What are the deployment options?
There are several ways to run a backend in production, on a spectrum of control versus convenience: a raw virtual machine, a managed platform, serverless functions, or containers on an orchestrator. Each trades effort, cost, and flexibility differently.
Why it matters
Where and how you deploy shapes cost, scaling, and how much operations work falls on you. Junior engineers often pick the most complex option because it sounds impressive; senior ones pick the simplest that meets the need. Knowing the trade-offs lets you choose deliberately and defend it.
What to learn
- Virtual machines and full control with full responsibility
- Platform-as-a-service for push-to-deploy simplicity
- Serverless functions and their cold-start and statelessness trade-offs
- Containers and when an orchestrator is justified
- Environments: dev, staging, production
- Zero-downtime deploys and health checks
- Matching the option to team size and traffic
Common pitfall
Jumping straight to Kubernetes for a small app. The operational overhead dwarfs the benefit until you have real scale and a team to run it. Start with a managed platform or a single container, and move to an orchestrator only when concrete needs — many services, fine-grained scaling — actually demand it.
Resources
Primary (free):
- 12-Factor App · docs
- MDN — Deployment · docs
- Fly.io — Docs · docs
Practice
Deploy your API to a managed platform that builds from your repo. Set its environment variables through the platform, add a health check endpoint, and confirm a new push redeploys it. Done when your service is reachable at a public URL and a fresh commit ships automatically.
Outcomes
- Compare VPS, PaaS, serverless, and containers by trade-off.
- Pick the simplest deployment that meets the requirement.
- Separate dev, staging, and production with config.
- Deploy a service with a health check and automated redeploys.