8.10 Release notes
Release notes for new features included in the 8.10 minor release, including alpha feature releases.
| Minor release date | End of standard maintenance | Changelog(s) | Upgrade guides |
|---|---|---|---|
| 13 October 2026 | 11 April 2028 | Patch Releases and Changelogs | 8.10 upgrade guides |
- See What's new in Camunda 8.10 for important changes to consider when planning your upgrade from Camunda 8.9.
- See release announcements to learn more about supported environment changes, breaking changes, and deprecations.
- Refer to the quality board for an overview of known bugs by component and severity.
Technical Changelogs for all 8.10.x releases
Overview of all patch releases and their Changelogs in GitHub
Agentic orchestration
Agentic control plane
Use the Optimize agentic control plane dashboard to monitor AI agent adoption, token usage, reliability, and performance across your processes in a single view. The dashboard is primarily intended to help operators, process owners, and engineering leads who manage AI-agent-powered processes, and need to keep them reliable and cost-effective.
AI Agent connector
Conversation storage SPI redesign
The conversation storage SPI used by custom AI Agent storage backends has been redesigned. Built-in stores are migrated transparently; custom ConversationStore implementations must be updated.
Conversation storage SPI redesign
New native element templates
The AI Agent Task and AI Agent Sub-process connectors are now available as new, native element templates, running on new job types and giving native access to each LLM provider's own SDK and wire format, including extended thinking and prompt caching configuration where supported.
Provider and backend selection are now decoupled. For example, the Anthropic provider can run through AWS Bedrock Mantle, and the OpenAI provider through Microsoft Foundry (Azure), while keeping each provider's own configuration options. The legacy element templates are deprecated as of Camunda 8.10.
This is a major redesign of the AI Agent connector, available from 8.10 only, and requires manual migration of each element from the current legacy connector.
Upgrade AI Agent element templates
The legacy connector is deprecated in 8.10, but is not removed and continues to work. Adopting the new template is a manual, per-element migration, not an automatic upgrade.
Claude on Microsoft Foundry and OAuth 2.0 for compatible endpoints
Your AI agents can now use Claude models hosted by Microsoft Foundry (Azure), through the Anthropic provider of the new AI Agent element templates. The provider keeps Anthropic-specific configuration such as extended thinking and prompt caching. Authenticate with an API key, Microsoft Entra ID client credentials, or a managed identity (Hybrid and Self-Managed only).
The custom or compatible endpoint backends for both the Anthropic and OpenAI providers now support OAuth 2.0 client credentials. Use this authentication method with internal gateways that issue bearer tokens instead of accepting static API keys.
AI agent testing with Camunda Process Test
You can now test non-deterministic AI agent behavior in Camunda Process Test (CPT) with conditional behavior controls and evaluation-based assertions, so you can validate agent behavior and output quality with more reliable test outcomes.
- Define conditional behavior in tests with a
when(condition).then(action)API. - Assert output quality with LLM-as-a-judge expectations, or compare semantic similarity with embeddings, when exact matching is not enough.
- Use judge and semantic similarity assertions on any string value with AssertJ, or define judge assertions in JSON test cases.
- Configure remote or local models through code and properties, for both local development and CI/CD pipelines.
Assisted agent tool configuration
New features help you more easily configure your agent tools when modeling.
| Feature | Description | Available in |
|---|---|---|
| Fix | Automatically detect and apply a safe fix for an agent misconfiguration.
|
|
| Input from agent, Output to agent | Automatically fill in the fromAi() inputs or the toolCallResult output configuration of an agent tool contract.
|
|
| Lint rule checking | Agent tool configuration lint rule checking helps you avoid agent misconfiguration and errors when modeling.
|
|
- Changes are explicit, apply only when the correction is deterministic, and can be undone.
- These configuration features are only available inside an ad-hoc sub-process marked as agentic through either the
io.camunda.agenticai.toolContainerproperty or an out-of-the-box AI Agent element template. It is not available in a plain sub-process. You might need to update your element template to use this new feature.
Assisted agent tool configuration
Camunda-provided LLM for SaaS
You can now run AI Agents on Camunda 8 SaaS in minutes using the Camunda-provided LLM, without your own LLM credentials.
- Whether you start from a Camunda-provided agentic blueprint or build your own agent from scratch, the required credentials are populated automatically as cluster secrets, so there is little to no extra setup needed to get started.
- The included budget is sufficient for hundreds or thousands of agent runs even on a trial account, depending on the model used. Enterprise organizations must explicitly enable the Camunda Provided LLM toggle in Camunda Hub, which is separate from the AI-powered features toggle.
- This dramatically reduces time-to-first-running-agent by removing the need for external LLM infrastructure or credential setup.
IDP supports ABBYY for document extraction
Intelligent document processing (IDP) now supports ABBYY as a document extraction provider.
Intelligent document processing
MCP start event element template
The MCP start event element template is now available in Modeler. Apply it to a BPMN message start event to configure the process as an MCP tool with name, purpose, inputs, and usage guidance for LLMs.
Processes MCP Server
AI agents can use the Processes MCP Server to discover and call deployed BPMN processes as Model Context Protocol (MCP) tools.
- When you deploy a process with an MCP start event it is automatically registered as a callable tool.
- MCP clients connect to the
/mcp/processesendpoint and can invoke any registered process, with the Orchestration Cluster starting a new process instance and immediately returning the process instance key. - The server also exposes static tools for inspecting running process instances, so agents can check variables, state, and incidents without switching servers.
ProcessOS Harness
Discover your existing processes, re-engineer them against defined outcomes, and generate executable Camunda solutions, with a governed process that keeps AI-generated work auditable.
Real-time agent visibility and monitoring
Monitor and evaluate AI agent behavior in Operate.
- View each agent's execution state (thinking, calling a tool, idle) highlighted on the process diagram, as well as its current tool calls, usage metrics (tokens, tool calls, and model calls against the configured limit), model, and system prompt.
- Trace the full reasoning chain behind AI agent decisions in the conversation history such as user prompts, assistant messages, tools selected with the agent's reasoning, and tool calls with navigation to the corresponding diagram elements, so you can see exactly which messages, inputs, and tool responses informed each of the agent's next steps.
- Operate displays readable model reasoning as an inline Thinking entry in the conversation history. Migrate to the AI Agent element templates introduced in 8.10 to display reasoning where supported.
- External agents built with frameworks such as LangGraph or CrewAI get the same visibility through the new Agent Instance API.
Monitor your AI agents with Operate
If you modeled the agent element before Camunda 8.10, you must update its element template to at least v1 (version 13) or v2 to enable this feature.
Skills repository for pro-code AI enablement
The Camunda Skills repository toolset enables AI coding agents to build, validate, and configure Camunda artifacts. With the Skills installed, your AI agent can:
- Build and modify BPMN diagrams with a human-readable layout.
- Configure connectors using element templates (no raw XML).
- Generate form schemas with validation.
- Create and edit DMN decision tables.
- Run BPMN lint rules against generated diagrams.
- Scaffold and wire Camunda Process Test (CPT) integration tests.
APIs & tools
C# SDK
Camunda now offers an officially supported C# Client for the Camunda 8 Orchestration Cluster REST API v2.
You can authenticate with your cluster (No Auth for local, Basic authentication, or OIDC access tokens) and use C# methods to deploy resources, start and manage process instances, work with user tasks, and query processes and decisions, complete with pagination helpers and typed responses via generated models.
Camunda Hub API
A new public Camunda Hub API is provided under /v2/ for programmatic access to the resources previously managed in Console and Web Modeler.
- The API aligns with the Orchestration Cluster API guidelines, with standardized error handling and data-fetching patterns.
- The Console Self-Managed and Web Modeler APIs are deprecated in favor of the Camunda Hub API.
- See the release announcement for details.
Console API supports external encryption for cluster creation
The Camunda Console API now accepts encryption configuration parameters when creating clusters.
Organizations using Terraform, custom scripts, or CI/CD pipelines can specify the encryption type (including external customer-managed keys) directly in the cluster creation request, removing the need for a separate manual step in the web console.
- Clusters that do not meet the required encryption policy can be blocked at the API level before provisioning begins.
FEEL evaluation with process instance key
The POST /v2/expression/evaluation endpoint now optionally evaluates expressions in the context of:
- A process instance, via
processInstanceKey. - A flow node instance, via
elementInstanceKey.
The endpoint:
- Combines process instance variables, element-local variables (for element scope), cluster variables, and optional request context into a single evaluation context.
- Enforces
EXPRESSION:EVALUATEplusPROCESS_DEFINITION:READ_PROCESS_INSTANCEon the underlying process definition. - Requires exactly one of
processInstanceKeyorelementInstanceKey(mutually exclusive); sending both returns400 Bad Request.
Behavior remains free from side effects and uses the same timeout and guardrails as the existing cluster-scope evaluation.
Go and Rust SDKs
8.10 introduces Technical Previews for Go and Rust language SDKs for the Orchestration Cluster API.
The Go SDK additionally contains support for gRPC job streaming. During 8.10 these SDKs will be stabilized, but there may be changes to their API surface based on user feedback. These SDKs will be fully supported and guaranteed to be stable in a later release.
Invite members via the Hub API who haven't previously logged in
Adding a workspace member via the public API no longer requires the invitee to have previously logged in to Hub Modeler.
- You can use
PUT /v1/collaboratorsorPOST /v2/workspaces/{workspaceKey}/members. - If the email address belongs to an organization member with no local user yet, a pending invitation is created and an invitation email sent.
- The invitee gains workspace access once they accept the invitation.
Java client in-memory OAuth credentials cached by default
The Camunda Java client now caches OAuth credentials in memory by default.
The file-based cache at $HOME/.camunda/credentials is no longer enabled by default and is available as an explicit opt-in.
- The previous default tried to create
$HOME/.camunda/credentialson first use. In hardened container environments such as non-root users (KubernetessecurityContext.runAsUser, OpenShift), read-only root filesystems, and immutable images, this raisedAccessDeniedException/IOExceptionat first cache write. Affected users had to apply a non-obvious workaround (mount a writable volume and point an environment variable at it) just to get a client to start. - Memory-only caching removes that footgun: clients work out of the box in any deployment topology, and the in-process token cache plus proactive refresh still avoid unnecessary token endpoint calls during a JVM's lifetime.
- The file cache had also been a source of latent corruption when multiple JVMs shared the same
$HOME; making it opt-in restricts its use to deployments where persistence across restarts is genuinely needed.
How to opt in to the file-based cache (behavior identical to pre-8.10):
| Configuration method | Example |
|---|---|
| Java client builder | new OAuthCredentialsProviderBuilder().credentialsCachePath("/path/to/cache") |
| Spring property | camunda.client.auth.credentials-cache-path: /path/to/cache |
| Environment variable | CAMUNDA_CLIENT_CONFIG_PATH=/path/to/cache (or ZEEBE_CLIENT_CONFIG_PATH for the legacy Zeebe client) |
If you previously set CAMUNDA_CLIENT_CONFIG_PATH / ZEEBE_CLIENT_CONFIG_PATH only to work around the non-root container error, you can now remove that configuration and rely on the in-memory default.
Spring Boot starter configuration
Operate and Tasklist APIs removed
The deprecated Operate and Tasklist APIs are removed. Process data, task management, and operational queries are now served through the Orchestration Cluster API.
Migrate to the Orchestration Cluster API
Scheduled cluster backups via the Administration API
With the Camunda 8 SaaS Administration API, you can now schedule and manage recurring cluster backups programmatically, helping you automate disaster-recovery routines instead of relying only on manual, on-demand backups.
Zeebe Client replaced by Camunda Java Client
The Zeebe Client is removed and replaced by the Camunda Java Client. This covers process deployment, message correlation, and job handling.
Migrate to the Camunda Java Client
Zeebe Process Test replaced by Camunda Process Test
The Zeebe Process Test library is removed and replaced by Camunda Process Test. This provides richer assertions, Spring integration, and alignment with the Orchestration Cluster API surface.
Migrate to Camunda Process Test
Camunda 8 Run
Camunda 8 Run Java runtime
Camunda 8 Run now includes a bundled Java runtime. This means you no longer need to install OpenJDK or set JAVA_HOME before starting Camunda 8 Run.
Camunda design system
The new visual Camunda design system is introduced for Admin, Camunda Hub, and Tasklist with the 8.10 release.
- The new, streamlined design system offers a cleaner, more consistent look across components.
- Accessibility improvements are built in, and the updated navigation menu makes it easier to find your way around.
- The new design system is enabled by default in both Self-Managed and SaaS.
Camunda Hub
Camunda Hub is now the single place where you and your teams build, govern, and run process solutions in Camunda.
-
Hub is where you design, model, manage, and oversee your processes. Hub replaces Web Modeler and Console, keeping their existing features while adding new features within a single unified platform.
-
Hub is deployed only once, and serves as the single point of entry for all your environments, connecting to all your dev, staging, and production Orchestration Clusters.
Hub changes how you and your teams work. Instead of managing separate Web Modeler and Console instances per environment, you now use a single Hub that connects to all your clusters. You design once, and manage everything from one place.
Business value dashboard
Use the new Business Value page in Camunda Hub to track process outcomes using cycle time, automation rate, activity, and agentic adoption metrics, and to set targets for cycle time and automation rate.
- A portfolio view compares every process in the selected environment on target coverage, target attainment, activity, automation rate, cycle time, and agentic adoption, and ranks off-target processes by how many targets are missed and by how far.
- A process view shows the metrics and targets for a single process, including per-metric target status and a cycle time distribution with P50, average, and P95.
- Set optional targets for cycle time and automation rate against the current baseline. Activity is shown as a metric, but you can't set a target for it in 8.10.
- Every metric is calculated from completed process instances in the selected environment. No changes to your process models are required.
Catalog
The new Camunda Hub catalog gives your center of excellence (CoE) a governed, organization-wide place to publish approved element templates, so delivery teams can reuse trusted building blocks instead of rebuilding them in each project.
- Manage element templates and their metadata in your own Git repository, and use a CI/CD pipeline to publish them to the catalog through the Hub API whenever the approved set changes.
- Browse, search, and filter published assets in Hub, and read each asset's details before you apply it while modeling.
- See which assets are outdated and which workspaces and projects still use an older version, so you can prioritize migrations.
- Unpublish assets you no longer want used. Elements that already use an unpublished asset keep working and show a deprecation hint.
In 8.10, the catalog supports element templates as its only asset type.
Console
Console is now a top-level entry in the Camunda Hub navigation for organization owners, admins, and DevOps users, and the cluster references in Console point to the Environments and Clusters pages.
- SaaS: The cluster health and the cluster links on the Console dashboard open the clusters in Environments > Clusters. The cluster references on the organization page point to the same pages.
- Self-Managed: Console shows the dashboard and usage information. The cluster links open the clusters in Environments > Clusters, and the cluster list moved there from Console.
- Self-Managed: Each instance of a management component has its own entry on the dashboard.
Duplicate a cluster in Console
With Camunda 8.10, you can now duplicate a cluster in Console without manually re-entering its settings. Selecting Duplicate opens the create-cluster form pre-filled with the source cluster’s configuration, ready for you to review and submit.
Process data is not copied to the new cluster, and each API client receives a new client ID and secret.
Environments
Environments are the new deployment targets where teams run their processes in Camunda Hub. A cluster remains the infrastructure that administrators manage, and an environment is hosted on a cluster.
- Organization admins assign environments to workspaces, in the Camunda Hub interface or with the Camunda Hub API. Every project in a workspace can deploy to all the environments assigned to the workspace.
- Projects no longer connect clusters to deployment stages. The deploy dialog and the Test tab list the environments of the workspace, with their tags, version, and status.
- In Self-Managed, each Physical Tenant of a cluster at version 8.10 or later is an environment. In SaaS, each cluster has one environment.
- The Environments page shows every environment of the organization with its status, opens its applications, and shows a summary of its jobs.
- Organization admins can require an approved project snapshot before anyone deploys to an environment tagged
prod. - When you upgrade, Camunda Hub assigns the clusters that your projects used to their workspaces as environments.
Connectors
App Integrations connector
Use the App Integrations connector to send and receive messages in Microsoft Teams and Slack.
Send messages: You can send Microsoft Teams and Slack messages without managing credentials. The connector sends messages to Microsoft Teams and Slack, and creates channels, through your organization's Camunda app integrations. The connection is configured once for the environment, so no endpoint or credentials appear in the process model.
Receive messages: You can receive Microsoft Teams and Slack messages in a process. A process can start from a message someone writes to the Camunda app in Microsoft Teams or Slack, and a process that is already holding a conversation receives the reply, so an approval, a choice, or a correction can be collected in the chat people are already in rather than in a separate form.
AWS Connectors updated to AWS SDK for Java v2
All AWS connectors are updated to use AWS SDK for Java v2.
This ensures Camunda AWS connector implementations use supported client libraries and reduces maintenance risk, as AWS SDK for Java 1.x reached end of support on 31 December 2025.
Connector Management observability
Connector Management now provides a unified view of inbound and outbound connectors.
- The refreshed experience adds status summaries, search, filtering, sorting, per-runtime health and metrics, richer process details, clearer activity logs, and direct links to Operate.
- Operators can also reset inbound connector executables from the UI, while webhook activity logs expose redacted request metadata and bounded body previews to make troubleshooting easier.
Connector search improvements
You can now find a connector by the operation you want to perform. Built-in connector templates now describe their operations, so you can model by the action you want to take instead of the product that provides it.
- Searching in the create, append, or change element menu for
upload objectorsend emailreturns the matching operations of every connector as their own entries, and selecting one applies the connector with that operation preselected. - Connectors with several operations show their operations as a nested menu, and the operation selection is now the first group in the properties panel.
- Connectors that provide a single operation are also renamed to describe their action. For example, the REST Outbound Connector is renamed to Send REST Request. Existing process models are unaffected.
Integrate a built-in connector
Storage connector improvements
The following improvements are made to storage connectors (S3, Azure Blob, GCS):
- Support for direct object creation from variables and better content extraction for document references.
- Generation of .json, .txt, .csv, or binary files inline without relying on the Document Store. Documents with incorrect content-types can be read using conversion options (for example, "read as text", "read as JSON").
Helm chart deployment
Application configuration Helm keys deprecated
Helm chart values that only proxy a single application property are deprecated in favor of the component's extraConfiguration, so application settings live in the component's own configuration. The deprecated keys continue to work in 8.10, and setting one to a non-default value logs a deprecation warning.
Understand Helm and application configuration responsibilities
Bitnami subcharts removed from the Helm chart
Starting in 8.10, the Camunda Helm chart no longer includes the bundled Bitnami subcharts for PostgreSQL, Elasticsearch, and Keycloak. Helm installations must connect to external infrastructure, such as managed databases and search services, Kubernetes operators, or customer-owned images.
If you still use Bitnami subcharts on 8.8 or 8.9, migrate to external or vendor-supported infrastructure on 8.9 before upgrading to 8.10. The 8.10 Helm chart has no Bitnami-based fallback. See the release announcement for details.
Migrate from Bitnami subcharts
Camunda Helm Toolkit
The new Helm migration and validation toolkit can help you upgrade from Camunda 8.9 to 8.10 on Kubernetes with Helm.
Use the toolkit to:
- Read your existing 8.9 Helm values (for example, values.yaml).
- Generate a sample 8.10 values file reflecting the recommended Helm CLI v4, Bitnami sub‑charts removal, Hub‑aware deployment patterns, and simplified application configuration.
- Create a migration report that lists the keys that were migrated automatically, flags keys that require manual decision (for example, infrastructure endpoints, security‑sensitive options), suggests where to find more information in the documentation, and can validate an existing 8.10 values file (for example, one drafted by hand or AI tool) against Camunda’s migration rules.
The CLI is non‑interactive, with clear exit codes and optional JSON output, making it suitable for humans using the command line, CI pipelines, and AI agents (for example, Claude Code, Copilot) that can use it as part of an automated migration workflow.
Camunda Hub replaces Console and Web Modeler in the Helm chart
Camunda Hub is a drop-in replacement for Web Modeler in the Camunda Helm chart, and Console is no longer a standalone deployment. The camunda/hub image serves both Console and Web Modeler features, and you enable and configure it with the camundaHub key.
- For standard deployments, only the top-level key needs to change: replace
console.enabledandwebModeler.enabledwithcamundaHub.enabled. - Existing Web Modeler Helm values keep working. A compatibility layer in the application honors the existing value structure, and deprecated keys are logged but not required to change immediately.
- Moving your values under
camundaHubis cleanup that you can do later. The upgrade guide documents the steps. - Review
camundaHub.restapi.resourcesafter upgrading, because Console now runs in the Hub REST API pod.
Consolidate Console and Web Modeler into Camunda Hub
Helm chart version matrix improvements
The Helm chart version information for Camunda 8 has been redesigned into a clear, tabular version matrix. This makes installation, upgrades, and troubleshooting easier and more predictable, especially in environments with frequent patch releases.
You can now:
- Quickly see which Helm chart version corresponds to each Camunda 8 minor and patch release, including alpha and stable tags.
- Check the release date and support status of each Helm chart.
- See which Helm CLI versions are supported by each chart.
- Jump directly to change logs and related references via links in the matrix.
Camunda 8 Helm chart version matrix
Helm CLI v3 and v4 support
Camunda 8.10 (chart 15.x) supports Helm CLI v3 (3.10 or later) and v4. With Helm CLI v3, the chart shows a warning when you run helm install or helm upgrade.
Camunda recommends Helm CLI v4 and supports it for the full release cycles of Camunda 8.9 and 8.10. Camunda supports Helm CLI v3 (3.10 or later) until February 10, 2027, when upstream support ends. After February 10, 2027, Camunda no longer supports Helm CLI v3. Customers who continue to use Helm CLI v3 after that date do so at their own risk.
Switching CLIs does not require a release-state migration. Helm runs on the client, and both CLIs read and write the same release-storage format. Use Helm CLI v4 for new installations. Switch existing deployments before Helm CLI v3 support ends.
Host network support for Orchestration Cluster pods
The 8.10 Helm chart adds orchestration.hostNetwork (default: false), which lets Orchestration Cluster pods share the host node's network namespace. This is useful in bare-metal or restricted network environments where pods must be reachable directly via the node IP rather than a cluster overlay network.
When orchestration.hostNetwork is set to true and orchestration.dnsPolicy is not set, the chart automatically uses dnsPolicy: ClusterFirstWithHostNet to preserve in-cluster DNS resolution. You can override this by setting orchestration.dnsPolicy explicitly.
orchestration:
hostNetwork: true
Improved TLS support in the Helm chart
The Camunda Helm chart now includes an optional TLS overlay, values-tls.yaml, that sets up trust for encrypted connections from Camunda components to your datastores and identity provider. You provide one PEM CA bundle through global.tls.caBundle, and the chart makes it available to every component in the format its runtime needs.
- Connect to Elasticsearch, OpenSearch, and PostgreSQL over TLS, including with self-signed or private CA certificates.
- Trust external OIDC issuers that use a private CA, such as Microsoft Entra, Okta, or an internal Keycloak.
- Use cert-manager to manage certificates, update the CA bundle, and verify that no plaintext fallback remains.
The overlay doesn't encrypt in-cluster pod-to-pod traffic. For TLS at the pod level, combine it with a service mesh.
Independent REST and gRPC TLS for the Orchestration Cluster
The Camunda Helm chart now configures REST TLS and gRPC TLS on the Orchestration Cluster independently, so you can run any combination of the two. You enable each mode with global.tls.orchestration.rest.enabled and global.tls.orchestration.grpc.enabled.
When you enable a mode, the chart also:
- Sets the backend protocol on the NGINX Ingress for the Orchestration REST and gRPC endpoints to match the TLS state.
- Derives the in-cluster endpoint schemes that clients such as Connectors and Web Modeler use to reach the Orchestration Cluster.
Your explicit overrides, such as webModeler.restapi.clusters and connectors.configuration, remain authoritative. If the Orchestration server certificate is self-signed or issued by a private CA, also set global.tls.caBundle so in-cluster clients trust it.
Configure Orchestration REST and gRPC TLS modes
IRSA Document store support
Camunda 8 Self‑Managed now supports using IAM Roles for Service Accounts (IRSA) with the AWS S3 document store:
- You can deploy Camunda 8 on Amazon EKS with the document store configured for S3 without providing static AWS credentials.
- The Helm chart no longer requires AWS access keys when IRSA is in use and allows pods to rely solely on their IAM role for S3 access.
- Existing deployments using static AWS keys can migrate to IRSA following documented steps.
Refer to the following updated Helm configuration and secret management documentation for more details:
- See IAM Roles for Service Accounts (IRSA) for the IAM role and trust policy, Helm chart configuration, service account annotations, and verification steps for the AWS S3 document store.
- See document handling configuration in Helm for AWS S3 document store options.
- See Helm charts secret management to learn how static AWS credentials take precedence over IRSA.
PostgreSQL databases are highly available by default
The operator-based infrastructure reference architecture now deploys each CloudNativePG cluster with two instances instead of one, on a dedicated write-ahead log (WAL) volume, and requires the two instances of a cluster to sit on different nodes.
A single-instance cluster gives CloudNativePG no switchover target, so the operator refuses to evict it and kubectl drain never completes. Because a Kubernetes upgrade drains one node at a time, that stalls the upgrade on whichever node holds a database. A second instance gives the operator somewhere to switch over to. The dedicated WAL volume keeps the write-ahead log that a standby's replication slot retains from growing into the data directory.
Deployments already running the single-instance shape migrate in place: CloudNativePG clones the standby from the running primary and relocates pg_wal onto the new volume, with no dump or restore. Environments that cannot host a second instance, such as local Kind clusters, can pass PG_INSTANCES=1 to deploy.sh.
High availability and node maintenance
Integrations
Camunda for Slack
Camunda for Slack brings tasks, processes, and notifications into Slack through the same App Integrations backend as Microsoft Teams. Everything runs through the /camunda slash command, the Camunda direct message, and channel mentions. There is no tab app.
- List and filter tasks, claim and release them, and complete a task from a Block Kit modal.
- Start a process, and switch organization and cluster.
- Subscribe a channel or direct message to user task notifications.
- Use Slack with the App Integrations connector in both directions: a process can send a Slack message, and a Slack message can reach a process.
Microsoft Teams and Slack are independent. You can run either on its own, or both against the same backend.
Microsoft Teams routing and permission-aware task actions
Camunda for Microsoft Teams now supports routing incident and task collaboration to private channels, shared channels, and group chats. Notifications and task actions in Teams now align with Camunda assignment and access rules, ensuring that only eligible users are notified and allowed to act.
Modeler
BPMN element menu improvements
The create, append, and change menus now group BPMN elements by category, such as tasks, gateways, events, and so on. Each category includes a short description so you can quickly find the right element.
- Search still searches across all categories.
- When appending, elements that continue a flow subtly indicate where the flow continues next. Select this to open the append pad with a prominent Append action.
Decoupled element template lifecycle
Element templates now have a lifecycle independent of process application versioning in Web Modeler.
- Publish and version element templates on their own, without creating a process application version.
- A clear separation between template publishing and process app versioning removes unexpected coupling and side effects between template changes and business-logic versioning.
- Architects managing reusable templates across teams and environments get a more predictable mental model.
Existing templates are automatically migrated to the new lifecycle model; no manual action is required.
Define operations in your own element templates
Element templates support the steps and presets keys to offer several predefined configurations within a single template. Use steps to define the menu users navigate when they apply the template, and presets to define the property values each operation applies. Operation names, descriptions, and keywords are matched by search, so your operations are as discoverable as the templates themselves.
FEEL context variables for the process instance
The process instance properties are now accessible in FEEL expressions via the camunda.processInstance context, resolvable anywhere in the process. camunda.processInstance.key returns the process instance's system-generated key, and camunda.processInstance.businessId returns its business ID (or null if none is set).
Hide the Add members button
In Self-Managed, you can now hide the Add members button on the workspace Members page, preventing non-organization admins from adding members via the UI. They can still add members via the modify collaborator API endpoint if granted access.
Low-code assertions
Turn process instance runs into repeatable tests. Run a process instance, observe the output, then save the input data and assertions as a low-code integration test. That test now catches regressions on every change.
- Add variable assertions to saved test cases using CPT-compatible names and values for interoperability.
- Add path assertions that require specific elements or end events.
- View pass/fail results based on assertions, not just "process completed without incidents".
- Manage test metadata and assertions in one place in the Test tab.
Low-code test CI/CD compatibility
Test files in Test Studio now use the same schema as Camunda Process Test (CPT). You can record a test in Test Studio and run it in your CI/CD pipeline through CPT without converting formats, and load CPT-authored test files into Test Studio to debug them visually.
- Use one JSON schema across Test Studio and CPT: record once, run anywhere.
- Existing Play test scenario files are migrated automatically to the new format.
Low-code test repair
Saved test cases survive diagram changes. When a BPMN element is deleted, renamed, or changed type, Test Studio now tells you which steps broke and lets you fix them in place instead of re-recording the run.
- See a broken-step indicator on the test case in the list, and a per-step warning explaining exactly which reference no longer resolves.
- Repair a step inline: re-map it to another element, pick a valid value, or delete the step.
- Repair covers execution instructions and assertions, including variable, element-instance, user-task, process-instance, message-subscription, and decision assertions.
- Open the test file editor from a broken test case for advanced edits that the graphical flow does not cover.
- Rerun immediately after repair to confirm the fix.
Modeling menu improvements
When you create, append, or change an element, the menu groups insertion options into two tabs:
- BPMN: Standard BPMN elements, organized by their usual categories.
- Reusable assets: Assets, connectors, and templates from your project, along with existing project resources such as forms, called processes, decisions, and RPA scripts.
Find reusable assets in the modeling menus
New organizational structure for workspaces and projects
A new organizational structure for workspaces and projects is introduced in 8.10.
With this new file resource hierarchy:
- Workspaces now only contain projects and IDP projects.
- Files and folders are stored inside projects.
- Previously, a workspace (called a project in Web Modeler) could contain process applications (now projects), folders, and files.
The new Workspace > Project > File/folder hierarchy makes resources more discoverable and your workspaces more scalable.
Your SaaS Web Modeler data, now part of Camunda Hub, was updated during the 29 August 2026 maintenance window to support this new structure.
Project versioning model
A new versioning model for workspaces, projects, and file resources is introduced in 8.10. Workspaces now only contain projects and IDP projects on the root level. Folders and files are stored inside projects. Projects: The new project versioning model uses snapshots to save the current state of all the project files, in a single action. This helps you track a project throughout its development lifecycle and ensures the correct state is referenced.
File versioning: Every BPMN diagram, DMN diagram, form, RPA script, README file, and test file keeps a version history, a single timeline of the autosaves and named versions created as you work. You can open that history to view an earlier state of the file, compare any two entries, restore an entry, or copy one to another project.
Runtime connection targets environments
In Camunda Hub, the runtime connection of the modeler is a connection to an environment instead of a cluster. Select the environment from the modeling toolbar to model against.
- Connector-credential names of the connected environment autocomplete in your FEEL expressions.
- Task testing runs in the connected environment.
- Two Physical Tenants on the same cluster are separate connections.
The runtime connection is disabled by default and behind the feature flag runtimeConnectionEnabled. The properties-panel connector-credential picker additionally requires credentialsEnabled.
Safe deletion with a 30-day recovery window
Deleting an item in Camunda Hub no longer removes it immediately. Deleted workspaces, projects, files, folders, and IDP projects are moved to Recently deleted for 30 days. During that time, users with the appropriate permissions can see who deleted an item and when, and restore it. After 30 days, items are permanently deleted.
Deletion no longer corrupts project version history, as existing snapshots continue to reference deleted files correctly. The recovery window applies to deletions made in 8.10 and later; items deleted before upgrading cannot be recovered.
Start a process instance with a business ID
You can now set a business ID when starting a process instance directly from Camunda Hub or Desktop Modeler. The business ID field is available in the start process instance dialog alongside variables.
Support for configurable headers for execution listeners
Execution listeners now support configurable headers, aligned with service task job headers.
- In BPMN, execution listeners can define
<zeebe:taskHeaders>. The headers are passed to the listener’s job worker alongside any base-element headers, with listener headers overriding on key conflicts. - In Modeler, you can configure execution listener headers visually (name/value pairs) without editing BPMN XML.
- Listener workers can consume these headers as metadata and configuration parameters using the same patterns as service task job workers.
Support for start forms in Desktop Modeler
Desktop Modeler now supports defining form references on none start events in Camunda 8 BPMN models, matching the existing Camunda Hub capability.
You can configure start forms directly in Desktop Modeler's properties panel using:
- Camunda Form (linked): Reference a deployed Camunda Form by ID.
- Camunda Form (embedded): Embed form JSON in the BPMN diagram (deprecated).
Start forms can now be defined and edited in both modelers, ensuring a seamless experience when working with diagrams across Camunda Hub and Desktop Modeler.
Task testing supports call activities
Task testing now supports call activities in both Desktop Modeler and Camunda Hub. Testing a call activity starts the deployed called process, shows its progress in the execution log with a link to open it in Operate, and reports incidents raised inside it.
Test process segments in Play
When testing your process with Play in Camunda Hub, you can now capture and rerun targeted sections of a process as low-code integration tests:
- Run segment tests individually or in batches to validate process changes faster.
- Test BPMN elements like connectors, DMN, forms, and LLM tasks without a full end-to-end run.
- Reuse saved segment tests during iterative model changes to catch regressions earlier.
Variables panel improvements
When you hover over "written in X elements" or an element ID in the variables panel, the diagram now highlights the corresponding element or elements so you can quickly see where a variable is used.
FEEL expressions in the variable outline now use the same syntax highlighting as the FEEL editor, with more granular tokens that distinguish function names from arguments and operators from literals, making complex expressions easier to read.
When no element is selected on the canvas, the variables panel now highlights the process (root) scope, matching how it highlights the scope of a selected element. Variable value previews also no longer repeat the opening brackets of nested objects and arrays, so previews are easier to scan.
Optimize
Client bearer tokens are now classified for permission checks
Optimize now classifies each bearer token as belonging to a user or a machine-to-machine (M2M) client, using camunda.security.authentication.oidc.username-claim and client-id-claim, and enforces your configured Optimize permission only on tokens it classifies as a user's. A token Optimize can't classify is treated as belonging to a user, and checked against your configured Optimize permission.
Optimize authentication in Self-Managed
Delete a process definition's data via API
Optimize now exposes a public API endpoint to delete all analytics data for a given process definition, so you can remove data for retired processes or respond to data removal requests without manually touching Elasticsearch or OpenSearch. The deletion runs asynchronously: the API accepts and queues the request, then processes it in the background.
Delete process definition data
Object variables no longer flattened by default in Self-Managed
Starting in 8.10, Optimize no longer flattens object variables by default in Self-Managed deployments.
Object variables are not flattened into per-property fields, and their raw values are no longer stored. This significantly reduces Optimize storage and CPU usage and aligns Self-Managed with the default Camunda 8 SaaS behavior.
-
If you rely on object variable properties in reports, filters, or Raw Data Reports, you can opt in by setting
zeebe.includeObjectVariableValue: true(envCAMUNDA_OPTIMIZE_ZEEBE_INCLUDE_OBJECT_VARIABLE=true). -
If the setting is not explicitly configured, Optimize logs a
WARNon startup stating that object variables will not be flattened, and details the opt-in setting. -
SaaS deployments are unaffected as this behavior is already disabled.
Recovery: The Optimize importer is idempotent. As long as the object variables still exist in the zeebe-record-variable\* indices (within your Zeebe retention window), you can enable the flag and reset the importer to reimport/flatten historical variables.
Object variables configuration
Optimize data filters
You can now configure Optimize data filters directly in cluster settings, without editing Helm values or configuration files.
The Data filters section in cluster settings lets you:
- Enable or disable Optimize export filtering per cluster.
- Include or exclude process definitions by exact
bpmnProcessId. - Include or exclude variable names by prefix — for example,
business_includes all variables whose names start withbusiness_. - Exclusion takes precedence over inclusion when both are configured.
New SaaS clusters include a default business_ variable include filter, which limits Optimize to variables starting with business_ to reduce Elasticsearch storage and shard usage. Existing clusters show data filters disabled with a one-click opt-in — no automatic migration occurs.
Saving filter changes triggers a rolling restart of the Orchestration Cluster; the cluster is briefly unavailable while it restarts.
Filtered records are permanently excluded from Optimize and cannot be recovered even if you relax the filters later.
Configure Optimize data filters
Optimize disabled by default on new trial clusters
On new trial clusters in Camunda 8 SaaS, Optimize is now disabled by default. When Optimize is disabled, the overview shows a muted tile with an Enable Optimize prompt so it stays discoverable.
Upgrading from a trial to a paid plan automatically enables Optimize, with no manual action required.
Scope-aware variable export configuration for Optimize
You can now configure variable export behavior by scope:
- You can enable or disable root (process instance) variables and local variables independently.
- You can exclude all local variables by default, while still allowing specific local variables by name pattern.
- Configuration integrates with the existing variable filtering mechanism, using consistent syntax and semantics.
Terminology aligns with Camunda 8 docs:
- Root scope/process instance scope: Variables visible across the process.
- Local variables: Variables defined in child scopes only.
With this, you can configure setups such as:
- Export only root variables for all processes.
- Export a curated subset of local variables (for example,
taskContextDisplayNameor specific local audit variables) without exposing all locals.
Orchestration Cluster
Bespoke cluster generations for SaaS
Organizations can now access exclusive Camunda 8 generation versions tailored specifically for their organization, available for both new cluster creation and upgrades. These generations are not visible to other organizations.
Bring your own identity provider per cluster in SaaS
You can now connect your own identity provider to individual clusters in Camunda SaaS. Each Orchestration Cluster authenticates users through its own OIDC connection instead of Camunda's built-in organization identity provider, so you can enforce your own security and compliance policies.
- Configure the OIDC connection per cluster, including standard OIDC parameters and custom claims mapping with mapping rules.
- Migrate from the built-in provider with minimal disruption to existing user authentication.
Web Modeler and Console continue to use Camunda's built-in identity provider. Only Orchestration Clusters use your identity provider directly.
Business ID in message correlation
You can now include a business ID when publishing or correlating a message. Business ID acts as an additional filter alongside the message name and correlation key.
Supported combinations for start events: message name alone; name + business ID; name + correlation key; name + correlation key + business ID. For non-start events, business ID is usable alongside name + correlation key. When both a correlation key and business ID are provided, both fields must match the corresponding values stored on the subscription.
If business ID uniqueness is enabled, a blocked message-start waits in the buffer until the active instance releases the business ID or the TTL expires — it is not dropped immediately.
Business ID in message correlation
Business ID propagation in call activities
Call activities now support configuring the business ID assigned to the child process instance. Child instances inherit the parent's business ID by default (unchanged from 8.9). You can override this per call activity with a literal value or FEEL expression. The FEEL context variable camunda.processInstance.businessId provides access to the parent's ID within the expression.
The resolved value is set once at child creation and is immutable.
Cancel execution listener
Execution listeners now support a cancel event type on the process element. Cancel listeners run when a process instance is terminated — useful for cleanup, audit logging, or notifying external systems.
Centralized Secret Resolution via Zeebe
Centralized secret resolution through Zeebe is introduced in 8.10.
Processes can reference credentials from customer-managed secret stores without persisting secret values in Camunda.
- Reference secrets as
camunda.secrets.NAMEin input mappings, expressions, and output mappings. The legacy{{secrets.NAME}}syntax continues to work. - Secrets are resolved automatically for activated jobs and can also be requested through the Gateway APIs
/v2/secrets/resolveand/v2/secrets/list. - Resolved values are not written to engine state, exports, backups, Operate, Tasklist, or application logs.
- Self-Managed deployments support AWS Secrets Manager and GCP Secret Manager with workload identity authentication. A file-based provider is available for development and testing.
- SaaS requires no configuration and uses Camunda’s managed secret backend.
- Camunda 8 Run uses the file-based provider: create one file per secret (filename = secret name, contents = value), and set
camunda.secrets.stores.file.default.pathto that directory in the Camunda 8 Run application configuration.
Migration: Existing processes continue to work without changes. For new processes, use camunda.secrets.NAME. To migrate hardcoded or connector-specific credentials, store the value in a supported secret store and replace it with a centralized secret reference.
Limitations: This feature does not yet include HashiCorp Vault or Azure Key Vault support, secret access audit logging, per-process secret restrictions, or centralized resolution for Hybrid Connector Runtimes. Cache entries expire after the configured TTL, which is 20 seconds by default.
Cluster variable metadata
You can now add metadata to cluster variables as a map of string keys to scalar values (strings or numbers). Camunda stores the metadata alongside the variable but keeps it separate from its value.
Use metadata to discover and filter variables by semantic attributes without inspecting their values. The search endpoint supports metadata filters with equality, numeric range, existence, in, and like operators for each key. Metadata is not exposed as part of the FEEL-accessible runtime value.
Cluster version selection for SaaS
You can now create new SaaS clusters on specific supported Camunda 8 minor and patch versions, including:
- The latest recommended versions (latest patch of each active minor)
- Other still-supported versions that you already run on existing clusters in the same organization.
Cross-region cold recovery for SaaS
If a primary region fails, you can now recover your SaaS Orchestration Cluster in a secondary region from replicated backups, without depending on a support request. Cross-region cold recovery creates a new Orchestration Cluster in the secondary region and restores the backup you select.
- Enable dual-region backup when you create the cluster, and select the backup location in Console.
- Start failover in Console or through the API, and select the backup to restore from.
- Cold recovery is available for AWS and GCP clusters in region pairs marked Failover supported, including AWS clusters that use Bring Your Own Key (BYOK).
- Use only the recovered cluster after failover. Don't run the original cluster at the same time, to avoid conflicting writes.
The data you can lose depends on the backup you select and your backup interval, because the recovered cluster contains only the data up to that backup.
Dark and light mode persists across Admin, Operate, and Tasklist
Dark mode and light mode preferences now persist across Admin, Operate, and Tasklist. Set your preference once and it applies across all Orchestration Cluster applications.
Default RocksDB memory allocation strategy changed to FRACTION
The default RocksDB memory allocation strategy changes from PARTITION to FRACTION. RocksDB memory is now allocated as a fraction of total available memory (default 0.1, or 10%) instead of scaling with the number of partitions per broker. This may result in a different amount of memory being allocated to RocksDB.
To keep the previous behavior, explicitly set the strategy to PARTITION. See the release announcement for more details.
Docker images
Camunda no longer produces the following Docker images in Camunda 8.10 and later, or in Camunda 8.9 from patch release 8.9.12:
Use the unified camunda/camunda Docker image instead.
Edit roles and tenants in Admin
You can now edit the name and description of a role or tenant directly in Admin, without deleting and re-creating it. Existing assignments stay in place.
- Default roles and the
<default>tenant are system entities and cannot be edited. - Role and tenant IDs cannot be changed after creation.
Job and process prioritization
Camunda 8.10 introduces support for job and process instance prioritization for pull-based job activation via gRPC and REST (including long polling).
- Users can assign an integer priority (for example, 0–99) to process instances and jobs via BPMN model attributes.
- Job workers can now opt into priority-aware activation, so that ActivateJobs (gRPC) and REST-based long-polling endpoints consider priority when selecting which jobs to return.
Late Business ID assignment
You can now assign a business ID to a running process instance that has none, using the POST /process-instances/{processInstanceKey}/business-id-assignment REST endpoint, the AssignProcessInstanceBusinessId gRPC command, or by including businessId in a job completion request. The assignment is single and irreversible, and only available while business ID uniqueness enforcement is disabled.
Multi-instance activity execution listeners
Execution listeners can now be configured on the enclosing body of multi-instance activities. beforeAll listeners run once per multi-instance body activation, before the inputCollection is evaluated and inner instances are created, making listener-produced variables available to the body's inputCollection expression.
- Replicate Camunda 7 multi-instance and execution listener patterns without redesigning your process.
- Dynamically calculate collections using custom logic or external data before instance creation.
Multi-tenancy support in SaaS
Camunda 8 SaaS now officially supports multi-tenancy via tenant identifiers, bringing the same logical tenant isolation model available in Self-Managed to SaaS clusters.
Multi-tenancy is available on SaaS clusters running generation 8.8 and later — including existing 8.8 and 8.9 clusters. You do not need to upgrade to 8.10 to use this feature.
- Owners and Admins can create, update, and delete tenants in Camunda Hub, and assign users, groups, and client credentials to them.
- Camunda Hub and Desktop Modeler support tenant-scoped deployments to multi-tenant clusters by specifying a tenant ID.
- Tenant usage is reflected in Camunda Hub reporting so org owners can monitor tenant consumption across a cluster.
Multi-tenancy is enabled at the cluster level. Process definitions, instances, and decisions are scoped to the tenant they were deployed to, keeping data isolated across teams and applications sharing a single cluster.
New AWS US West region
With the new Camunda 8 SaaS AWS US West (us-west-2) region in North America, you can deploy orchestration workloads with full US data residency and improved regional stability.
New GCP Montréal region
Camunda 8 SaaS now supports the Google Cloud Platform (GCP) Montréal, North America (northamerica-northeast1) region. Together with the existing Toronto region, you can now run process orchestration with your data hosted in Canada. To use it, select the Montréal region when you create a cluster in Console.
OIDC Diagnostic Logging
OIDC authentication failures now surface actionable diagnostics in application logs.
- Enable
camunda.security.authentication.oidc.diagnostics.enabledto log the redirect URI Camunda expects against the one your identity provider returned, and to flag a callback that arrives without a valid session, the two most common causes of a login redirect loop. - If you use Microsoft Entra as your identity provider, an app registration issuing v1 tokens now fails authentication with an explicit error naming the fix (
api.requestedAccessTokenVersion = 2) instead of looping silently.
Operate batch delete completed process and decision instances
Operate now supports deleting completed process instances and evaluated decision instances as a batch operation. When selecting finished instances from the list, you can use the new Delete batch action in the toolbar to remove multiple instances at once. A confirmation modal prevents accidental mass deletion.
Operate Business ID visibility and filtering
Business ID is now a first-class searchable attribute across Operate and the Orchestration Cluster API. Operations engineers can search and filter process instances, decision instances and user tasks by Business ID, enabling fast identification and investigation of business cases.
- Business ID is visible in Operate process instance lists, decision instance lists, details views, and filters.
- Advanced filtering supports exact match, not-equal, exists, and wildcard searches.
- Business ID participates in message correlation as an additional constraint alongside the existing correlation key.
- Business ID is visible in Tasklist task views for task workers to identify the associated business case.
Business ID filtering
Operate now exposes business ID as a filter field for process instances. You can filter using Equals, Contains (with * and ? wildcards), and Is one of — or use the full operator set ($eq, $neq, $exists, $like, $in, $notIn) via the API.
Visibility for decision instances
Business ID is now visible in Operate for decision instances, in both the decision instance list and the decision instance details view. Filter decision instances by business ID using Equals, Contains, and Is one of in the filter UI, or the full operator set ($eq, $neq, $exists, $like, $in, $notIn) via the API.
Business ID for decision instances
Visibility for process instances
Business ID is now visible in Operate for process instances. The businessId field appears in the process instance list and the process instance details view.
Business ID for process instances
Visibility for reference Documents
View documents attached to process instances directly in the Operate process instance detail view.
Documents display metadata (name, type, size, creation date) and support in-product preview for formats such as PDF, JSON, plain text, PNG, and JPG. Operators can now inspect agent memory, large payloads, connector attachments, and IDP source documents without leaving Operate or making API calls.
Operate JSON display improvements
The JSON display functionality in Operate for SaaS is improved. You can now:
- Open JSON variables in a dedicated JSON viewer directly from the variables panel, without entering editing mode.
- View JSON values with consistent, easier to understand formatting.
- Copy full JSON variable values to the clipboard.
- Use the improved in-line variables display.
These improvements help you navigate more complex data during operations and troubleshooting.
Operate multi-variable filtering
In Operate, you can now combine multiple variable filters with AND logic to find exactly the process instances you need.
Filter by variable name, value, and comparison operators, such as equals, contains, greater than, and less than, including nested JSON paths.
Operate wait state visibility
Operate now shows what an active process instance is waiting for.
- When you inspect an active element, you can see the wait state and its details, for example, a timer's due date, a receive task's message name and correlation key, a signal name, a condition expression, or a job's type and state.
- Wait state tracking is enabled by default and writes records to secondary storage. In Camunda 8 Self-Managed, you can disable it if you do not want to track this data.
Opt-in analytics exporter
Camunda 8.10 adds an opt-in analytics exporter for Self-Managed clusters. It is disabled by default, so you decide whether to enable it. When enabled, it shares product usage data with Camunda to help us prioritize improvements.
Physical tenants: strong tenant isolation in one Orchestration Cluster
Self-Managed Orchestration Clusters can now host multiple physical tenants. Each one is an isolated execution unit with its own Raft partitions, secondary storage (separate RDBMS schema, Elasticsearch/OpenSearch cluster, or prefixed indices), document store, exporters, and identity provider. Teams and business units get strong isolation without running a separate cluster for each.
- Operations: Back up and restore each tenant on its own, manage its partitions, exporters, and scaling separately, and monitor it with its own metrics and logs.
- APIs and clients: Clients pick a tenant through
/physical-tenants/{physicalTenantId}/v2/...on REST or theCamunda-Physical-Tenantheader on gRPC.CamundaClientsupports tenant selection, and a single Java/Spring client or Connectors runtime can serve multiple tenants. - Web apps: Operate, Tasklist, and Admin are available per tenant at
<baseurl>/physical-tenants/<physicalTenantId>/<webapp>and show only the selected tenant's data. - Identity: Each tenant enforces its own roles, mapping rules, and permissions, so a user can have different roles on different tenants. You define identity providers at the cluster level, and each tenant chooses which ones it accepts. Cluster-wide operations (topology, backups, restore) are protected by a claim-based cluster admin role.
Every cluster has a default physical tenant, so existing setups run unchanged. tenantId-based logical tenants still work inside each physical tenant. Physical tenants are defined in configuration and applied with a rolling restart. Upgrades apply to the whole cluster, and queries cannot span tenants. Data cannot be moved from a logical tenant into a separate physical tenant. Tenants can share brokers, and quotas between tenants are not included. SaaS is not supported yet.
Physical Tenant isolation model
Process instance suspension and resumption
You can now suspend and resume a running process instance without canceling it. Suspending halts execution at its current point: no jobs activate or complete, no events correlate, and no timers fire. Resuming picks up from exactly where execution stopped, with no loss of progress or data.
- Suspend or resume a single instance, or a batch of instances, from Operate or the REST API.
- You can still read and update variables on a suspended instance, so you can fix data before resuming.
- Timers that come due during a suspension fire immediately on resume. Messages and signals are not correlated to a suspended instance.
Suspend and resume a process instance
Rebalance API for coordinated leadership transfer
Coordinated leadership transfer for Orchestration Clusters is introduced in 8.10.
The existing rebalance endpoint asks every leader to step down at once and returns immediately, without guarantee that the intended broker wins the resulting election. The new rebalance API transfers leadership deterministically, ensuring transfer in most cases in a way that is both minimally disruptive and observable.
| Feature | Description |
|---|---|
| Coordinated rebalancing API | POST /cluster/v2/rebalance starts a rebalance, GET /cluster/v2/rebalance reports the cluster's balance state and the progress of each partition, and DELETE /cluster/v2/rebalance stops a running rebalance once the transfer in flight has finished. The endpoint requires cluster-admin credentials. |
| Deterministic transfers | Leadership is handed directly to the partition's highest-priority replica instead of being left to an open election, so a rebalance reaches the intended leader layout. |
| Minimal disruptions | Transfers are sequenced one partition at a time across the cluster, so at most one partition is affected at any moment, rather than every partition becoming leaderless simultaneously. |
| Configurable | The replication lag a desired leader is allowed to have, how long a partition may wait for that leader to catch up, and how long to wait for a leaderless partition can all be set as cluster defaults and overridden per request. When the desired leader cannot take over in time, the partition resumes under its current leader. |
| Observable | POST /cluster/v2/rebalance?dryRun=true returns the plan a rebalance would carry out, without pausing any partition or moving any leadership. Each partition reports how its transfer ended or why it was skipped (already led by the desired leader, replication lag too high, replication timed out, and so on), so an incomplete rebalance can be diagnosed easily. |
- The previous /actuator/rebalance endpoint continues to work unchanged, and is superseded by the new API.
- There are some cases where rebalancing is still not guaranteed, notably where the desired leader is simply not available or becomes unavailable during the operation. Such cases require manual retries once the desired leader of a given partition is back online.
Region-aware partition placement
Camunda 8.10 introduces region awareness to the Orchestration Cluster. Operators declare which region each broker belongs to using a topology label, and the engine uses those declarations to distribute partition replicas across regions, ensuring no single region holds a quorum for any partition.
Leader election priorities respect region boundaries, preferring region-local leaders under normal conditions and adjusting automatically when a region becomes unavailable. The same mechanism extends to availability zone or datacenter isolation using the same configuration.
Orchestration Cluster configuration properties
Restore API for Orchestration Cluster backups
You can now restore an Orchestration Cluster from a backup through the Restore API, without restarting the brokers or running the restore application on each broker. The Restore API works with Elasticsearch, OpenSearch, and relational database secondary storage. While a restore runs, the cluster is in recovery mode and processes no work.
- Switch the cluster into recovery mode and trigger the restore with two non-blocking requests. Each returns a
changeIdthat you use to track progress, so you can script and rehearse disaster recovery. - Restore from selected backups, and validate a request first with
dryRun=true, which returns the planned operations without changing the cluster. - In a cluster with physical tenants, restore your own tenant with
/v2/restore, or restore one or all tenants with/cluster/v2/restoreas a cluster admin.
S3-compatible object stores for Document Handling
Document Handling now supports any S3-compatible object store such as MinIO, Cloudian, or Garage alongside Amazon S3, Google Cloud Storage, and Azure Blob Storage.
- Configure an S3-compatible backend by pointing the existing AWS S3 document store to your custom provider endpoint.
- No migration is required for existing AWS S3 deployments.
Document handling configuration
Secure connectivity with AWS inbound PrivateLink for Camunda 8.7
Camunda 8.7 SaaS on AWS now supports inbound AWS PrivateLink with cluster authentication. Follow the Secure connectivity guide to configure your VPC endpoint.
Secure connectivity (AWS PrivateLink)
Select a DMN version with a FEEL expression
You can now call a dynamically calculated version of a DMN decision from a BPMN business rule task by specifying the version with a FEEL expression.
Select a target version when upgrading a cluster
When you upgrade an Orchestration Cluster that has more than one valid upgrade target, Camunda Hub now shows a version selection step in the upgrade wizard. Each option displays the generation name and the Zeebe patch version.
The recommended version (the longest upgrade path) is pre-selected and labeled latest, and you can choose a different option before proceeding. Clusters with only one upgrade target keep the existing flow.
Self-service restore for SaaS orchestration clusters from backups
Organization admins can now restore a SaaS orchestration cluster directly from a completed backup in Hub and via the Administration API.
- Reduced time to recovery for operational incidents.
- Operational control without opening a support ticket for standard same-cluster restores.
- Clear restore status visibility during execution.
During a restore, the cluster is unavailable until it completes.
Startup no longer depends on a reachable identity provider
The Orchestration Cluster contacts an OIDC provider at the first request that needs it, and not at startup. A provider that is still starting, or that is down, no longer stops the cluster from starting.
- Only the requests that need the unreachable provider fail, such as browser login requests and token-validation requests for that provider. All other requests succeed.
- A session that the cluster authenticated before the outage keeps its access token until the token expires. The refresh that follows fails, and the session ends.
- Each new request tries again. The traffic recovers when the provider answers, and you do not need a restart. The cluster holds no queue of failed requests, and it makes no attempt in the background.
- A failed request writes a warning that names the step that failed and the provider with its issuer, at most once each minute for each combination of step and provider. The warning follows the traffic, and it is not a health check of the provider.
Requests fail when an identity provider is unreachable
Startup warns about an incorrect OIDC configuration
The Orchestration Cluster checks its OIDC configuration at startup, without contacting the provider, and writes a warning for each problem it finds. The cluster still starts.
- The checks cover the client ID, the set of endpoints, the scope, and the shape of the redirect URI.
- A redirect URI with no callback path, or with a path that has no leading slash, falls back to
{baseUrl}/sso-callback. Any other unusable value stays as configured, and the login fails later. - The warnings come from the loggers
io.camunda.security.spring.oidc.ScopedClientRegistrationFactoryandio.camunda.security.spring.oidc.OidcRedirectionEndpoint.
Tasklist Business ID
Business ID is now visible in Tasklist, in both the task list and task detail views. Filter tasks by business ID using Equals, Contains, and Is one of in the filter dialog, or the $neq/$exists/$notIn operators via the API.
Unified authentication for the Orchestration Cluster and Optimize
Optimize can now be configured with the same camunda.security.authentication.* settings already used by the Orchestration Cluster, so you configure authentication once, in one place. Nothing changes for the Orchestration Cluster, which already used these settings in 8.9.
Optimize continues to accept its 8.9 authentication settings in 8.10, translating the recognized properties to their new equivalents at startup, but those 8.9 properties are deprecated and will be removed in a future release. Confirm your camunda.security.authentication.oidc.issuer-uri and .audiences settings match your IdP before upgrading Optimize.
User, group, role, tenant, and permission management for Optimize is unchanged in this release, and is still handled by Management Identity.
Optimize authentication in Self-Managed
Unified frontend application for Admin, Operate, and Tasklist
Operate, Tasklist, and Admin are now accessed from a single frontend application with shared navigation, consistent design patterns, and unified deployment. Your user preferences, such as dark or light mode, are applied across all views.
Upgrade readiness APIs
Self-Managed Orchestration Clusters now provide upgrade readiness APIs that report whether a cluster has finished the migrations and exports it needs before you upgrade to the next minor version.
Use them to avoid back-to-back minor upgrades that can put your secondary storage data at risk.
Usage & billing metrics for 2025 enterprise license model
Camunda Hub and Accounts now support the 2025 enterprise license model.
- A new
licensing_modelattribute onOrganizationMetaDataidentifies if an enterprise organization is using the 2025 or legacy license model. If unset, it is treated as legacy. - If you are an organization with
licensing_model = 2025, your Usage and Billing views only show Process Instance (PI) metrics. Decision Instance (DI) and Unique Task User (TU) information is no longer shown. Legacy organizations continue to see the existing metric set. - For enterprise (
salesplantype = enterprise) organizations, the licensing model is shown in the organization details. Admins can edit this by selecting either legacy or 2025 via a modal action. - The enterprise onboarding wizard now includes a license selection step (defaults to 2025). The
ExternalOnboardingRouteraccepts an optional licensing model parameter (defaulting to 2025 if not provided).
Reference architectures
Amazon ECS reference architecture
A new reference architecture details how you can run the full Camunda 8 stack on Amazon ECS, including Orchestration Cluster, Camunda Hub, and Management Identity.
What’s included:
- A reference architecture diagram and dependency overview for ECS.
- A Terraform‑based reference deployment paired with step‑by‑step documentation.
- Guidance for:
- Networking, storage, secrets, and IAM (including IRSA where relevant).
- Basic Day‑2 operations (scaling, updates, troubleshooting entry points).
This helps support Amazon ECS as a first‑class, documented deployment option for Camunda 8 Self‑Managed, alongside Kubernetes.
Dual-region Amazon ECS reference architecture
A new dual‑region reference architecture details how you can run the Orchestration Cluster and Connectors on AWS ECS with RDBMS secondary storage (such as Aurora Global Database).
What's included:
- Recommended topology, exporter configuration, and RDBMS replication setup.
- Step‑by‑step failover and failback procedures so your platform team can design, deploy, and operate an active‑active (or active‑passive) two‑region ECS environment that meets enterprise HA/DR requirements without bespoke architecture work.
Dual-region ECS reference architecture
Kubernetes reference architecture updated for Camunda Hub
With Camunda 8.10, the Kubernetes reference architecture is updated to reflect the Camunda Hub-based deployment model:
- The architecture diagrams now separate Camunda Hub from the Orchestration Cluster, aligning with the recommended production topology.
- The documentation clarifies how a single Camunda Hub can manage multiple Orchestration Clusters, which components are deployed with each, and how this split maps to Kubernetes namespaces and services.
- Updated guidance and configuration examples help you adapt the reference architecture to your environment.
Use this updated reference architecture as the starting point for new 8.10+ deployments, and as a guide when you evolve existing clusters toward a Camunda Hub-centric model.
Kubernetes reference architecture
Multi-region RDBMS reference architecture
A new multi-region reference architecture details how you can design, deploy, and operate one Orchestration Cluster stretched across three or more Kubernetes regions, where the Zeebe data plane is active-active across every region and the relational secondary storage is active-standby, with a single global writer and replication owned by the database.
What's included:
- A zone-aware topology for primary storage that keeps its Raft quorum when a region is lost, so processing continues without an operator step.
- A multi-region RDBMS as secondary storage, with the asynchronous replication monitoring that lets Zeebe replay exported records after a writer failover.
- Cross-region networking, zone activation, region loss, and failback procedures for a reference implementation on Amazon EKS.
This architecture removes the recovery procedure rather than the recovery window: no operator step restores Zeebe processing after a region loss, while re-election, client rerouting, and database writer promotion still take time.
Secondary storage
Archive by ID for Elasticsearch and OpenSearch
Archiving of finished process instance data in Elasticsearch and OpenSearch secondary storage now uses a targeted, incremental approach by default.
- Documents are moved in small, targeted batches rather than in a single operation, improving stability and reducing resource pressure during archiving.
- The
rolloverBatchSizeandreindexBatchSizeproperties control how many process instances and individual documents are processed per batch.
Async replication support for RDBMS secondary storage
Camunda 8.10 adds first-class support for asynchronously replicated relational databases as secondary storage, including AWS Aurora and PostgreSQL.
- The exporter layer detects when the active RDBMS endpoint is unreachable, including during a standby promotion or cross-region failover, and pauses export operations automatically rather than entering an error state. Export position is preserved in the Zeebe log and replayed on reconnection.
- After failover, a reconciliation path replays missing events from the Zeebe log to close any replication lag gap, restoring a consistent secondary storage state without manual data repair. A single-exporter configuration is now supported for deployments where the RDBMS handles cross-region replication natively.
Elasticsearch 9.x and OpenSearch 3.x support
Camunda 8.10 supports Elasticsearch 9.4+, Elasticsearch 8.19+, OpenSearch 3.5+, and OpenSearch 2.19+. Operators can upgrade their search layer to the latest certified versions without impact on process history, active instance visibility, or incident management.
Elasticsearch index sizing and replication
New comprehensive Elasticsearch configuration documentation explains how to:
- Size your Elasticsearch cluster for Camunda 8 workloads.
- Configure index replicas to achieve fault‑tolerant indices in multi‑node clusters.
- Adjust retention and rollover intervals to avoid oversharding while meeting your data‑retention requirements.
This documentation helps Self‑Managed customers:
- Avoid oversharding (too many shards per node).
- Prevent index unavailability and related Operate/Tasklist errors.
- Reduce Elasticsearch‑related incidents in production.
Install Camunda for production with Helm
New RDBMS version support
Camunda 8.10 adds support for new relational database versions. Operators running Self-Managed Camunda clusters can upgrade their database layer to the latest supported versions without disruption to running process instances.
New supported versions include Amazon Aurora PostgreSQL 18, MariaDB 12.3, Microsoft SQL Server 2025, and MySQL 9.7.
Rolling upgrades
You can now perform rolling upgrades of self-managed Camunda 8 between patch and minor versions with zero downtime across all supported secondary storage backends, including Elasticsearch, OpenSearch, and relational databases.
- The cluster stays operational during a rolling upgrade: workflows continue executing, and Operate remains accessible for monitoring and incident response.
- Schema changes between versions are strictly backwards-compatible and applied transparently.
8.10.0-alpha5
| Release date | Changelog(s) | Blog |
|---|---|---|
| 8 September 2026 | - |
Agentic orchestration
AI Agent connector: new native element templates
The AI Agent Task and AI Agent Sub-process connectors are now available as new, native element templates, running on new job types and giving native access to each LLM provider's own SDK and wire format, including extended thinking and prompt caching configuration where supported.
Provider and backend selection are now decoupled: for example, the Anthropic provider can run through AWS Bedrock Mantle, and the OpenAI provider through Microsoft Foundry (Azure), while keeping each provider's own configuration options. The legacy element templates are deprecated as of Camunda 8.10.
This is a major redesign of the AI Agent connector, available from 8.10 only, and requires manually migrating each element from the still-functioning legacy connector.
See the release announcement for more details.
The legacy connector is deprecated in 8.10, but is not removed and continues to work. Adopting the new template is a manual, per-element migration, not an automatic upgrade.
Improved agent tool configuration
New features help you more easily configure your agent tools when modeling.
| Feature | Description | Available in |
|---|---|---|
| Fix | Automatically detect and apply a safe fix for an agent misconfiguration.
|
|
| Input from agent, Output to agent | Automatically fill in the fromAi() inputs or the toolCallResult output configuration of an agent tool contract.
|
|
| Lint rule checking | Agent tool configuration lint rule checking helps you avoid agent misconfiguration and errors when modeling.
|
|
- Changes are explicit, apply only when the correction is deterministic, and can be undone.
- These configuration features are only available inside an ad-hoc sub-process marked as agentic through either the
io.camunda.agenticai.toolContainerproperty or an out-of-the-box AI Agent element template. It is not available in a plain sub-process. You might need to update your element template to use this new feature.
Real-time agent visibility and monitoring
Monitor and evaluate AI agent behavior in Operate.
- View each agent's execution state (thinking, calling a tool, idle) highlighted on the process diagram, as well as its current tool calls, usage metrics (tokens, tool calls, and model calls against the configured limit), model, and system prompt.
- Trace the full reasoning chain behind AI agent decisions in the conversation history such as user prompts, assistant messages, tools selected with the agent's reasoning, and tool calls with navigation to the corresponding diagram elements, so you can see exactly which messages, inputs, and tool responses informed each of the agent's next steps.
- External agents built with frameworks such as LangGraph or CrewAI get the same visibility through the new Agent Instance API.
Monitor your AI agents with Operate
If you modeled the agent element before Camunda 8.10, you must update its element template to at least v1 (version 13) or v2 to enable this feature.
Camunda design system
The new Camunda visual design system is introduced with this alpha for Self-Managed deployments.
- A new, streamlined design system offers a cleaner, more consistent look across components.
- Accessibility improvements are built in, and the updated navigation menu makes it easier to find your way around.
- The new design system is enabled by default in Self-Managed for Camunda Hub and Operate.
The new design system will be introduced for SaaS deployments with the 8.10 minor release.
Camunda Hub
Modeling menu improvements
When you create, append, or change an element, the menu groups insertion options into two tabs:
- BPMN: Standard BPMN elements, organized by their usual categories.
- Reusable assets: Assets, connectors, and templates from your project, along with existing project resources such as forms, called processes, decisions, and RPA scripts.
Find reusable assets in the modeling menus
New organizational structure for workspaces and projects
A new organizational structure for workspaces and projects is introduced with this alpha.
With this new file resource hierarchy:
- Workspaces now only contain projects and IDP projects.
- Files and folders are stored inside projects.
- Previously, a workspace (called a project in Web Modeler) could contain process applications (now projects), folders, and files.
The new Workspace > Project > File/folder hierarchy makes resources more discoverable and your workspaces more scalable.
Your SaaS Web Modeler data, now part of Camunda Hub, was updated during the 29 August 2026 maintenance window to support this new structure.
Project versioning model
A new versioning model for workspaces, projects, and file resources is introduced with this alpha. Workspaces now only contain projects and IDP projects on the root level. Folders and files are stored inside projects.
Projects: The new project versioning model uses snapshots to save the current state of all the project files, in a single action. This helps you track a project throughout its development lifecycle and ensures the correct state is referenced.
File versioning: Every BPMN diagram, DMN diagram, form, RPA script, README file, and test file keeps a version history, a single timeline of the autosaves and named versions created as you work. You can open that history to view an earlier state of the file, compare any two entries, restore an entry, or copy one to another project.
This new versioning model will be introduced for Self-Managed deployments with the 8.10 minor release.
Runtime connection in Camunda Hub
You can now view and choose which cluster you are connected to in Camunda Hub.
- Connector-credential names from the cluster autocomplete in your FEEL expressions.
- Task testing runs against the connected cluster.
- Choose the cluster from the bottom panel bar of the diagram, in the Implement tab, to model against your real environment.
Connectivity
Secure connectivity with AWS inbound PrivateLink for Camunda 8.7
Inbound AWS inbound PrivateLink with cluster authentication is now supported for Camunda 8.7 SaaS on AWS. Follow the Secure Connectivity (AWS PrivateLink) guide to configure your VPC endpoint.
Secure connectivity (AWS PrivateLink)
Connectors
AWS Connectors updated to AWS SDK for Java v2
All AWS connectors are updated to use AWS SDK for Java v2.
This ensures Camunda AWS connector implementations are using supported client libraries and reduces maintenance risk, as AWS SDK for Java 1.x reached end of support on 31 December 2025.
Connector Management observability improvements
Connector Management now provides a unified view of inbound and outbound connectors in Camunda Hub.
- The refreshed experience adds status summaries, search, filtering, sorting, per-runtime health and metrics, richer process details, clearer activity logs, and direct links to Operate.
- Operators can also reset inbound connector executables from the UI, while webhook activity logs expose redacted request metadata and bounded body previews to make troubleshooting easier.
Storage connector improvements
The following improvements are made to storage connectors (S3, Azure Blob, GCS):
- These connectors now support direct object creation from variables and better content extraction for document references.
- You can now generate .json, .txt, .csv, or binary files inline without relying on the Document Store. Documents with incorrect content-types can be read using conversion options (for example, "read as text", "read as JSON").
Helm chart deployment
Elasticsearch index sizing and replication
New comprehensive Elasticsearch configuration documentation explains how to:
- Size your Elasticsearch cluster for Camunda 8 workloads.
- Configure index replicas to achieve fault‑tolerant indices in multi‑node clusters.
- Adjust retention and rollover intervals to avoid oversharding while meeting your data‑retention requirements.
This documentation helps Self‑Managed customers:
- Avoid oversharding (too many shards per node).
- Prevent index unavailability and related Operate/Tasklist errors.
- Reduce Elasticsearch‑related incidents in production.
Install Camunda for production with Helm
Helm migration and validation tool
The new Helm migration and validation tool can help you upgrade from Camunda 8.9 to 8.10 on Kubernetes with Helm.
Use the tool to:
- Read your existing 8.9 Helm values (for example, values.yaml).
- Generate a sample 8.10 values file reflecting:
- Bitnami sub‑charts removal.
- Hub‑aware deployment patterns.
- Simplified application configuration.
- Produce a migration report that:
- Lists the keys that were migrated automatically.
- Flags keys that require manual decision (for example, infrastructure endpoints, security‑sensitive options).
- Suggests where to find more information in the documentation.
- Can validate an existing 8.10 values file (for example, one drafted by hand or by an AI tool) against Camunda’s migration rules.
The CLI is non‑interactive, with clear exit codes and optional JSON output, making it suitable for humans using the command line, CI pipelines, and AI agents (for example, Claude Code, Copilot) that can use it as part of an automated migration workflow.
IRSA Document store support
Camunda 8 Self‑Managed now supports using IAM Roles for Service Accounts (IRSA) with the AWS S3 document store:
- You can deploy Camunda 8 on Amazon EKS with the document store configured for S3 without providing static AWS credentials.
- The Helm chart no longer requires AWS access keys when IRSA is in use and allows pods to rely solely on their IAM role for S3 access.
- Existing deployments using static AWS keys can migrate to IRSA following documented steps.
Refer to the following updated Helm configuration and secret management documentation for more details:
- See IAM Roles for Service Accounts (IRSA) for the IAM role and trust policy, Helm chart configuration, service account annotations, and verification steps for the AWS S3 document store.
- See document handling configuration in Helm for the
global.documentStore.type.aws.irsa.enabledsetting and other AWS S3 document store options. - See Helm charts secret management to learn how static AWS credentials take precedence over IRSA.
REST API, RDBMS, and Document Store support for physical tenants
Support for physical tenant isolation in 8.10 is added for the Camunda 8 REST API, RDBMS storage, and Document Store.
Integrations
Camunda for Slack
Camunda for Slack brings tasks, processes, and notifications into Slack through the same App Integrations backend as Microsoft Teams. Everything runs through the /camunda slash command, the Camunda direct message, and channel mentions; there is no tab app.
From Slack, you can list and filter tasks, claim and release them, complete a task from a Block Kit modal, start a process, switch organization and cluster, and subscribe a channel or direct message to user task notifications. Slack also works with the App Integrations connector in both directions: a process can send a Slack message, and a Slack message can reach a process.
Microsoft Teams and Slack are independent. You can run either on its own, or both against the same backend.
This feature is released as an early access alpha feature.
Optimize
Delete a process definition's data via API
Optimize now exposes a public API endpoint to delete all analytics data for a given process definition, so you can remove data for retired processes or respond to data removal requests without manually touching Elasticsearch or OpenSearch.
The deletion runs asynchronously: the API accepts and queues the request, then processes it in the background.
Delete process definition data
Object variables no longer flattened by default in Self-Managed
Starting in 8.10, Optimize no longer flattens object variables by default in Self-Managed deployments.
Object variables are not flattened into per-property fields, and their raw values are no longer stored. This significantly reduces Optimize storage and CPU usage and aligns Self-Managed with the default Camunda 8 SaaS behavior.
-
If you rely on object variable properties in reports, filters, or Raw Data Reports, you can opt in by setting
zeebe.includeObjectVariableValue: true(envCAMUNDA_OPTIMIZE_ZEEBE_INCLUDE_OBJECT_VARIABLE=true). -
If the setting is not explicitly configured, Optimize logs a
WARNon startup stating that object variables will not be flattened, and details the opt-in setting. -
SaaS deployments are unaffected as this behavior is already disabled.
Recovery: The Optimize importer is idempotent. As long as the object variables still exist in the zeebe-record-variable\* indices (within your Zeebe retention window), you can enable the flag and reset the importer to reimport/flatten historical variables.
Object variables configuration
Orchestration Cluster
Centralized Secret Resolution via Zeebe
Centralized secret resolution through Zeebe is introduced with this alpha. Processes can reference credentials from customer-managed secret stores without persisting secret values in Camunda.
- Reference secrets as
camunda.secrets.NAMEin input mappings and expressions. The legacy{{secrets.NAME}}syntax continues to work. - Secrets are resolved automatically for activated jobs and can also be requested through the Gateway APIs
/v2/secrets/resolveand/v2/secrets/list. - Resolved values are not written to engine state, exports, backups, Operate, Tasklist, or application logs.
- Self-Managed deployments support AWS Secrets Manager and GCP Secret Manager with workload identity authentication. A file-based provider, backed by a mounted Kubernetes secret or a local directory, is also available and can be used in production as well as for local development.
- SaaS requires no configuration and uses Camunda’s managed secret backend.
- Camunda 8 Run uses the file-based provider: create one file per secret (filename = secret name, contents = value), and set
camunda.secrets.stores.file.default.pathto that directory in the Camunda 8 Run application configuration.
Migration: Existing processes continue to work without changes. For new processes, use camunda.secrets.NAME. To migrate hardcoded or connector-specific credentials, store the value in a supported secret store and replace it with a centralized secret reference.
Limitations: This feature does not yet include HashiCorp Vault or Azure Key Vault support, secret access audit logging, per-process secret restrictions, or centralized resolution for Hybrid Connector Runtimes. Cache entries expire after the configured TTL, which is 20 minutes by default.
New rebalance API for coordinated leadership transfer
Coordinated leadership transfer for Orchestration Clusters is introduced with this alpha.
The existing rebalance endpoint asks every leader to step down at once and returns immediately, without guarantee that the intended broker wins the resulting election. The new rebalance API transfers leadership deterministically, ensuring transfer in most cases in a way that is both minimally disruptive and observable.
| Feature | Description |
|---|---|
| Coordinated rebalancing API | POST /cluster/v2/rebalance starts a rebalance, GET /cluster/v2/rebalance reports the cluster's balance state and the progress of each partition, and DELETE /cluster/v2/rebalance stops a running rebalance once the transfer in flight has finished. The endpoint requires cluster-admin credentials. |
| Deterministic transfers | Leadership is handed directly to the partition's highest-priority replica instead of being left to an open election, so a rebalance reaches the intended leader layout. |
| Minimal disruptions | Transfers are sequenced one partition at a time across the cluster, so at most one partition is affected at any moment, rather than every partition becoming leaderless simultaneously. |
| Configurable | The replication lag a desired leader is allowed to have, how long a partition may wait for that leader to catch up, and how long to wait for a leaderless partition can all be set as cluster defaults and overridden per request. When the desired leader cannot take over in time, the partition resumes under its current leader. |
| Observable | POST /cluster/v2/rebalance?dryRun=true returns the plan a rebalance would carry out, without pausing any partition or moving any leadership. Each partition reports how its transfer ended or why it was skipped (already led by the desired leader, replication lag too high, replication timed out, and so on), so an incomplete rebalance can be diagnosed easily. |
- The previous /actuator/rebalance endpoint continues to work unchanged, and is superseded by the new API.
- There are some cases where rebalancing is still not guaranteed, notably where the desired leader is simply not available or becomes unavailable during the operation. Such cases require manual retries once the desired leader of a given partition is back online.
Process instance suspension and resumption
You can now suspend and resume a running process instance without canceling it. Suspending halts execution at its current point: no jobs activate or complete, no events correlate, and no timers fire. Resuming picks up from exactly where execution stopped, with no loss of progress or data.
- Suspend or resume a single instance, or a batch of instances at once, from Operate or the REST API.
- Variables are the one exception to the halt — you can still read and update variables on a suspended instance, so you can fix data before resuming.
- Timers whose due dates pass during suspension fire immediately on resume rather than waiting out their remaining duration.
- Messages and signals are not correlated to a suspended instance; publishing itself is unaffected.
Suspend and resume a process instance
Reference architecture for Amazon ECS
A new reference architecture details how you can run the full Camunda 8 stack on Amazon ECS, including Orchestration Cluster, Camunda Hub, and Management Identity.
What’s included:
- A reference architecture diagram and dependency overview for ECS.
- A Terraform‑based reference deployment paired with step‑by‑step documentation.
- Guidance for:
- Networking, storage, secrets, and IAM (including IRSA where relevant).
- Basic Day‑2 operations (scaling, updates, troubleshooting entry points).
This helps support Amazon ECS as a first‑class, documented deployment option for Camunda 8 Self‑Managed, alongside Kubernetes.
Reference architecture for dual-region ECS RDBMS
A new dual‑region reference architecture details how you can run the Orchestration Cluster and Connectors on AWS ECS with RDBMS secondary storage (such as Aurora Global Database).
What's included:
- Recommended topology, exporter configuration, and RDBMS replication setup.
- Step‑by‑step failover and failback procedures so your platform team can design, deploy, and operate an active‑active (or active‑passive) two‑region ECS environment that meets enterprise HA/DR requirements without bespoke architecture work.
Dual-region setup (ECS Fargate)
Task testing supports call activities
Task testing now supports call activities in both Desktop Modeler and Camunda Hub. Testing a call activity starts the deployed called process, shows its progress in the execution log with a link to open it in Operate, and reports incidents raised inside it.
8.10.0-alpha4
| Release date | Changelog(s) | Blog |
|---|---|---|
| 11 August 2026 | - |
Agentic orchestration
Agentic control plane
Use the Optimize agentic control plane dashboard to monitor AI agent adoption, token usage, reliability, and performance across your processes in a single view.
The dashboard is primarily intended to help operators, process owners, and engineering leads who manage AI-agent-powered processes, and need to keep them reliable and cost-effective.
Camunda Hub
BPMN element menu improvements
The create, append, and change menus now group BPMN elements by category, such as tasks, gateways, events, and so on. Each category includes a short description so you can quickly find the right element.
- Search still searches across all categories.
- When appending, elements that continue a flow subtly indicate where the flow continues next. Select this to open the append pad with a prominent Append action.
Define operations in your own element templates
Element templates support the steps and presets keys to offer several predefined configurations within a single template. Use steps to define the menu users navigate when they apply the template, and presets to define the property values each operation applies. Operation names, descriptions, and keywords are matched by search, so your operations are as discoverable as the templates themselves.
Hide the Add members button
In Self-Managed, you can now hide the Add members button on the workspace Members page, preventing non-organization admins from adding members via the UI. They can still add members via the modify collaborator API endpoint if granted access.
Optimize data filters in Camunda Hub
You can now configure Optimize data filters directly in Camunda Hub cluster settings, without editing Helm values or configuration files.
The Data filters section in cluster settings lets you:
- Enable or disable Optimize export filtering per cluster.
- Include or exclude process definitions by exact
bpmnProcessId. - Include or exclude variable names by prefix — for example,
business_includes all variables whose names start withbusiness_. - Exclusion takes precedence over inclusion when both are configured.
New SaaS clusters include a default business_ variable include filter, which limits Optimize to variables starting with business_ to reduce Elasticsearch storage and shard usage. Existing clusters show data filters disabled with a one-click opt-in — no automatic migration occurs.
Saving filter changes triggers a rolling restart of the Orchestration Cluster; the cluster is briefly unavailable while it restarts.
Filtered records are permanently excluded from Optimize and cannot be recovered even if you relax the filters later.
Configure Optimize data filters
Connectors
Find a connector by the operation you want to perform
Built-in connector templates now describe their operations, so you can model by the action you want to take instead of the product that provides it. Searching in the create, append, or change element menu for upload object or send email returns the matching operations of every connector as their own entries, and selecting one applies the connector with that operation preselected. Connectors with several operations show their operations as a nested menu, and the operation selection is now the first group in the properties panel.
Connectors that provide a single operation are also renamed to describe their action — for example, REST Outbound Connector is now Send REST Request. Existing process models are unaffected.
Integrate a built-in connector
Receive Microsoft Teams and Slack messages in a process
The App Integrations connector now receives messages as well as sending them. A process can start from a message someone writes to the Camunda app in Microsoft Teams or Slack, and a process that is already holding a conversation receives the reply, so an approval, a choice, or a correction can be collected in the chat people are already in rather than in a separate form.
Receiving needs no connector task and no job worker. Element templates for a chat start event, an intermediate catch event, a receive task, and a boundary event set up the correlation, so a start event and a catch event are enough for a working conversation loop. A Chat key on the start event decides which chats it answers: configure a Microsoft Teams channel or chat in the Camunda app's Settings tab, or a Slack channel or direct message with /camunda chat, and give the process the same key. A reply always reaches the cluster whose process asked the question. In a personal chat or direct message every message reaches the process; in a channel on either platform, @mention the Camunda app.
Send Microsoft Teams and Slack messages without managing credentials
The new App Integrations connector sends messages to Microsoft Teams and Slack, and creates channels, through your organization's Camunda app integrations. The connection is configured once for the environment, so no endpoint or credentials appear in the process model.
Messages can address a Microsoft Teams channel, user, or conversation, a Slack channel or user, or a Camunda recipient — an assignee, candidate users, or candidate groups — which the connector resolves to whichever platforms those people have connected. Alongside plain text you can send an Adaptive Card, a Block Kit payload, or a Camunda form. The result reports every destination reached and every one that failed, so a process can react to a partial delivery.
Helm chart deployment
Camunda Hub replaces Console and Web Modeler in the Helm chart
Camunda Hub is a drop-in replacement for Web Modeler in the Camunda Helm chart, and Console is no longer a standalone deployment. The camunda/hub image serves both Console and Web Modeler features, and you enable and configure it with the camundaHub key.
- For standard deployments, only the top-level key needs to change: replace
console.enabledandwebModeler.enabledwithcamundaHub.enabled. - Existing Web Modeler Helm values keep working. A compatibility layer in the application honors the existing value structure, and deprecated keys are logged but not required to change immediately.
- Moving your values under
camundaHubis cleanup that you can do later. The upgrade guide documents the steps. - Review
camundaHub.restapi.resourcesafter upgrading, because Console now runs in the Hub REST API pod.
Consolidate Console and Web Modeler into Camunda Hub
Operate
Business ID visibility for decision instances
Business ID is now visible in Operate for decision instances, in both the decision instance list and the decision instance details view. Filter decision instances by business ID using Equals, Contains, and Is one of in the filter UI, or the full operator set ($eq, $neq, $exists, $like, $in, $notIn) via the API.
Optimize
Client bearer tokens are now classified for permission checks
Optimize now classifies each bearer token as belonging to a user or a machine-to-machine (M2M) client, using camunda.security.authentication.oidc.username-claim and client-id-claim, and enforces your configured Optimize permission only on tokens it classifies as a user's. A token Optimize can't classify is treated as belonging to a user, and checked against your configured Optimize permission.
Optimize authentication in Self-Managed
Orchestration Cluster
Elasticsearch 9.x and OpenSearch 3.x support
Camunda 8.10 supports Elasticsearch 9.4+, Elasticsearch 8.19+, OpenSearch 3.6+, and OpenSearch 2.19+. Operators can upgrade their search layer to the latest certified versions without impact on process history, active instance visibility, or incident management.
The Self-Managed reference architectures ship these versions out of the box. The Elasticsearch clusters they deploy through the ECK operator run Elasticsearch 9.x, and the Amazon OpenSearch domains they provision through Terraform run OpenSearch 3.x. If you based your deployment on an earlier copy of a reference architecture, upgrade your search layer to a supported version before you move to 8.10.
FEEL context variables for the process instance
The process instance properties are now accessible in FEEL expressions via the camunda.processInstance context, resolvable anywhere in the process. camunda.processInstance.key returns the process instance's system-generated key, and camunda.processInstance.businessId returns its business ID (or null if none is set).
Late Business ID assignment
You can now assign a business ID to a running process instance that has none, using the POST /process-instances/{processInstanceKey}/business-id-assignment REST endpoint, the AssignProcessInstanceBusinessId gRPC command, or by including businessId in a job completion request. The assignment is single and irreversible, and only available while business ID uniqueness enforcement is disabled.
Physical Tenant identity support
Physical Tenants now support independent per-tenant authorization.
- Each Physical Tenant enforces its own roles, mapping rules, and permissions.
- Users can have different roles on different Physical Tenants, such as a developer role on one, and a viewer role on another.
- Cluster-wide operations (topology, backups, restore) are protected by a claim-based cluster admin role, with no new infrastructure required.
- Identity providers are defined at the cluster level. Each Physical Tenant chooses which IdPs it can accept.
Physical Tenant isolation model
Set up two isolated Physical Tenants
Rolling upgrades
You can now perform rolling upgrades of self-managed Camunda 8 between patch and minor versions with zero downtime across all supported secondary storage backends, including Elasticsearch, OpenSearch, and relational databases.
- The cluster stays operational during a rolling upgrade: workflows continue executing, and Operate remains accessible for monitoring and incident response.
- Schema changes between versions are strictly backwards-compatible and applied transparently.
S3-compatible object stores for Document Handling
Document Handling now supports any S3-compatible object store such as MinIO, Cloudian, or Garage alongside Amazon S3, Google Cloud Storage, and Azure Blob Storage.
- Configure an S3-compatible backend by pointing the existing AWS S3 document store to your custom provider endpoint.
- No migration is required for existing AWS S3 deployments.
Document handling configuration
Unified authentication for the Orchestration Cluster and Optimize
Optimize can now be configured with the same camunda.security.authentication.* settings already used by the Orchestration Cluster, so you configure authentication once, in one place. Nothing changes for the Orchestration Cluster, which already used these settings in 8.9.
Optimize continues to accept its 8.9 authentication settings in 8.10, translating the recognized properties to their new equivalents at startup, but those 8.9 properties are deprecated and will be removed in a future release. Confirm your camunda.security.authentication.oidc.issuer-uri and .audiences settings match your IdP before upgrading Optimize.
User, group, role, tenant, and permission management for Optimize is unchanged in this release, and is still handled by Management Identity.
Optimize authentication in Self-Managed
Unified frontend application for Admin, Operate, and Tasklist
Operate, Tasklist, and Admin are now accessed from a single frontend application with shared navigation, consistent design patterns, and unified deployment. Your user preferences (such as dark/light mode) are applied across all views, with consistent navigation patterns throughout the interface.
Tasklist
Business ID in Tasklist
Business ID is now visible in Tasklist, in both the task list and task detail views. Filter tasks by business ID using Equals, Contains, and Is one of in the filter dialog, or the $neq/$exists/$notIn operators via the API.
8.10.0-alpha3
| Release date | Changelog(s) | Blog |
|---|---|---|
| 14 July 2026 | - |
Agentic orchestration
AI agent testing assertions in Camunda Process Test
You can now test non-deterministic AI agent behavior in Camunda Process Test (CPT) with conditional behavior controls and evaluation-based assertions. With this, you can validate agent behavior and output quality with clearer, more reliable test outcomes.
- Define conditional behavior in tests with a
when(condition).then(action)API for activation-based flow control. - Assert output quality with LLM-as-a-judge expectations when exact matching is not enough.
- Assert semantic similarity with embedding-based comparison for responses that vary in phrasing.
- Configure remote or local models through code and properties for both local development and CI/CD pipelines.
APIs & tools
Invite members through the public API who haven't logged in yet
Adding a workspace member through the public API — PUT /v1/collaborators or POST /v2/workspaces/{workspaceKey}/members — no longer requires the invitee to have already logged in to Camunda Hub at least once. If the email address belongs to an organization member with no local user yet, Camunda now creates a pending invitation and sends an invitation email, the same as when inviting through the Camunda Hub UI. The invitee gains workspace access once they accept the invitation.
Public Camunda Hub API
A new Camunda Hub API is provided under /v2/ for programmatic access to the resources previously managed in Console and Web Modeler. The API aligns with the Orchestration Cluster API guidelines, with standardized error handling and data-fetching patterns.
The Console Self-Managed and Web Modeler APIs are deprecated in favor of the Camunda Hub API. See the release announcement for details.
The Camunda Hub API is not yet exposed in Camunda 8. To access it, please reach out to Camunda success.
Camunda Hub
Bespoke cluster generations for SaaS
Organizations can now access exclusive Camunda 8 generation versions tailored specifically for their organization, available for both new cluster creation and upgrades. These generations are not visible to other organizations.
Catalog
The new Camunda Hub catalog gives your center of excellence (CoE) a governed, organization-wide place to publish approved element templates, so delivery teams can reuse trusted building blocks instead of rebuilding them in each project.
- Manage element templates and their metadata in your own Git repository, and use a CI/CD pipeline to publish them to the catalog through the Hub API whenever the approved set changes.
- Browse, search, and filter published assets in Hub, and read each asset's details before you apply it while modeling.
- Track where each asset version is used, and identify projects that still use an outdated version.
- Unpublish assets you no longer want used. Elements that already use an unpublished asset keep working and show a deprecation hint.
Safe deletion with a 30-day recovery window
Deleting an item in Camunda Hub no longer removes it immediately. Deleted workspaces, projects, files, folders, and IDP projects are moved to Recently deleted for 30 days. During that time, users with the appropriate permissions can see who deleted an item and when, and restore it. After 30 days, items are permanently deleted.
Deletion no longer corrupts project version history, as existing snapshots continue to reference deleted files correctly. The recovery window applies to deletions made in 8.10 and later; items deleted before upgrading cannot be recovered.
Select a target version when upgrading a cluster
When you upgrade an Orchestration Cluster that has more than one valid upgrade target, Camunda Hub now shows a version selection step in the upgrade wizard. Each option displays the generation name and the Zeebe patch version.
The recommended version (the longest upgrade path) is pre-selected and labeled latest, and you can choose a different option before proceeding. Clusters with only one upgrade target keep the existing flow.
Self-service restore for SaaS orchestration clusters from backups
Organization admins can now restore a SaaS orchestration cluster directly from a completed backup in Camunda Hub and through the Administration API.
Key benefits:
- Reduced time to recovery for operational incidents.
- Operational control without opening a support ticket for standard same-cluster restores.
- Clear restore status visibility during execution.
This release supports in-place restore for the same cluster only. During restore, the cluster is unavailable until completion.
Known limitations:
- Same-cluster restore only.
- Partition count must match between backup and target cluster.
- Cross-region and cross-cluster restore are not supported in this release.
Start a process instance with a business ID
You can now set a business ID when starting a process instance directly from Camunda Hub or Desktop Modeler. The business ID field is available in the start process instance dialog alongside variables.
Test process segments in Play
When testing your process with Play in Camunda Hub, you can now capture and rerun targeted sections of an agentic process as low-code integration tests:
- Run segment tests individually or in batches to validate process changes faster.
- Test BPMN elements like connectors, DMN, forms, and LLM tasks without a full end-to-end run.
- Reuse saved segment tests during iterative model changes to catch regressions earlier.
Desktop Modeler
Variables panel improvements
When you hover over "written in X elements" or an element ID in the variables panel, the diagram now highlights the corresponding element or elements so you can quickly see where a variable is used.
FEEL expressions in the variable outline now use the same syntax highlighting as the FEEL editor, with more granular tokens that distinguish function names from arguments and operators from literals, making complex expressions easier to read.
When no element is selected on the canvas, the variables panel now highlights the process (root) scope, matching how it highlights the scope of a selected element. Variable value previews also no longer repeat the opening brackets of nested objects and arrays, so previews are easier to scan.
Helm chart deployment
Docker images
Camunda no longer produces the following Docker images in Camunda 8.10 and later, or in Camunda 8.9 from patch release 8.9.12:
Use the unified camunda/camunda Docker image instead.
Operate
Business ID filtering in Operate
Operate now exposes business ID as a filter field for process instances. You can filter using Equals, Contains (with * and ? wildcards), and Is one of — or use the full operator set ($eq, $neq, $exists, $like, $in, $notIn) via the API.
Multi-variable filtering
In Operate, you can now combine multiple variable filters with AND logic to find exactly the process instances you need.
Filter by variable name, value, and comparison operators, such as equals, contains, greater than, and less than, including nested JSON paths.
Wait states
Operate now shows what an active process instance is waiting for. When you inspect an active element, you can see the wait state and its details, for example, a timer's due date, a receive task's message name and correlation key, a signal name, a condition expression, or a job's type and state.
Wait state tracking is enabled by default and writes records to secondary storage. In Camunda 8 Self-Managed, you can disable it if you do not want to track this data.
Optimize
Optimize disabled by default on new trial clusters
On new trial clusters in Camunda 8 SaaS, Optimize is now disabled by default. When Optimize is disabled, the overview shows a muted tile with an Enable Optimize prompt so it stays discoverable.
Upgrading from a trial to a paid plan automatically enables Optimize, with no manual action required.
Orchestration Cluster
Archive by ID for Elasticsearch and OpenSearch
Archiving of finished process instance data in Elasticsearch and OpenSearch secondary storage now uses a targeted, incremental approach by default.
Documents are moved in small, targeted batches rather than in a single operation, improving stability and reducing resource pressure during archiving. The rolloverBatchSize and reindexBatchSize properties control how many process instances and individual documents are processed per batch.
Async replication support for RDBMS secondary storage
Camunda 8.10 adds first-class support for asynchronously replicated relational databases as secondary storage, including AWS Aurora and PostgreSQL.
The exporter layer detects when the active RDBMS endpoint is unreachable, including during a standby promotion or cross-region failover, and pauses export operations automatically rather than entering an error state. Export position is preserved in the Zeebe log and replayed on reconnection.
After failover, a reconciliation path replays missing events from the Zeebe log to close any replication lag gap, restoring a consistent secondary storage state without manual data repair. A single-exporter configuration is now supported for deployments where the RDBMS handles cross-region replication natively.
Business ID in message correlation
You can now include a business ID when publishing or correlating a message. Business ID acts as an additional filter alongside the message name and correlation key.
Supported combinations for start events: message name alone; name + business ID; name + correlation key; name + correlation key + business ID. For non-start events, business ID is usable alongside name + correlation key. When both a correlation key and business ID are provided, both fields must match the corresponding values stored on the subscription.
If business ID uniqueness is enabled, a blocked message-start waits in the buffer until the active instance releases the business ID or the TTL expires — it is not dropped immediately.
Business ID in message correlation
Business ID propagation in call activities
Call activities now support configuring the business ID assigned to the child process instance. Child instances inherit the parent's business ID by default (unchanged from 8.9). You can override this per call activity with a literal value or FEEL expression. The FEEL context variable camunda.processInstance.businessId provides access to the parent's ID within the expression.
The resolved value is set once at child creation and is immutable.
Cluster variable metadata
You can now add metadata to cluster variables as a map of string keys to scalar values (strings or numbers). Camunda stores the metadata alongside the variable but keeps it separate from its value.
Use metadata to discover and filter variables by semantic attributes without inspecting their values. The search endpoint supports metadata filters with equality, numeric range, existence, in, and like operators for each key. Metadata is not exposed as part of the FEEL-accessible runtime value.
Dual-region ECS reference architecture
Camunda 8.10 adds a dual-region reference architecture for running the Orchestration Cluster and Connectors on AWS ECS with an RDBMS secondary storage such as Aurora Global Database.
The documentation covers the recommended topology, exporter configuration, and RDBMS replication setup, and includes step-by-step failover and failback procedures for active-active and active-passive two-region ECS environments.
Dual-region ECS reference architecture
Multi-tenancy support in SaaS
Camunda 8 SaaS now officially supports multi-tenancy via tenant identifiers, bringing the same logical tenant isolation model available in Self-Managed to SaaS clusters.
Multi-tenancy is available on SaaS clusters running generation 8.8 and later — including existing 8.8 and 8.9 clusters. You do not need to upgrade to 8.10 to use this feature.
- Owners and Admins can create, update, and delete tenants in Camunda Hub, and assign users, groups, and client credentials to them.
- Camunda Hub and Desktop Modeler support tenant-scoped deployments to multi-tenant clusters by specifying a tenant ID.
- Tenant usage is reflected in Camunda Hub reporting so org owners can monitor tenant consumption across a cluster.
Multi-tenancy is enabled at the cluster level. Process definitions, instances, and decisions are scoped to the tenant they were deployed to, keeping data isolated across teams and applications sharing a single cluster.
New RDBMS version support
Camunda 8.10 adds support for new relational database versions. Operators running Self-Managed Camunda clusters can upgrade their database layer to the latest supported versions without disruption to running process instances.
New supported versions include Amazon Aurora PostgreSQL 18, MariaDB 12.3, Microsoft SQL Server 2025, and MySQL 9.7.
Physical Tenant support
Camunda 8.10 introduces Physical Tenant support for RDBMS, enabling strong isolation across tenants.
- The REST API and gRPC API are exposed per Physical Tenant.
CamundaClientsupports tenant selection over both REST and gRPC. - Web apps (Operate, Tasklist, and Admin) are accessible per Physical Tenant at
<baseurl>/physical-tenants/<physicalTenantId>/<webapp>. - Authentication is configurable as
basic author OIDC at the cluster level, with support for multiple OIDC providers assigned to individual Physical Tenants.
Physical Tenant isolation model
Set up two isolated Physical Tenants
Region-aware partition placement
Camunda 8.10 introduces region awareness to the Orchestration Cluster. Operators declare which region each broker belongs to using a topology label, and the engine uses those declarations to distribute partition replicas across regions, ensuring no single region holds a quorum for any partition.
Leader election priorities respect region boundaries, preferring region-local leaders under normal conditions and adjusting automatically when a region becomes unavailable. The same mechanism extends to availability zone or datacenter isolation using the same configuration.
Orchestration Cluster configuration properties
Select a DMN version with a FEEL expression
You can now call a dynamically calculated version of a DMN decision from a BPMN business rule task by specifying the version with a FEEL expression.
8.10.0-alpha2
| Release date | Changelog(s) | Blog |
|---|---|---|
| 09 June 2026 | - |
Agentic orchestration
Judge assertions in CPT JSON Test Cases
Camunda Process Test (CPT) now supports judge assertions in JSON test cases.
- Define judge assertions using JSON test case instructions.
- Use a preconfigured judge from
camunda-container-runtime.propertiesor Spring application properties depending on the test execution context.
Processes MCP Server
AI agents can use the Processes MCP Server to discover and call deployed BPMN processes as Model Context Protocol (MCP) tools.
When you deploy a process with an MCP start event it is automatically registered as a callable tool. MCP clients connect to the /mcp/processes endpoint and can invoke any registered process, with the Orchestration Cluster starting a new process instance and immediately returning the process instance key.
The server also exposes static tools for inspecting running process instances, so agents can check variables, state, and incidents without switching servers.
Skills repository for pro-code AI enablement
The Camunda Skills repository toolset enables AI coding agents to build, validate, and configure Camunda artifacts. With the Skills installed, your AI agent can:
- Build and modify BPMN diagrams with a human-readable layout.
- Configure connectors using element templates (no raw XML).
- Generate form schemas with validation.
- Create and edit DMN decision tables.
- Run BPMN lint rules against generated diagrams.
- Scaffold and wire Camunda Process Test (CPT) integration tests.
APIs & tools
Camunda 8 Run no longer requires Java
Camunda 8 Run now includes a bundled Java runtime. This means you no longer need to install OpenJDK or set JAVA_HOME before starting Camunda 8 Run.
FEEL evaluation with process instance key
The POST /v2/expression/evaluation endpoint now optionally evaluates expressions in the context of:
- A process instance, via
processInstanceKey. - A flow node instance, via
elementInstanceKey.
The endpoint:
- Combines process instance variables, element-local variables (for element scope), cluster variables, and optional request context into a single evaluation context.
- Enforces
EXPRESSION:EVALUATEplusPROCESS_DEFINITION:READ_PROCESS_INSTANCEon the underlying process definition. - Requires exactly one of
processInstanceKeyorelementInstanceKey(mutually exclusive); sending both returns400 Bad Request.
Behavior remains free from side effects and uses the same timeout and guardrails as the existing cluster-scope evaluation.
Removal of deprecated APIs, Zeebe Client, and Zeebe Process Test
The deprecated Operate and Tasklist APIs are removed. Process data, task management, and operational queries are now served through the Orchestration Cluster API.
Migrate to the Orchestration Cluster API
The Zeebe Client is removed and replaced by the Camunda Java Client. This covers process deployment, message correlation, and job handling.
Migrate to the Camunda Java Client
The Zeebe Process Test library is removed and replaced by Camunda Process Test. This provides richer assertions, Spring integration, and alignment with the Orchestration Cluster API surface.
Camunda Hub
Low-code test CI/CD compatibility
Test files in Test Studio now use the same schema as Camunda Process Test (CPT). You can record a test in Test Studio and run it in your CI/CD pipeline through CPT without converting formats, and load CPT-authored test files into Test Studio to debug them visually.
- Use one JSON schema across Test Studio and CPT: record once, run anywhere.
- Existing Play test scenario files are migrated automatically to the new format.
Desktop Modeler
Support for start forms in Desktop Modeler
Desktop Modeler now supports defining form references on none start events in Camunda 8 BPMN models, matching the existing Camunda Hub capability.
You can configure start forms directly in Desktop Modeler's properties panel using:
- Camunda Form (linked): Reference a deployed Camunda Form by ID.
- Camunda Form (embedded): Embed form JSON in the BPMN diagram (deprecated).
Start forms can now be defined and edited in both modelers, ensuring a seamless experience when working with diagrams across Camunda Hub and Desktop Modeler.
Helm chart deployment
Bitnami subcharts removed from the Helm chart
The Camunda Helm chart no longer includes the bundled Bitnami subcharts for PostgreSQL, Elasticsearch, and Keycloak. Helm installations must connect to external infrastructure, such as managed databases and search services, Kubernetes operators, or customer-owned images.
If you still use Bitnami subcharts on 8.8 or 8.9, migrate to external or vendor-supported infrastructure on 8.9 before upgrading to 8.10; the 8.10 Helm chart has no Bitnami-based fallback. See the release announcement for details.
Migrate from Bitnami subcharts
Operate
Business ID visibility in Operate
Business ID is now visible in Operate for process instances. The businessId field appears in the process instance list and the process instance details view.
Optimize
Scope-aware variable export configuration for Optimize
You can now configure variable export behavior by scope:
- You can enable or disable root (process instance) variables and local variables independently.
- You can exclude all local variables by default, while still allowing specific local variables by name pattern.
- Configuration integrates with the existing variable filtering mechanism, using consistent syntax and semantics.
Terminology aligns with Camunda 8 docs:
- Root scope/process instance scope: Variables visible across the process.
- Local variables: Variables defined in child scopes only.
With this, you can configure setups such as:
- Export only root variables for all processes.
- Export a curated subset of local variables (for example,
taskContextDisplayNameor specific local audit variables) without exposing all locals.
Orchestration Cluster
Default RocksDB memory allocation strategy changed to FRACTION
The default RocksDB memory allocation strategy changes from PARTITION to FRACTION. RocksDB memory is now allocated as a fraction of total available memory (default 0.1, or 10%) instead of scaling with the number of partitions per broker. This may result in a different amount of memory being allocated to RocksDB.
To keep the previous behavior, explicitly set the strategy to PARTITION. See the release announcement for more details.
Edit roles and tenants in Admin
You can now edit the name and description of a role or tenant directly in Admin, without deleting and re-creating it. Existing assignments stay in place.
- Default roles and the
<default>tenant are system entities and cannot be edited. - Role and tenant IDs cannot be changed after creation.
Multi-Instance activity execution listeners
Execution listeners can now be configured on the enclosing body of multi-instance activities. beforeAll listeners run once per multi-instance body activation, before the inputCollection is evaluated and inner instances are created, making listener-produced variables available to the body's inputCollection expression.
- Replicate Camunda 7 multi-instance and execution listener patterns without redesigning your process.
- Dynamically calculate collections using custom logic or external data before instance creation.
8.10.0-alpha1
| Release date | Changelog(s) | Blog |
|---|---|---|
| 13 May 2026 | - |
Agentic orchestration
AI Agent connector: Conversation storage SPI redesign
The conversation storage SPI used by custom AI Agent storage backends has been redesigned. Built-in stores are migrated transparently; custom ConversationStore implementations must be updated.
See the release announcement for more details.
Camunda-provided LLM for SaaS
You can now run any AI Agent on Camunda 8 SaaS in minutes using the Camunda-provided LLM, without wiring your own LLM credentials. Whether you start from a Camunda-provided agentic blueprint or build your own agent from scratch, the required credentials are populated automatically as cluster secrets, so there is little to no extra setup needed to get started.
The included budget is sufficient for hundreds or thousands of agent runs even on a trial account, depending on the model used. Enterprise organizations must explicitly enable the Camunda Provided LLM toggle in Camunda Hub, which is separate from the AI-powered features toggle.
This dramatically reduces time-to-first-running-agent by removing the need for external LLM infrastructure or credential setup on day one.
MCP start event element template
The MCP start event element template is now available in Camunda Hub and Desktop Modeler. Apply it to a BPMN message start event to configure the process as an MCP tool with name, purpose, inputs, and usage guidance for LLMs.
See MCP start event for the full property reference.
Standalone evaluation assertions for judge and semantic similarity
Camunda Process Test now exposes judge-based evaluation and semantic similarity evaluation as standalone AssertJ assertions for arbitrary string values, without requiring process-variable assertions. Semantic similarity checks support configurable embedding models and thresholds, and both assertion types reuse the existing CamundaAssert configuration with optional local overrides.
APIs & tools
In-memory OAuth credentials cache by default for the Java client
The Camunda Java client now caches OAuth credentials in memory by default. The file-based cache at $HOME/.camunda/credentials is no longer enabled out of the box and is available as an explicit opt-in.
Why this change:
- The previous default tried to create
$HOME/.camunda/credentialson first use. In hardened container environments — non-root users (KubernetessecurityContext.runAsUser, OpenShift), read-only root filesystems, immutable images — this raisedAccessDeniedException/IOExceptionat first cache write. Affected users had to apply a non-obvious workaround (mount a writable volume and point an environment variable at it) just to get a client to start. - Memory-only caching removes that footgun: clients work out of the box in any deployment topology, and the in-process token cache plus proactive refresh still avoid unnecessary token endpoint calls during a JVM's lifetime.
- The file cache had also been a source of latent corruption when multiple JVMs shared the same
$HOME; making it opt-in restricts its use to deployments where persistence across restarts is genuinely needed.
How to opt in to the file-based cache (behavior identical to pre-8.10):
- Java client builder:
new OAuthCredentialsProviderBuilder().credentialsCachePath("/path/to/cache"). - Spring property:
camunda.client.auth.credentials-cache-path: /path/to/cache. - Environment variable:
CAMUNDA_CLIENT_CONFIG_PATH=/path/to/cache(orZEEBE_CLIENT_CONFIG_PATHfor the legacy Zeebe client).
If you previously set CAMUNDA_CLIENT_CONFIG_PATH / ZEEBE_CLIENT_CONFIG_PATH only to work around the non-root container error, you can now remove that configuration and rely on the in-memory default.
Spring Boot starter configuration
Camunda Hub
Cluster version selection for SaaS Orchestration Clusters
You can now create new SaaS Orchestration Clusters on specific supported Camunda 8 minor and patch versions, including:
- The latest recommended versions (latest patch of each active minor)
- Other still-supported versions that you already run on existing clusters in the same organization.
Execution listener configurable header support
Execution listeners now support configurable headers, aligned with service task job headers.
- In BPMN, execution listeners can define
<zeebe:taskHeaders>. The headers are passed to the listener’s job worker alongside any base-element headers, with listener headers overriding on key conflicts. - In Modeler, you can configure execution listener headers visually (name/value pairs) without editing BPMN XML.
- Listener workers can consume these headers as metadata and configuration parameters using the same patterns as service task job workers.
Usage & billing metrics for 2025 enterprise license model
Camunda Hub and Accounts now support the 2025 enterprise license model.
- A new
licensing_modelattribute onOrganizationMetaDataidentifies if an enterprise organization is using the 2025 or legacy license model. If unset, it is treated as legacy. - If you are an organization with
licensing_model = 2025, your Usage and Billing views only show Process Instance (PI) metrics. Decision Instance (DI) and Unique Task User (TU) information is no longer shown. Legacy organizations continue to see the existing metric set. - For enterprise (
salesplantype = enterprise) organizations, the licensing model is shown in the organization details. Admins can edit this by selecting either legacy or 2025 via a modal action. - The enterprise onboarding wizard now includes a license selection step (defaults to 2025). The
ExternalOnboardingRouteraccepts an optional licensing model parameter (defaulting to 2025 if not provided).
Helm chart deployment
Host network support for Orchestration Cluster pods
The 8.10 Helm chart adds orchestration.hostNetwork (default: false), which lets Orchestration Cluster pods share the host node's network namespace. This is useful in bare-metal or restricted network environments where pods must be reachable directly via the node IP rather than a cluster overlay network.
When orchestration.hostNetwork is set to true and orchestration.dnsPolicy is not set, the chart automatically uses dnsPolicy: ClusterFirstWithHostNet to preserve in-cluster DNS resolution. You can override this by setting orchestration.dnsPolicy explicitly.
orchestration:
hostNetwork: true
For details, see configure pod networking.
Integrations
Microsoft Teams routing and permission-aware task actions
Camunda for Microsoft Teams now supports routing incident and task collaboration to private channels, shared channels, and group chats. Notifications and task actions in Teams now align with Camunda assignment and access rules, ensuring that only eligible users are notified and allowed to act.
Intelligent document processing (IDP)
Support for ABBYY as an IDP Provider
Camunda IDP now supports ABBYY as a document extraction provider.
Operate
JSON display in Operate
Camunda 8.10 introduces an update to the JSON display functionality in Operate (SaaS).
You can now:
- Open JSON variables in a dedicated JSON viewer directly from the variables panel, without entering editing mode.
- View JSON values with consistent, easier to understand formatting.
- Copy full JSON variable values to the clipboard.
- Use the improved in-line variables display.
This change helps navigate more complex data during operations and troubleshooting.
Orchestration Cluster
Cancel execution listener
Execution listeners now support a cancel event type on the process element. Cancel listeners run when a process instance is terminated — useful for cleanup, audit logging, or notifying external systems.
For details, see cancel listeners.