Service Pod Architecture Changes for Self-Managed Environments

Starting with 107.161.x Self-Managed release, the artifactory and artifactory-ha Helm charts run Frontend, JFBus, and JFmelt as standalone Kubernetes Deployments by default. This is a potentially breaking change if you use custom Helm values, are missing a Join Key or Master Key, or have network policies tuned for the previous single-pod layout.

These three services reached this state differently:

• Frontend genuinely moved out of the Artifactory StatefulSet pod, where it previously ran as a container. It became available as an optional standalone Deployment in 107.146.x. From 107.161.x, enabled by default.
• JFBus and JFmelt are newer platform services that were introduced directly as standalone Kubernetes Deployments — neither ever ran as a container inside the Artifactory StatefulSet pod. What changed for them in this release is that they are now enabled by default, where they previously required opting in.

Components Affected

To disable any of these services (restoring Frontend to the Artifactory StatefulSet pod, or turning JFBus/JFmelt off entirely), see Configure Frontend, JFBus, and JFmelt Deployments.

New Pod Topology

flowchart TB
    subgraph FE["Frontend Pod"]
        F1["frontend + router + observability"]
    end
    subgraph JB["JFBus Pod"]
        J1["jfbus + router + observability"]
    end
    subgraph AF["Artifactory StatefulSet Pod"]
        A1["artifactory, metadata, event, jfconnect, router, observability, ..."]
    end
    subgraph JM["JFmelt Pod (Pro only)"]
        M1["jfmelt + router + observability"]
    end

    FE --> AF
    JB --> AF
    AF --> JM

Why These Services Run as Standalone Deployments

Frontend previously ran as a container inside a single Artifactory StatefulSet pod, alongside Artifactory and other microservices. That model had limits that motivated splitting Frontend out, and that also shaped JFBus and JFmelt as standalone services from their introduction:

1. Coupled lifecycle — Restarting or upgrading one service restarted the entire pod.
2. No independent scaling — Frontend could not be scaled separately under load.
3. Resource contention — Services sharing one pod compete for that pod's CPU/memory limits.
4. SaaS parity — SaaS already runs these as separate services; this release aligns Self-Hosted with that architecture.
5. New platform services — JFBus and JFmelt are first-class services that need their own lifecycle, health checks, and horizontal pod autoscaling (HPA).

Mandatory Join Key and Master Key

Helm now validates that a Join Key and Master Key can be resolved for every installation (unless keysPassedViaSystemyaml: true is set), because Frontend, JFBus, and JFmelt now run as independent deployments and each must authenticate to the platform at startup. If either key is missing, helm install/helm upgrade fails early with a descriptive error rather than deploying a pod that can't join the topology.

How to Provide Keys

Option 1 — Kubernetes Secret (recommended for production):

kubectl create secret generic artifactory-mandatory-keys -n <namespace> \
  --from-literal=master-key=${MASTER_KEY} \
  --from-literal=join-key=${JOIN_KEY}

helm upgrade --install artifactory jfrog/artifactory \
  --set global.masterKeySecretName=artifactory-mandatory-keys \
  --set global.joinKeySecretName=artifactory-mandatory-keys

Option 2 — Inline Helm values (dev/test only):

helm upgrade --install artifactory jfrog/artifactory \
  --set global.masterKey=${MASTER_KEY} \
  --set global.joinKey=${JOIN_KEY}

Option 3 — Keys already in system.yaml: If keys are already defined via artifactory.extraSystemYaml, artifactory.systemYaml, or systemYamlOverride under shared.security.joinKey/shared.security.masterKey, skip Options 1 and 2 and set:

helm upgrade --install artifactory jfrog/artifactory \
  --set keysPassedViaSystemyaml=true

Retrieving Existing Keys for an Upgrade

• Join Key — In the JFrog Platform UI, go to Administration > Security > General > Connection Details, enter your password, and copy the Join Key. See Manage Keys for the full procedure.

• Master Key — Retrieve it from a running Artifactory pod:

  Bash

  export MASTER_KEY=$(kubectl exec -it <release>-artifactory-0 -n <namespace> -c artifactory -- cat /opt/jfrog/artifactory/var/etc/security/master.key)

Fresh installs can generate new keys instead of retrieving existing ones:

export MASTER_KEY=$(openssl rand -hex 32)
export JOIN_KEY=$(openssl rand -hex 32)

Breaking Changes and Customer Impact

splitServicesToContainers Requirement

From Artifactory 7.161.x, splitServicesToContainers: false is no longer supported. Setting it to false fails Helm validation with:

'splitServicesToContainers: false' is no longer supported.
Starting with releases from 7.161.x, the Helm chart no longer supports running all services in a single container.
Set 'splitServicesToContainers: true' to proceed.

splitServicesToContainers: true is the default and must remain enabled.

Support Troubleshooting Checklist

1. Helm install/upgrade fails immediately — Check for a missing Join Key or Master Key; verify keysPassedViaSystemyaml is set if keys already exist in system.yaml.
2. JFmelt not deploying — Confirm a Pro license, jfconnect.enabled: true, and jfbus.enabled: true.
3. Frontend pod not starting — Check the waitForArtifactory init behavior and the Join/Master Key environment variables on the Frontend pod.

Related Topics

• Manage Keys
• Configure Frontend, JFBus, and JFmelt Deployments
• Hardware Sizing Matrix
• Artifactory Helm Upgrade
• Artifactory Product

Frequently Asked Questions