Docker packages your application so it runs the same on a laptop and a server. Nginx stands in front of it, handling HTTPS, routing, and static files. Together they are the deployment backbone behind a large share of production web apps — including ours.
This guide covers the shape of a sane setup and the mistakes that cause most deployment pain.
The shape of the setup
Each service (web app, API, database, worker) runs in its own container, defined in a Dockerfile and wired together with Docker Compose on a single server, or a container platform when you outgrow one. Containers talk on a private network; only Nginx faces the internet.
Nginx terminates TLS, proxies requests to the right container, serves static assets with cache headers, and gives you one place for rate limits and request logs.
server {
listen 443 ssl;
server_name example.com;
# ssl_certificate and ssl_certificate_key configured via Certbot
location / {
proxy_pass http://app:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Environments and configuration
Keep configuration in environment variables, never in the image. The same container should run in preview and production with different variables, and secrets should live outside your repository.
Separate preview and production properly. Most 'the deploy broke the site' stories are really 'there was nowhere safe to test the deploy'.
Releases without downtime drama
Build the new image, start it alongside the old one, health-check it, then switch Nginx or the Compose service to it. Keep the previous image tagged so rollback is a restart, not a rebuild.
Automate it in CI/CD once the manual path works twice. Automating a process you have never run by hand just makes the failure faster.
- Health-check endpoint the deploy can wait on
- Previous image kept for instant rollback
- Database migrations run deliberately, not as a side effect of app start
- Logs and disk usage monitored — containers fill disks quietly
Backups and TLS, before you need them
Automate certificate renewal (Certbot or your platform) and test it. Back up databases and uploaded files on a schedule, and practise one restore; an untested backup is a hope, not a backup.
Common questions
For many products, yes — one well-kept server with Compose, monitoring, and backups beats a premature Kubernetes setup. Move to orchestration when you have multiple servers or strict uptime needs.
Managed platforms can replace Nginx. On your own server, Nginx earns its place for TLS, routing multiple services on one host, caching, and request logs.
Related services
Working on something like this?
These are the services behind this guide. Tell us about your project and we will reply with a useful next step — not a sales script.
