Deployment Alternatives

Depending on deployment environment and use case, various alternatives are available.

Pick a deployment path based on your scale, availability, and workflow needs. Kubernetes targets high availability and higher scale. The sandbox VM targets a single-machine, all-in-one setup. Local test deployment targets fast runner development without provisioning a full environment.

Summary: the 3 supported alternatives

1) Kubernetes Deployment (higher scale & high availability)

Use this when you need multi-node scalability, workload isolation, and high availability patterns. This is the typical approach for shared environments and production-grade operations.

• Best for: higher-scale production, HA requirements, shared staging/dev

• What you get: initial core platform install, then self-service module installs via admin UI

• Automation options: fully automated or step-by-step

• Typical duration: ~30–60 min (fully automated) or ~2–3 hours (step-by-step), depending on customizations

Continue here: Kubernetes Deployment

Both Kubernetes and the sandbox VM are supported paths. Choose Kubernetes when you need HA/higher scale, and choose the sandbox VM when you want a single-VM environment with everything bundled.

2) Sandbox VM Deployment (single VM, Docker Compose)

Use this when you want an all-in-one environment on a single VM. It spins up services via Docker Compose.

• Best for: evaluation, training, dev/test, small environments

• Minimum VM size: 4 vCPU, 16 GB RAM

• Included components (typical): Admin UI, controller/runner services, MongoDB, Kafka, Elasticsearch (profiles can disable parts)

• Config surface: mostly environment variables in composite/.env

Continue here: Sandbox VM Deployment

3) Local Test Deployment (run a runner on your machine)

Use this when you’re building or debugging runners, sagas, queries, and business rules. You run a local Spring-based event runner and test through its REST API.

• Best for: fast iteration on runner logic, local debugging

• What you need: Java, Gradle, sandbox repo, and connectivity to your backing systems (often MongoDB)

• What you get: local service process + REST endpoints for health checks and test flows

Continue here: Local Test Deployment

Quick decision guide

• Choose Kubernetes for higher scale, high availability, and multi-team shared environments.

• Choose Sandbox VM for a single-VM “everything included” setup.

• Choose Local Test for runner development when you don’t want to deploy infrastructure.