Deploying toard

한국어로 보기

Deploying toard

Choose the platform that fits how your team already operates infrastructure. This page helps with the choice; docs/DEPLOY.md is the canonical source for manifests, values, commands, and environment-variable details.

Choose a deployment method

Method	Choose it when	What it provides
Docker Compose	You need a straightforward self-hosted server, demo, or small-team deployment.	Application, Postgres, and migrations in one Compose setup.
Kubernetes with kustomize	You already operate a Kubernetes cluster and need Ingress, TLS integration, and rolling deployment controls.	Raw manifests, health probes, an application Deployment, and an optional in-cluster Postgres setup.
Helm	You manage multiple environments or use GitOps tooling such as Argo CD.	A values-driven chart for image, database, secret, and Ingress configuration.

Postgres is the default backend for all approaches. ClickHouse is an optional backend for events and aggregates; account and authentication metadata remain in Postgres.

Before exposing the server

• Generate and store AUTH_SECRET through your secret-management process. It is required.
• Use TLS whenever developers reach the server over an untrusted network: ingest tokens are sent as Bearer credentials.
• Set TOARD_PUBLIC_URL when the external browser address differs from the address inferred by the application, such as behind a reverse proxy. This keeps generated installer endpoints correct.
• Set CRON_SECRET in production to protect /api/cron/*. This security boundary applies whether you use the built-in scheduler or an external scheduler; an external caller also uses the secret as its Bearer credential.
• Keep deployment secrets and database credentials out of repositories, Wiki pages, and logs.

For Compose, use a persistent deployment environment file or an equivalent secret-management mechanism. For Helm, prefer an existing external Secret in production. For Kubernetes manifests, keep the copied secret manifest out of Git as documented by the deployment guide.

Readiness and safe updates

Use the two health endpoints in your platform checks:

• /api/health is the liveness check and does not depend on the database.
• /api/ready is the readiness check and includes a database ping.

Kubernetes and Helm run migrations before starting the application through an init container. During rolling deployment, keep only backward-compatible schema changes in a release: add or dual-write first, backfill separately, and remove old fields only after old application versions have left service.

Platform notes

Docker Compose

Compose is the shortest route to a self-hosted installation. It pulls prebuilt application and migration images by default and starts the application, Postgres, and migration service together. Use it when one deployment host and a simple operations model are sufficient.

Kubernetes with kustomize

Use the k8s/ manifests when your cluster is the operating boundary. Configure the image, secret, and Ingress for your environment; use an external managed database by removing the bundled Postgres manifest and supplying the database connection through the documented Secret.

Helm

Use helm/toard when values-based configuration and repeatable environment promotion are important. The chart supports bundled or external Postgres, existing Secrets, image configuration, migrations, and Ingress settings.

Optional content collection

Deployment does not enable prompt and response storage by default. If you decide to offer it, review the encryption-key and database-role requirements in docs/DEPLOY.md and the boundaries in Privacy-and-security first.

Continue

• For a first Compose deployment, follow Quickstart.
• For developer onboarding, follow Roll-out-your-team.
• For the authoritative full deployment runbook, read docs/DEPLOY.md.