For the complete documentation index, see llms.txt.
Skip to main content
Version: 8.10

Property reference

Camunda Hub Self-Managed consists of two components: restapi and websocket. Each component is configured separately as described below.

  • The restapi component is a Spring Boot application. Its configuration is stored in a YAML file (application.yml) by default. All Camunda Hub-specific settings are prefixed with camunda.hub.
  • The websocket (PHP/Laravel) component is configured via environment variables.
Configuration methods

The two components support configuration through environment variables. For the restapi component, environment variables can be used as an alternative to application.yml following Spring Boot conventions: convert the property to uppercase, remove any dashes, and replace any delimiters (.) with _.

For example, the property camunda.hub.clusters[0].name is represented by the environment variable CAMUNDA_HUB_CLUSTERS_0_NAME.

If you are using the Camunda 8 Helm chart, read more about the different configuration options in the chart's Helm chart values documentation. You can pass environment variables to each component via camundaHub.restapi.env and camundaHub.websocket.env in your values.yaml.

For which settings belong in the chart and which belong here, see Helm and application configuration responsibilities. The recommended path for the properties on this page is camundaHub.restapi.extraConfiguration.

For a working example configuration showing how the components are correctly wired together, see the Docker Compose file for Camunda Hub.

Licensing​

Camunda 8 Self-Managed only

Installations of Camunda 8 Self-Managed which require a license can provide their license key to the components as an environment variable:

Environment variableDescriptionDefault value
CAMUNDA_LICENSE_KEYYour Camunda 8 license key, if your installation requires a license.None

For Helm installations, license keys can be configured globally in your values.yaml file. See the License key for more details.

note

Camunda 8 components without a valid license may display Non-Production License in the navigation bar and issue warnings in the logs. These warnings have no impact on startup or functionality.

Camunda Hub without a license: Camunda Hub is limited to five concurrent users when running without a valid enterprise license. This applies to Self-Managed installations used for testing or development purposes. To support additional users or for production use, obtain a Camunda Self-Managed Enterprise Edition license by visiting the Camunda Enterprise page.

Configuration of the restapi component​

As a Spring Boot application, the restapi component supports any standard Spring configuration method.

The tables below list each setting in two formats:

  • Application properties – the property names used in application.yml, the native Spring Boot configuration file format.
  • Environment variables – suitable for Docker Compose or direct shell usage.
Passing JVM options

When running the restapi component in a container (Docker / Kubernetes), use the JAVA_TOOL_OPTIONS environment variable to pass JVM arguments, for example for trust store settings or proxy configuration.

General​

PropertyDescriptionExample valueDefault value
camunda.hub.server.urlURL at which users access Camunda Hub in the browser (used to construct redirect URLs in the client-side login flow as well as links in notification emails).https://hub.example.com,
https://example.com/hub		-
server.servlet.context-path[optional]
Context path of the URL. Must be set if camunda.hub.server.url does not point to the root path of a (sub-)domain.		/hub-
camunda.hub.server.https-only[optional]
Enforce the usage of HTTPS when users access Camunda Hub (by redirecting from http:// to https://).		truetrue

Clusters​

To show your Orchestration Clusters in Camunda Hub, use the following configuration options available from Camunda 8.10. If you're migrating from an older version of Camunda Self-Managed, refer to the deprecated legacy configurations and the migration guide.

The Camunda 8.10 Helm chart can deploy one Hub release with orchestration releases from supported chart versions:

Hub chartOrchestration chartTopology mode
8.108.10orchestration
8.108.9orchestration
8.108.8orchestration
8.108.7orchestration

Set global.topology.mode: orchestration in each orchestration release. The 8.7, 8.8, and 8.9 charts don't support Hub mode or global.topology.clusters; configure the Hub release and cluster inventory with the 8.10 chart.

An orchestration release must disable its local Management Identity and set global.identity.service.url to the Management Identity service in the Hub release. Chart 8.7 uses separate Zeebe, Operate, and Tasklist components, so its Hub inventory must use the legacy component endpoints rather than the unified Orchestration Cluster endpoints.

Management Identity cluster​

If identity.enabled is true for a Hub release, the Helm chart automatically adds a management-cluster entry named Management Identity to camunda.hub.clusters, containing only the Hub's own Management Identity component. This entry appears in the Clusters pages alongside your Orchestration Cluster registrations so Console and DevOps role holders can manage the Hub's Management Identity instance. You don't need to configure this entry manually, and it isn't affected by dynamic cluster management.

note

Access to the cluster pages in Camunda Hub depends on the user's role: Console and DevOps role holders (users with the admin:clusters permission) get management access to the cluster pages, Hub admins (users with the admin:* permission) get full access, and other Hub members get read-only access.

PropertyDescriptionExample value
camunda.hub.clusters[0].idAn identifier for the cluster.camunda-platform
camunda.hub.clusters[0].nameA readable name for the cluster.Camunda Platform
camunda.hub.clusters[0].versionThe cluster version.8.10.0
camunda.hub.clusters[0].tagsA list of tags. The tags appear on every environment of the cluster. Use prod to mark production.['dev', 'test']
camunda.hub.clusters[0].authenticationThe authentication method.BEARER_TOKEN
camunda.hub.clusters[0].authorizations.enabledEnables or disables authorizations for the cluster. If enabled, users see a hint when they deploy from Camunda Hub.true
camunda.hub.clusters[0].custom-propertiesA list of custom properties.See custom properties.
camunda.hub.clusters[0].componentsA list of components for the clusters.See components.

Available authentication methods​

Clusters must be configured using the following options to access the cluster from within Camunda Hub:

MethodDescriptionWhen to use?
BEARER_TOKENCamunda Hub sends the authenticated user's token in the Authorization header with every request to the cluster.Cluster version >= 8.8
The cluster uses OIDC authentication with the same identity provider as Camunda Hub.
Note: You need to ensure that the cluster accepts Camunda Hub's token audience.
BASICCamunda Hub sends a username and password with every request to the cluster. The credentials have to be provided by the user in the UI.Cluster version >= 8.8
The cluster uses Basic authentication.

Console limitation
Console pages in Camunda Hub don't support clusters configured with Basic authentication. Console requests to the Orchestration Cluster are made automatically in the background, so there is no UI to collect credentials. Clusters using Basic authentication will not work correctly with Camunda Hub's Console functionality.
NONECamunda Hub does not send any authentication information.Cluster version >= 8.8
The cluster API is configured as unprotected and can be used without authentication.

Custom properties​

Use custom properties to include helpful links in the Clusters user interface:

PropertyDescription
camunda.hub.clusters[0].custom-properties[0].descriptionA description of the custom property.
camunda.hub.clusters[0].custom-properties[0].linksA list of links.
camunda.hub.clusters[0].custom-properties[0].links[0].nameA name for the link.
camunda.hub.clusters[0].custom-properties[0].links[0].urlThe link's URL.

Example configuration:

camunda:
  hub:
    clusters:
      - id: camunda-platform
        # other fields...
        custom-properties:
          - description: This is the integration environment for the Camunda platform.
            links:
              - name: Camunda
                url: https://camunda.com/
              - name: Documentation
                url: https://docs.camunda.io/

Components​

Use components to set up components in the cluster:

PropertyDescription
camunda.hub.clusters[0].components[0].nameThe component's name.
camunda.hub.clusters[0].components[0].typeThe component's type.
camunda.hub.clusters[0].components[0].versionThe component's version.
camunda.hub.clusters[0].components[0].urls.webappThe API base URL for all components with a web app: Admin, Management Identity, Optimize, Tasklist, Operate.
camunda.hub.clusters[0].components[0].urls.restThe REST API base URL for Connectors and the Orchestration Cluster.
camunda.hub.clusters[0].components[0].urls.grpcThe address of the Zeebe gRPC API.
camunda.hub.clusters[0].components[0].urls.readinessThe address of the health check endpoint.

Available component types and requirements:

Configuration valueComponentRequirements
connectorsConnectorsREST URL
identityManagement Identity-
hubCamunda Hub-
operateOperate-
optimizeOptimize-
orchestrationOrchestration ClusterCluster version >= 8.8, gRPC URL, and REST URL
adminAdmin-
tasklistTasklist-
Backward compatibility

The old values webModelerWebApp (replaced by hub) and orchestrationIdentity (replaced by admin) are still accepted for backward compatibility.

Example configuration:

camunda:
  hub:
    clusters:
      - id: camunda-platform
        # other fields...
        components:
          - name: "Orchestration Cluster"
            type: "orchestration"
            version: "8.10-SNAPSHOT"
            urls:
              grpc: "grpcs://camunda.example.com:26500"
              rest: "https://camunda.example.com"
              readiness: "https://camunda.example.com:9600/core/actuator/health/readiness"
          - name: "Orchestration Admin"
            type: "admin"
            version: "8.10-SNAPSHOT"
            urls:
              webapp: "https://camunda.example.com"
              readiness: "https://camunda.example.com:9600/core/actuator/health/readiness"

Mark a cluster as production​

This step is optional. Tag a cluster with prod only if you want Camunda Hub to treat its environments as production environments. Camunda Hub treats an environment as a production environment if the tags of its cluster include prod. The match is exact and case-sensitive, so prod works but Prod and production don't. All Physical Tenants of a cluster tagged prod are production environments. See the project deployment settings.

camunda:
  hub:
    clusters:
      - id: camunda-platform
        # other fields...
        tags: ["prod"]

Physical tenants​

Declare the Physical Tenants of your clusters in the Camunda Hub configuration. Camunda Hub surfaces each declared Physical Tenant, and the default Physical Tenant of every cluster, as an environment that teams deploy to. An environment appears only if its cluster is in your configuration. Camunda Hub reads the cluster configuration once at startup on every instance, so after you change it, perform a rolling restart.

The version of the cluster decides which Physical Tenants Camunda Hub surfaces as environments:

Cluster versionEnvironments
8.10 or laterOne for the default Physical Tenant, which always exists, plus one for each Physical Tenant you declare under physical-tenants. Camunda Hub names the default one after the cluster.
Earlier than 8.10One environment for the whole cluster, named after the cluster.

If you declare physical-tenants on a cluster earlier than 8.10, Camunda Hub ignores them and logs a warning.

Declare physical tenants​

Declare each additional Physical Tenant of a cluster with physical-tenants. Camunda Hub uses the ID of a tenant as the name of its environment, except for the default tenant.

PropertyDescriptionRequired
camunda.hub.clusters[0].physical-tenants[0].idThe ID of the Physical Tenant. Camunda Hub shows it as the environment name.Yes
camunda.hub.clusters[0].physical-tenants[0].componentsThe components that differ from the cluster for this tenant. Each component needs a type and a version.No

Example configuration:

camunda:
  hub:
    clusters:
      - id: camunda-platform
        # other fields...
        physical-tenants:
          - id: payments-prod
          - id: lending-prod

Each Physical Tenant of a cluster shows the same tags as the cluster. The tenant inherits the web application addresses of the cluster, and Camunda Hub adds the /physical-tenants/<tenant ID> path for the tenants other than default.

Override components for a physical tenant​

Use components on a Physical Tenant to point it at its own component instances. This is a partial override:

  • Only the component types you list are replaced for the tenant. A listed component replaces the cluster entry completely, so set every address the tenant needs, such as urls.webapp and urls.readiness.
  • Every other component keeps using the configuration of the cluster, and follows later changes to it.
  • A tenant other than default never inherits Optimize from the cluster, because Optimize needs its own instance for each Physical Tenant. Add an optimize component to the tenant to show Optimize.
  • If you remove the override and restart Camunda Hub, the component uses the configuration of the cluster again.

Example configuration that overrides only Optimize for the payments-prod tenant. The other components still come from the cluster:

camunda:
  hub:
    clusters:
      - id: camunda-platform
        # other fields...
        physical-tenants:
          - id: payments-prod
            components:
              - type: optimize
                version: 8.10.0
                urls:
                  webapp: https://optimize-payments-prod.example.com
                  readiness: https://optimize-payments-prod.example.com/api/readyz

If a cluster earlier than 8.10 declares components on a tenant, Camunda Hub fails to start with the message must not declare physical tenant 'components' if 'version' is lower than the minimum physical tenant version.

Environment status​

Camunda Hub sends an HTTP request to the urls.readiness address of each component of an environment to determine its status. The status of the environment is the worst result of its components:

Component responseStatus
A successful response, with no body or with a status of up or readyHealthy
An error response, or any other statusUnhealthy
No readiness address, no response within five seconds, a redirect, or a body without a status fieldUnknown

A cluster that you configure with url instead of components has no readiness address, so its environments always have the status Unknown.

Not reported environments​

If you remove a cluster or Physical Tenant from the configuration, but its environment is still assigned to a workspace, the environment stays in Camunda Hub with the status Not reported. It shows no live data, and you can't select it for a deployment. Remove the assignment from the workspace when you no longer need it.

Database​

Camunda Hub currently supports PostgreSQL, Oracle, Microsoft SQL Server (MSSQL), MySQL, MariaDB, and H2 as persistent data storage.

Oracle and MySQL driver

The Oracle and MySQL drivers are not provided by default and must be downloaded and supplied for the application to load. Refer to the Oracle and MySQL database configuration section for details.

PropertyDescriptionExample value
spring.datasource.urlJDBC URL of the databasejdbc:postgresql://postgres.example.com:5432/hub-db
spring.datasource.usernameDatabase user namehub-user
spring.datasource.passwordDatabase user password***
spring.datasource.driver-class-name[optional]
Java class name of the database driver		software.amazon.jdbc.Driver
spring.datasource.hikari.schema[optional; only supported for PostgreSQL]
Database schema.
Defaults to the default schema of the database user (usually public) if not set.
Refer to the PostgreSQL documentation for naming restrictions.		custom_schema

Refer to the Advanced Database Configuration Guide for additional details on how to configure Camunda Hub's database connection.

SMTP / email​

Camunda Hub requires an SMTP server to send notification emails to users.

PropertyDescriptionExample valueDefault value
spring.mail.hostSMTP server host namesmtp.example.com-
spring.mail.portSMTP server port587-
spring.mail.username[optional]
SMTP user name		hub-user-
spring.mail.password[optional]
SMTP user password		***-
spring.mail.properties.mail.smtp.auth[optional]
Set to true if you provide a user name and password.		truetrue
spring.mail.properties.mail.smtp.starttls.enable[optional]
Enable TLS encryption for SMTP connections (using STARTTLS).		truetrue
spring.mail.properties.mail.smtp.starttls.required[optional]
Enforce the use of STARTTLS (to prevent fallback to non-protected connections).		truetrue
camunda.hub.mail.from-addressEmail address used as the sender of emails sent by Camunda Hub.noreply@example.com-
camunda.hub.mail.from-name[optional]
Name displayed as the sender of emails sent by Camunda Hub.		CamundaCamunda

WebSocket​

Camunda Hub uses a WebSocket server to send events (e.g. "file updated", "comment added", "user opened diagram") between the backend and the client application in the browser. This enables features like real-time notifications and immediate UI updates.

PropertyDescriptionExample valueDefault value
camunda.hub.pusher.hostInternal host name of the WebSocket server.hub-websockets-
camunda.hub.pusher.portInternal port number of the WebSocket server.80608060
camunda.hub.pusher.app-idmust be the same as PUSHER_APP_IDhub-
camunda.hub.pusher.keymust be the same as PUSHER_APP_KEY***-
camunda.hub.pusher.secretmust be the same as PUSHER_APP_SECRET***-
camunda.hub.pusher.client.hostExternal host name on which the Camunda Hub client accesses the WebSocket server from the browser.ws.example.com-
camunda.hub.pusher.client.portExternal port number on which the Camunda Hub client accesses the WebSocket server from the browser.44380
camunda.hub.pusher.client.path[optional]
must be the same as PUSHER_APP_PATH		/hub-ws/
camunda.hub.pusher.client.force-tlsEnable TLS encryption for WebSocket connections initiated by the browser.truefalse

Identity / Keycloak​

Camunda Hub uses Keycloak as the default authentication provider (using OAuth 2.0 + OpenID Connect) and integrates with Management Identity for user management and authorization (see Manage access and permissions).

note

Configure Camunda Hub authentication with the properties on this page, not with the Orchestration Cluster's camunda.security.authentication.oidc.* settings. The one exception is the claim that identifies a user: you can also set camunda.security.authentication.oidc.username-claim directly, as an alternative to CAMUNDA_HUB_OAUTH2_TOKEN_USERIDCLAIM (camunda.hub.oauth2.token.user-id-claim). This is unrelated to CAMUNDA_IDENTITY_USERNAMECLAIM (camunda.identity.username-claim), which only sets a user's display name.

See authentication for more details.

PropertyDescriptionExample valueDefault value
camunda.identity.base-urlInternal base URL of the Identity API (used to fetch user data).http://identity:8080-
camunda.identity.username-claim[optional]
ID token claim used to assign usernames.		preferred_usernamename
camunda.hub.security.jwt.audience.internal-apiExpected value of the audience claim in user access tokens (used for JWT validation).web-modeler-apiweb-modeler-api
camunda.hub.security.jwt.audience.public-apiExpected value of the audience claim in M2M access tokens required for Camunda Hub's API (used for JWT validation).web-modeler-public-apiweb-modeler-public-api
camunda.identity.issuer-backend-url[optional]
Internal URL used to request Keycloak's OpenID Provider Configuration; if not set, spring.security.oauth2.resourceserver.jwt.issuer-uri is used.		http://keycloak:18080/auth/realms/camunda-platform-
spring.security.oauth2.resourceserver.jwt.issuer-uriURL of the token issuer (used for JWT validation).https://keycloak.example.com/auth/realms/camunda-platform-
spring.security.oauth2.resourceserver.jwt.jwk-set-uri[optional] URL of the JWK Set endpoint (used for JWT validation). Only necessary if URL cannot be derived from the OIDC configuration endpoint.https://keycloak.example.com/auth/realms/camunda-platform/protocol/openid-connect/certs-
spring.security.oauth2.resourceserver.jwt.jws-algorithms[optional] List of trusted JWS algorithms used for JWT validation. Only necessary if the algorithms cannot be derived from the JWK Set response.ES256-
spring.security.oauth2.resourceserver.jwt.audiences[optional]
Comma-separated list of accepted audience claim values, validated in addition to camunda.hub.security.jwt.audience.internal-api and camunda.hub.security.jwt.audience.public-api.		web-modeler-api-
camunda.hub.oauth2.client-idClient ID of the Camunda Hub application configured in Identity.web-modeler-
camunda.hub.oauth2.client.scope[optional]
OIDC scopes requested during authentication, determining what user information is included in the token.		fullopenid email profile
camunda.hub.oauth2.client.fetch-request-credentials[optional]
Configuration whether credentials should be sent along with requests to the OIDC provider, see documentation. Use this if you are using a proxy that requires cookies.		include-
Helm behavior

The restapi component default for CAMUNDA_IDENTITY_USERNAMECLAIM is name. In Helm-based setups, OIDC configuration commonly uses preferred_username, so usernames may appear as email-style identifiers unless you explicitly set CAMUNDA_IDENTITY_USERNAMECLAIM=name for the Camunda Hub restapi environment.

Refer to the authentication guide for additional details on how Camunda Hub authenticates users, and on how to connect a custom OpenID Connect (OIDC) authentication provider.

Camunda client​

Camunda Hub uses the Camunda Java client to connect to Zeebe. To customize the client configuration, you can provide optional properties.

PropertyDescriptionExample valueDefault value
camunda.ca-certificate-path[optional]
Path to a root CA certificate to be used instead of the certificate in the default store.		/path/to/certificate-
camunda.client.config-path[optional]
Path to a file used to cache the client's OAuth credentials on disk. When unset, credentials are cached in memory only.		/path/to/credentials/cache.txtin-memory only
camunda.client.request-timeout[optional]
The request timeout used when communicating with a target Zeebe cluster.		6000010000
camunda.auth.connect-timeout[optional]
The connection timeout for requests to the OAuth server.		300005000
camunda.auth.read-timeout[optional]
The data read timeout for requests to the OAuth server.		300005000

For more details, see the Zeebe connection troubleshooting section.

Logging​

PropertyDescriptionExample valueDefault value
logging.config[optional]
Path to custom Log4j2 configuration.		file:/full/path/to/custom-log4j2-spring.xml-
camunda.hub.client.logging.level[optional]
Log level for the client.		DEBUGWARN

The CAMUNDA_HUB_LOG_LEVEL, CAMUNDA_LOG_FILE_APPENDER_ENABLED, and CAMUNDA_HUB_LOG_APPENDER settings are only available as environment variables.

Refer to the advanced logging configuration guide for additional details on how to customize the restapi logging output.

info

SSL​

PropertyDescriptionExample valueDefault value
server.ssl.enabled[optional]
Whether to enable SSL support.		truefalse
server.ssl.certificate[optional]
Path to a PEM-encoded SSL certificate file.		file:/full/path/to/certificate.pem-
server.ssl.certificate-private-key[optional]
Path to a PEM-encoded private key file for the SSL certificate.		file:/full/path/to/key.pem-
management.server.ssl.enabled[optional]
Whether to enable SSL support for the management server routes.		truefalse
management.server.ssl.certificate[optional]
Path to a PEM-encoded SSL certificate file.		file:/full/path/to/certificate.pem-
management.server.ssl.certificate-private-key[optional]
Path to a PEM-encoded private key file for the SSL certificate.		file:/full/path/to/key.pem-
camunda.hub.pusher.ssl-enabled[optional]
Whether to enable communication via SSL to the websocket component.		truefalse

Refer to the advanced SSL configuration guide for additional details on how to set up secure connections (incoming & outgoing) to the Camunda Hub components.

Monitoring and health probes​

The restapi component is a Spring Boot application that includes the Spring Boot Actuator, providing health check and metrics endpoints out of the box. These endpoints are served on a separate management port (default: 8091).

By default, Camunda Hub uses the following actuator configuration:

PropertyDescriptionExample valueDefault value
management.server.port[optional]
Port for the management server (health and metrics endpoints).		80918091
management.endpoints.access.default[optional]
Default access level for all actuator endpoints.		read-onlynone
management.endpoints.web.exposure.include[optional]
Comma-separated list of actuator endpoints to expose over the web.		health, prometheushealth, info, prometheus, loggers
management.endpoints.web.base-path[optional]
Base path for all web-exposed actuator endpoints.		/actuator/
management.endpoints.web.path-mapping.health[optional]
Custom path mapping for the health endpoint.		healthhealth
management.endpoints.web.path-mapping.prometheus[optional]
Custom path mapping for the Prometheus endpoint.		prometheusmetrics
management.endpoint.prometheus.access[optional]
Access level for the Prometheus endpoint.		unrestrictedread-only
management.endpoint.health.access[optional]
Access level for the health endpoint.		unrestrictedread-only
management.endpoint.health.probes.enabled[optional]
Whether Kubernetes-style readiness and liveness probes are enabled.		truetrue
management.endpoint.health.group.readiness.additional-path[optional]
Expose the readiness probe on an additional path (e.g. on the main server port).		server:/healthserver:/health
management.endpoint.info.access[optional]
Access level for the info endpoint.		unrestrictedread-only
management.endpoint.loggers.access[optional]
Access level for the loggers endpoint.		read-onlyunrestricted
management.info.git.enabled[optional]
Whether Git info is exposed via the info endpoint.		truefalse
management.health.defaults.enabled[optional]
Whether default health indicators are enabled.		truefalse
management.metrics.distribution.percentiles[http.server.requests][optional]
Comma-separated list of percentiles to publish for HTTP server request metrics.		0.5, 0.9, 0.990.5, 0.9, 0.99

Available endpoints​

EndpointDescription
<server>:8091/metricsPrometheus metrics
<server>:8091/health/readinessReadiness probe
<server>:8091/health/livenessLiveness probe

For more details, including Kubernetes probe configuration examples and websocket health endpoints, see the Monitoring page.

Git Sync​

Camunda Hub supports syncing files via Git Sync. Provide the base URL for your provider if you are using a self-hosted GitLab, GitHub, or Azure DevOps Server instance.

ProviderPropertyDescriptionDefault value
All providerscamunda.hub.git-sync.max-filesMaximum number of allowed files for sync operations.100
All providerscamunda.hub.git-sync.max-in-memory-sizeMaximum memory size that can be processed by calls to the Git provider. This limits the maximum file size that can be synced.4MB
GitHubcamunda.hub.git-sync.github.base-urlThe base URL of your self-hosted GitHub instance.https://api.github.com
GitLabcamunda.hub.git-sync.gitlab.base-urlThe base URL of your self-hosted GitLab instance.https://gitlab.com/api/v4
Azure DevOpscamunda.hub.git-sync.azure.base-urlThe base URL of your self-hosted Azure DevOps Server instance.https://dev.azure.com
Azure DevOpscamunda.hub.git-sync.azure.api-versionThe Azure DevOps API versions to use.7.1
Azure DevOpscamunda.hub.git-sync.azure.authority-base-pathURL used to access authentication and authorization services for Microsoft cloud identities.https://login.microsoftonline.com
Azure DevOpscamunda.hub.git-sync.azure.scopeOAuth scope requested for Azure DevOps authentication.https://app.vssps.visualstudio.com/.default
Bitbucketcamunda.hub.git-sync.bitbucket.base-urlThe base URL of Bitbucket Cloud.https://api.bitbucket.org/2.0/repositories

Feature flags​

PropertyDescriptionExample valueDefault value
camunda.hub.feature.test-mode-enabled[optional]
Enables the Test mode in the BPMN editor, allowing users to test processes in a playground environment.		falsetrue
camunda.hub.feature.bpmn-deployment-enabled[optional]
Enables the Deploy and Run actions in the BPMN editor.
When disabled, it prevents users from deploying and starting instances of processes via the UI.		falsetrue
camunda.hub.feature.dmn-deployment-enabled[optional]
Enables the Deploy action in the DMN editor.
When disabled, it prevents users from deploying decisions via the UI.		falsetrue
camunda.hub.feature.dynamic-cluster-management-enabled[optional]
Enables dynamic cluster management.		truefalse
camunda.hub.feature.ui-user-invite-enabled[optional]
Enables the Add members button on the workspace Members page for users who aren't Organization admins. Organization admins always see the button, regardless of this setting. Adding members through the Hub API is unaffected.		falsetrue
camunda.hub.feature.runtime-connection-enabled[optional]
Enables the runtime connection selector in the BPMN editor.
When disabled, task testing uses its own cluster selection and connector credentials aren't offered in the properties panel.		falsetrue
camunda.hub.feature.credentials-enabled[optional]
Enables credentials in Camunda Hub.
Offering connector credentials in the properties panel of the BPMN editor also requires camunda.hub.feature.runtime-connection-enabled.		falsetrue
camunda.hub.feature.marketplace-enabled[optional]
Enables the integration of the Camunda Marketplace. If enabled, users can browse the Marketplace and download resources directly inside Camunda Hub.		falsetrue

Dynamic cluster management​

Use dynamic cluster management to automatically register your clusters with Camunda Hub.

By default, clusters shown in Camunda Hub are strictly managed by your configuration. Cluster registrations are created, updated, and deleted when you change your cluster configuration values.

Dynamic cluster management changes this to a hybrid model. Camunda Hub uses your cluster configuration—if you provide one—alongside the following API endpoints, which are only exposed when dynamic cluster management is enabled:

NamePath
Create or update a cluster registrationPOST /api/v2/clusters
Remove a cluster registrationDELETE /api/v2/clusters/{clusterId}

In this mode, you:

  1. Configure your Orchestration Clusters to send license information directly to the create or update a cluster registration endpoint. If you didn't define the clusters in your configuration, this call registers them with minimal information and no management functionality in the Camunda Hub interface.
  2. Remove stale cluster registrations from Camunda Hub using the remove a cluster registration endpoint.

You can still define new clusters in your configuration, though it's not required. When you do, Camunda Hub automatically registers them with all available settings and full management functionality in the interface.

note

With dynamic cluster management enabled, don't call the create or update cluster registration endpoint manually—only let your cluster configuration do it. The endpoint doesn't yet support creating clusters with all configurable settings.

Hide add members button​

Hide the Add members button on the workspace Members page (which is displayed by default):

camunda:
  hub:
    feature:
      ui-user-invite-enabled: false

Organization admins always see the button, regardless of this setting. Other users will not see the button. Instead, they must add members with the Camunda Hub API.

Unstable configuration options​

These are unstable options that are not officially supported and may be removed without deprecation in future releases. They are intended for testing and feedback purposes only.

PropertyDescriptionExample valueDefault value
camunda.hub.resource-import.allow-private-ip-addressAllow importing resources from a host that resolves to a private IP address. Enabling this option weakens server-side request forgery (SSRF) protections and can significantly increase security exposure.truefalse

Configuration of the websocket component​

The WebSocket server shipped with Camunda Hub Self-Managed is based on the laravel-websockets open source package and implements the Pusher Channels Protocol.

The websocket component is configured via environment variables. When using the Camunda Helm chart, you can pass these variables via camundaHub.websocket.env in your values.yaml. See the Helm chart values docs for all available configuration options.

Environment variableDescriptionExample valueDefault value
PUSHER_APP_IDID of the single application/tenant configured for Camunda Hub.hub-
PUSHER_APP_KEYA unique key used for authentication. Provide a random alphanumeric string of at least 20 characters.***-
PUSHER_APP_SECRETA unique secret used for authentication. Provide a random alphanumeric string of at least 20 characters.***-
PUSHER_APP_PATH[optional]
Base path of the WebSocket endpoint. Can be used to expose the endpoint on a sub path instead of the domain root (e.g. https://example.com/hub-ws).		/hub-ws/

Logging​

Environment variableDescriptionExample valueDefault value
LOG_CHANNEL[optional]
Log channel driver, see Laravel documentation		singlestack

Refer to the Advanced Logging Configuration Guide for additional details on how to customize the websocket logging output.

SSL​

Environment variableDescriptionExample valueDefault value
PUSHER_SSL_CERT[optional]
Path to a PEM-encoded SSL certificate file.		/full/path/to/certificate.pem-
PUSHER_SSL_KEY[optional]
Path to a PEM-encoded private key file for the SSL certificate.		/full/path/to/key.pem-
PUSHER_SSL_PASSPHRASE[optional]
Passphrase for the private key file.		change-me-

Refer to the advanced SSL configuration guide for additional details on how to set up secure connections (incoming & outgoing) to the Camunda Hub components.

Notes on host names and port numbers​

  • Internal refers to host names and port numbers that are only used inside a Docker Compose network or Kubernetes cluster for backend-to-backend communication.
  • External refers to host names and port numbers that are exposed to the outside and can be reached from a web browser.