Production deployment
What every internet-facing installation needs, wherever it runs: TLS, rate limits, client addresses, a closed admin API, MongoDB with authentication and least privilege, isolated functions and files. Then how Docker Compose and Kubernetes do it, and where to host.
backd deliberately leaves some protections to the infrastructure around it: TLS, request rate limits and sign-up spam, body size limits at the edge, and database security. They are the same wherever backd runs. This section separates what to put in place, on this page, from the technology that does it (Docker Compose or Kubernetes) and from the place it runs (cloud providers).
What every installation needs
| Protection | What it means | Docker Compose | Kubernetes |
|---|---|---|---|
| TLS | backd serves plain HTTP; terminate TLS in front of it and redirect HTTP to HTTPS | TLS | Traffic in |
| Rate limits | Limit requests per address, with a stricter zone for sign-up, password reset and verification | Rate limits | Traffic in |
| Client addresses | The proxy overwrites X-Forwarded-For; TRUSTED_PROXIES lists only your proxies | Client addresses | Traffic in |
| Body size | Cap request bodies at the edge | Request body size | Traffic in |
| A closed admin API | Public instances serve no admin API (BACKD_ADMIN_API=false); a separate internal instance does | Admin API | Who may reach the admin host |
| MongoDB | Authentication and TLS, reachable only from backd, a user limited to the configured collections, PROVISION_MODE=verify | MongoDB with authentication and TLS, Least-privilege provisioning | Network policies; what a managed database allows |
| Functions and files | The executor reaches only backd-server egress and the internal listener; object storage sits on a network only backd and its worker share | Functions, Files | Network policies |
| Secrets | Random, long, kept out of the configuration and the images, rotated without downtime | Administrators and API keys, Rotating passwords | Secrets on Kubernetes |
Before going public, go through the hardening checklist, and before exposing a realm the security checklist.
Pick the technology, then the place
- Docker Compose: a tested reference deployment (
deploy/production), end-to-end tested by CI. One host, or the model for your own. - Kubernetes: a Helm chart, the configuration baked into the image, a release pipeline, and the secrets of an installation.
- Cloud providers: where the infrastructure comes from: the Terraform and the walkthrough for a provider.
A tested reference deployment on Docker Compose: TLS, rate limits, client addresses, MongoDB with authentication and TLS, least-privilege provisioning, and a hardening checklist.
KubernetesThe Helm chart: the workloads, the configuration baked into the image, the release pipeline, rollbacks, network policies, who may reach the admin host, and the secrets of an installation.
Cloud providersWalkthroughs from an empty account to a running installation on a provider: the infrastructure it builds, what it costs, and what that provider cannot do.