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
8.10.0-alpha5
| Release date | Changelog(s) | Blog |
|---|---|---|
| 8 September 2026 | - |
Agentic orchestration
AI Agent connector: new native (v2) element templates
The AI Agent Task and AI Agent Sub-process connectors are now available as new, native (v2) 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 original (v1) element templates are deprecated as of Camunda 8.10.
The legacy connector is deprecated in 8.10 but 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 Web Modeler, Console and Operate.
The new design system will be introduced for SaaS deployments with the 8.10 minor release.
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 Console.
- 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:
- Helm 4-only support.
- 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 updated Helm configuration and secret management documentation for:
- Enabling IRSA for new EKS deployments using the AWS document store.
- Safely migrating existing deployments from static AWS keys to 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.
Modeler
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 projects and process applications
A new organizational structure for projects and process applications is introduced with this alpha.
With this new file resource hierarchy:
- Projects now only contain process applications and IDP applications.
- Files and folders are stored inside process applications.
- Previously, a project could contain process applications, folders, and files.
The new Project > Process application > File/folder hierarchy makes resources more discoverable and your projects more scalable.
SaaS Web Modeler data was updated during the 29 August 2026 maintenance window to support this new structure.
Project versioning model
A new versioning model for projects, process applications and file resources is introduced with this alpha. Projects now only contain process applications and IDP applications on the root level. Folders and files are stored inside process applications.
Process applications: The new process application versioning model uses snapshots to save the current state of all the process application files, in a single action. This helps you track a process application 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 Web Modeler
You can now view and choose which cluster you are connected to in Web Modeler.
- Connector-credential names from the cluster autocomplete in your FEEL expressions.
- Task testing runs against the connected cluster.
- Connect your cluster from the modeling toolbar to model against your real environment.
This is disabled by default and behind feature flag runtimeConnectionEnabled (cluster selection and task testing). The properties-panel connector-credential picker additionally requires credentialsEnabled.
Optimize
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, 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.
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.
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 and Web Modeler. 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
Optimize data filters in Console
You can now configure Optimize data filters directly in Console 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
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.
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.
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.
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 user button
In Self-Managed, you can now hide the Add user button on the Web Modeler Collaborators page, preventing non-organization admins from adding collaborators via the UI. They can still add collaborators via the modify collaborator API endpoint if granted access.
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
Optimize authentication moves to the Camunda Security Library
Optimize now authenticates through the Camunda Security LibraryCamunda Security Library (CSL)The shared authentication and authorization implementation used across Camunda 8. As of 8.10, the Orchestration Cluster, Camunda Hub, and Optimize all authenticate through it, so they accept the same camunda.security.* configuration. (CSL), adopting the same authentication and session handling as the Orchestration Cluster components.
See the release announcement for the upgrade action required, and Optimize authentication in Self-Managed for the Optimize authentication configuration.
Optimize authentication in Self-Managed
Orchestration Cluster
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.
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.
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
Unified authentication for the Orchestration Cluster, Camunda Hub, and Optimize
The Orchestration Cluster, Camunda Hub, and Optimize now authenticate through the Camunda Security LibraryCamunda Security Library (CSL)The shared authentication and authorization implementation used across Camunda 8. As of 8.10, the Orchestration Cluster, Camunda Hub, and Optimize all authenticate through it, so they accept the same camunda.security.* configuration., a shared implementation that replaces their separate identity stacks. All three components accept the same camunda.security.authentication.* settings, so you configure authentication once, in one place. Nothing changes for the Orchestration Cluster, which already used these settings in 8.9.
Camunda Hub and Optimize both continue to accept their existing authentication settings in 8.10, translating the recognized properties to their new equivalents at startup, but those legacy properties are deprecated for both components and are removed in 8.11. Camunda Hub requires no configuration change to upgrade to 8.10. Confirm your camunda.security.authentication.oidc.issuer-uri and .audiences settings match your IdP before upgrading Optimize. See Optimize authentication in Self-Managed for details.
User, group, role, tenant, and permission management for Camunda Hub and Optimize is unchanged in this release, and is still handled by Management Identity.
Optimize authentication in Self-Managed
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 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
Public Camunda Hub API
A new Camunda Hub API is provided under /v2/ for programmatic access to Console and Web Modeler resources. 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.
Invite collaborators through the public API who haven't logged in yet
Adding a project collaborator through the public API — PUT /v1/collaborators or POST /v2/workspaces/{workspaceKey}/members — no longer requires the invitee to have already logged in to Web Modeler 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 Web Modeler UI. The invitee gains project access once they accept the invitation.
Console
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.
Select a target version when upgrading a cluster
When you upgrade an Orchestration Cluster that has more than one valid upgrade target, Console 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 Console 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.
Learn more:
Modeler
Safe deletion with a 30-day recovery window
Deleting an item in Web Modeler no longer removes it immediately. Deleted projects, files, folders, process applications, and IDP applications 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 process application 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.
Test process segments in Play
When testing your process with Play in Web Modeler, 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.
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.
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.
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.
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.
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.
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.
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 Console, and assign users, groups, and client credentials to them.
- Web Modeler and Desktop Modeler support tenant-scoped deployments to multi-tenant clusters by specifying a tenant ID.
- Tenant usage is reflected in Console 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, with
CamundaClientsupporting Physical Tenant selection in the gRPC API. - 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
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.
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
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.
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.
8.10.0-alpha2
| Release date | Changelog(s) | Blog |
|---|---|---|
| 09 June 2026 | - |
Agentic orchestration
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.
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.
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.
Migrate to Camunda Process Test
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 Web Modeler 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 Web Modeler and Desktop Modeler.
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.
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.
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. For enterprise organizations, AI features must be enabled first; after that, Camunda-provided LLM is enabled automatically.
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 Web Modeler 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.
Console
Usage & billing metrics for 2025 enterprise license model
Console 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).
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.
Intelligent document processing (IDP)
Support for ABBYY as an IDP Provider
Camunda IDP now supports ABBYY as a document extraction provider.
Modeler
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.
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.
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.
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
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.
Helm chart deployment
Helm v4 required
Camunda 8.10 (chart 15.x) supports the Helm CLI v4 only. Earlier Camunda versions are the last to support the Helm v3 CLI.
Switching CLIs does not require a release-state migration; Helm is client-side only. Before you run helm upgrade to 8.10, install the Helm v4 CLI.
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.