What's new in Camunda 8.10
Highlights and important changes to consider when upgrading to Camunda 8.10.
Why upgrade to Camunda 8.10?
Upgrading to Camunda 8.10 delivers significant benefits and keeps your installation aligned and ready for future releases.
Summary of important changes
Important changes in Camunda 8.10 are summarized as follows:
Changes for 8.10 will be added here as the 8.10 documentation is updated.
- See release announcements and release notes for a full summary of what's included in Camunda 8.10, including all breaking changes and deprecations, and supported environment changes.
- For removed legacy APIs, Tasklist V1-dependent features, and Zeebe Process Test, see the 8.10 release announcement.
- Ready to upgrade? See the upgrade guides to learn more about upgrading from Camunda 8.9 to 8.10.
Web Modeler data
On 29 August 2026, your Web Modeler data will receive three updates:
- Organizational structure: Enforces a stricter, more scalable file resource hierarchy.
- Data migration: Aligns your existing data with the new structure.
- Process application versioning model: Provides more granular control.
Organizational structure
In Camunda 8.9, a project can contain process applications, folders, and files. Camunda 8.10 introduces a new file resource hierarchy in which projects only contain process applications. Everything else, including files, folders, and IDP application content, is stored inside a process application.
For example, if this is what your data looks like in 8.9:
Payments (Project)
├─ main.bpmn
├─ eligibility.dmn
├─ readme.md
├─ Forms (Folder)
│ ├── details.form
│ └── review.form
├─ Archive (Folder)
│ └── Refunds (Process application)
│ ├── refunds.bpmn
│ └── refund-request.form
└─ Onboarding (Process application)
├── onboarding.bpmn
└── kyc-checks.dmn
This is what the data looks like in 8.10:
Payments (Project)
├─ Payments - General (Process application - TEMPORARY PLACEMENT)
│ ├─ main.bpmn
│ ├─ eligibility.dmn
│ ├─ readme.md
│ ├─ Forms (Folder)
│ │ ├── details.form
│ │ └── review.form
│ └─ Archive (Folder)
├── Refunds (Process application - MOVED)
│ ├── refunds.bpmn
│ └── refund-request.form
└─ Onboarding (Process application)
├── onboarding.bpmn
└── kyc-checks.dmn
This strict new Project > Process application > File/folder hierarchy makes resources more discoverable and your projects more scalable.
Data migration
For Self-Managed, your data will be migrated to the new organizational structure during the upgrade to Camunda 8.10. For SaaS, this happens automatically during a scheduled maintenance window.
During the migration:
- Any process application nested inside a folder moves to the top level of its project.
- Any files or folders located directly in a project, not inside a process application, are automatically grouped in a new process application, named
YOUR PROJECT NAME - General. Once the migration is complete, you can rename this application, move content out of it, or otherwise reorganize it as with any other process application. - Git sync and cluster settings on existing process applications migrate unchanged along with your data.
During the migration, Web Modeler is briefly unavailable. Clusters and running processes are unaffected and continue executing normally.
Even though the migration process is tested extensively ahead of release, a backup is still taken before the migration to ensure your data is recoverable in its original state, should anything go wrong. If you notice anything unexpected after the migration, contact support.
The migration does not affect the following resources:
| Area | Impact |
|---|---|
| Running process instances | Orchestration Clusters, engines, and running process instances continue unaffected. Web Modeler and Camunda Hub form a modeling-and-management plane independent of the runtime path. |
| Redeployment | Deployments live on your clusters, not in the project structure being reorganized. Everything already deployed keeps running; this change doesn't require redeployment. |
| Clusters and configuration | Cluster and deployment settings attached to existing process applications migrate along with the data and carry over unchanged. |
| Files, folders, and version history | All files, folders, versions, and history are preserved; only their location within the project changes. |
| Git-synced projects | The migration doesn't modify process applications or their contents, so anything connected through Git sync is unaffected: the same files, in the same repository, with the same history. |
| Desktop Modeler | Desktop Modeler has no direct connection to Web Modeler affected by this change. Content shared via Git sync is also unaffected. |
If you automate against the Web Modeler API, content moving to a new location affects you directly. Web Modeler API v1 returns files and folders from their new place, and requests that create an item at a project's root are redirected into the new YOUR PROJECT NAME - General application, with the response reflecting the new location.
You should review any automation that relies on where files or folders are located before the migration runs. A small number of folder API integrations are affected more directly; if you rely on the folder API to work with process applications, contact support to confirm whether your integration needs updates.
Process application versioning model
In addition to the Web Modeler data migration, Camunda is introducing an improved process application versioning model:
- File-level versions — process applications can be versioned as a bundle, as before, but now also at the single-file level.
- Autosave for all files, plus file-level version history for every file.
- Decoupled versioning — process application versions and element template versions are now created independently of each other.
Before the new model, a process application and the resources within it were tightly coupled. You could only version and deploy the resources as a single, bundled unit. With the new model, you control whether you version:
- Process application resources as a bundle.
- Individual resources within the process application independently.
Camunda 8 Run no longer requires Java
Camunda 8 Run now ships with a bundled Java runtime. You no longer need to install OpenJDK or set JAVA_HOME before starting it.
Wait states
Operate now shows what an active process instance is waiting for, so you can tell expected waiting from a stalled instance. When you inspect an active element, you can see the wait state and its details — 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.
Helm chart deployment
Important changes to Helm chart deployment in 8.10 are as follows:
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.
Upgrade guides
The following guides offer detailed information on how to upgrade to Camunda 8.10.
| Guide | Description | Who is this guide for? |
| Self-Managed upgrade guide | Evaluate your infrastructure, understand operational changes, and choose the best update strategy for your environment. | Operations and platform administrators of Self-Managed installations. |
| APIs & tools upgrade guide | Plan and execute an upgrade from Camunda 8.9 to 8.10, focusing on API and tools transitions. |
|