Self-hosted mode is for teams that already need shared services.

Self-hosted mode runs split api, ingest, worker, and scheduler roles on PostgreSQL, MinIO, Valkey, and NATS. Use it when the one-binary Tiny path stops being enough.

2,200 eps Same-host stable throughput on the current self-hosted release lane.
48.82 ms Current query p95 on the same benchmark line.
4 roles api, ingest, worker, and scheduler separate the runtime duties.
391.8 MB Peak memory on the current self-hosted reference lane.

Pick the deployment shape first.

Shape Choose it when Skip it when
Tiny mode You want the fastest proof and one binary is still enough Shared services, split roles, or operator runbooks are already mandatory
Compose self-hosted You need the serious self-hosted stack with the smallest packaged baseline Your team already runs everything through Kubernetes tooling
Kubernetes / Helm Clusters, secret management, and day-2 operations already live in Kubernetes You would be adding cluster tax just to evaluate urgentry

When to use this

  • You already need shared PostgreSQL-backed infrastructure
  • You want split roles instead of one all-in-one process
  • You need operator workflows around backup, restore, and maintenance

Compose or Kubernetes, depending on the job.

docker compose
cd deploy/compose
cp .env.example .env
docker compose up -d
docker compose logs -f urgentry-api
kubernetes
kubectl apply -k deploy/k8s
kubectl -n urgentry-system get pods

Each role has one job.

Role Purpose
apiWeb UI, management API, query endpoints
ingestSDK envelope, store, and OTLP ingestion
workerAsync processing, projection, and backfill work
schedulerMaintenance and scheduled jobs
validation
bash deploy/compose/smoke.sh up

Validate the line you plan to run

  • Bring up the stack cleanly
  • Confirm the API role is reachable
  • Run the smoke path before you trust the rollout

Next docs

Use the deployment guide if you are actively rolling it out, or drop back to Tiny mode if your current requirement still fits in one binary.