Run it where you want
Castra runs on your own infrastructure, from a single host to Kubernetes. Nothing calls home. One image runs in many roles, and each role scales on its own. If you would rather not run it yourself, see Castra Cloud.
Three ways to run it
1. Single host
Docker Compose on one machine. The simplest start, and enough for a small team.
2. Scaled
Compose across hosts, or Kubernetes. Roles are scaled independently, so a busy service desk does not need more of everything.
3. Cloud services swapped in
Keep the application on your infrastructure and point it at managed services. The open protocols make this a configuration change.
Quick start
Subject to change. Castra is in early development. File names, options and profiles may change before a release.
Copy the example environment file, then start the stack with Docker Compose.
cp deploy/compose/.env.example deploy/compose/.env
docker compose -f deploy/compose/compose.yml --env-file deploy/compose/.env up -dCompose profiles choose how much runs:
minimal: the smallest working setfull: everything, including search and maildev: for working on Castra itself
The compose files live in the source repository, which is not public yet.
On-prem default, or a cloud swap
Every dependency speaks an open protocol, so a managed service can replace the default.
| On-prem default | Cloud swap |
|---|---|
| Postgres | Amazon RDS |
| NATS | Amazon SQS |
| Valkey | Amazon ElastiCache |
| SeaweedFS, Garage or MinIO | Amazon S3 |
| Meilisearch or OpenSearch | Managed OpenSearch |
| Keycloak or Authentik | Entra ID, Okta, Google Workspace or Auth0 |
| Postfix | Amazon SES |
Other providers that speak the same protocol should work too: Postgres, S3, the Redis protocol, OIDC, SCIM, SMTP and OpenTelemetry.