Installation¶

Ampora ships in three forms. Pick the one that matches your environment:

Before you start¶

Read the system requirements page first. It covers:

• supported platforms and runtime versions,
• CPU / memory / disk sizing per fleet size,
• PostgreSQL version requirements,
• network ports the deployment needs to expose,
• TLS certificate provisioning expectations.

Choosing between options¶

• Docker Compose is for development, demos, integration tests, and small single-host pilots. Not for production fleets.
• Kubernetes (Kustomize) is the production target. It bakes in HA behaviour, sticky sessions, PDB, HPA, NetworkPolicy, ServiceMonitor and every other primitive a real cluster expects.
• Self-contained binary is for environments without a container runtime — typically VMs or air-gapped appliances. You bring your own systemd unit, your own reverse proxy, your own database.

If your environment is k8s-shaped, prefer Kustomize. The other two paths are perfectly supported but you trade off ergonomics.

What lives where in the repo¶

deploy/
├── dev/                       # docker-compose support files
└── kustomize/
    ├── base/                  # generic, env-agnostic Kubernetes manifests
    └── overlays/
        ├── dev/
        ├── staging/
        └── production/

Dockerfile                     # multi-stage hardened distroless image
docker-compose.yml             # local "dev login" integration test stack
.gitlab-ci.yml                 # CI builds the same image you deploy

The container image you deploy in production is the same image CI builds for unit tests — there is no separate "release" build. This is deliberate; what you test is what you ship.