Deployment Architectures
KAWA can be deployed in several ways. This page shows the reference architecture for each option, illustrated with a diagram. For a side-by-side comparison of what each cloud provider supports, see Deployment Options.
1. AWS (EC2 / ECS)
A single-host Docker Compose deployment: KAWA runs as one OCI artifact on a single EC2 / ECS host. This is one of several supported options — for the Kubernetes (EKS) topology, see Deployment Options. The same pinned artifact is promoted unchanged across environments, and all network links are TLS-encrypted in transit.
Model
Single-host Docker Compose deployment — one OCI artifact on a single EC2 / ECS host.
Artifact
One OCI release bundling four images: KAWA Java (JDK 21 — core backend and platform APIs), KAWA AI (Python — inference via Amazon Bedrock, isolated in a filesystem sandbox), KAWA Workflow (BPMN 2.0 workflow engine), KAWA Python (runs user Python code, packages from PyPI).
Host
m7a.2xlarge — 8 vCPU, 32 GB RAM, AMD64 / x86_64, standard Linux. Runtime: Docker Compose (OCI).
Data & storage
PostgreSQL — back-office and entity store; Amazon S3 — user files, one bucket per environment; Databricks — SQL warehouse / lake.
AI
Amazon Bedrock — model inference.
Authentication
OIDC / OAuth2 — Auth0 or any OIDC-compliant IdP.
Integrations & email
SMTP — outbound email; Jira Cloud — issue sync; Bitbucket — source repositories; external / internal REST APIs.
Environments
Same pinned artifact promoted DEV → STAGING → PROD. Production runs active with an optional passive warm-standby host — see Disaster Recovery Architecture. Each environment has its own S3 bucket.
1.1 Deploy or upgrade
Deploy or upgrade an environment with a single command:
Replace <registry> and <tag> with the values provided by KAWA during onboarding. To upgrade, pull a new tag — there is no rebuild. The same pinned artifact moves unchanged from non-production to production.
Last updated
Was this helpful?

