Deployment strategies & Future support

At Consdata, we strive to be a reliable business partner working toward the future success of a project. This is why we base our cooperation with customers and partners on feasible assumptions and solid, actionable plans. As a result, we are able to offer the most optimal functionality while excluding inessential elements of the BPM engine, at the same time ensuring the most sustainable support models for the future.

With EximeeBPMS, we have opted to offer the most optimal functionality while excluding inessential elements of the BPM engine, at the same time ensuring the most sustainable support models for the future.

On this page we present the development direction of EximeeBPMS – both in terms of system components and implementation strategies as well as support models.

Evolution

As part of the development of the BPM Engine, we focus on modernity, modularity and the elimination of technical debt.

  • New components such as REST API 2.0, Event API and Templating Engine provide integration flexibility and readiness to operate within a microservice architecture.
  • Supported components provide a stable foundation for the tool: BPMN 2.0, DMN 1.3, multi-tenancy, Java/Groovy scripting and Java API – maintained and developed according to user needs.
  • Obsolete components (e.g. CMMN, Camunda Forms, WebApps) are elements with low adoption or dependent on outdated libraries and frameworks.

The future of EximeeBPMS is decentralisation and greater independence of components – therefore many of them (such as the process definition repository, metrics or audit) will get separate APIs and the ability to be deployed as external modules.

Deployment Strategies

The approach to deploying BPM systems is also evolving – moving away from centralized, heavyweight application servers to lightweight, containerized solutions.

  • The embedded model is still fully supported, especially for applications based on Spring Boot, Java, and lightweight frameworks.
  • The remote model is the way of the future: standalone JARs, Docker/Podman containers, Kubernetes support, and ready-to-use Camunda Run images enable fast, independent, and repeatable deployments.
  • Shared models (shared, container-managed) – traditional servers such as WebLogic, JBoss, or WebSphere – are being phased out as they are costly to maintain and limit update flexibility.

Flexibility, deployment automation, and a cloud-native approach are the pillars that guide the development of EximeeBPMS.

Future Support: Community Support vs Commercial Support

We understand that different organizations have different support needs. That's why we offer two models: Community Support and Commercial Support.

We understand that different organizations have different support needs. That's why we offer two models: Community Support and Commercial Support.

  • Community Support provides access to open documentation, a forum, GitHub issues, regular updates, and semi-annual releases. It's an ideal solution for teams with strong technical expertise.
  • Commercial Support provides access to a private forum and contact channels, SLA for blocker & critical bugs, questions and other issues, and critical security updates. This model also includes Long-Term Support (LTS). It's the choice for organizations that need guaranteed stability and fast response times.

Regardless of the chosen model, EximeeBPMS ensures transparent development, an active community and a strong focus on user security.