Most affordable · Cloud options
- 01Droplet Basic · 1 GiBDigitalOcean$6.00 USD / month
- 02Lightsail · 1 GBAWS$7.00 USD / month
- 03Render · StarterRender$7.00 USD / month
How to ship your app to production: PaaS, containers or Kubernetes
Deploy from Git with separate environments and clean configuration
The data, today
The context
Moving an app from your machine to production involves decisions worth making once and making well: where it runs, how code gets there, how testing is kept apart from production, and how each environment is configured without pasting secrets by hand. Many problems in the first months, such as deploys that corrupt data or credentials leaked into a repository, trace back to improvising one of these steps under deadline pressure.
The first choice is the level of abstraction. A PaaS deploys from Git and handles certificates, basic scaling and logs; managed containers give you more control over the runtime; Kubernetes gives you all the control and all the responsibility. CloudOps platforms aim for a middle ground on top of your own cloud account. Here we compare the criteria for choosing between them and cover the steps every option needs.
What to decide
- 1
PaaS, managed containers or Kubernetes?
Count your services, the people with operations experience, and any networking or compliance requirements. With few services and no platform team, a PaaS gets you moving. If you need custom images or private networking, go with managed containers. Kubernetes pays off with many services and someone who owns it. Compare monthly cost plus operating hours.
- 2
How do I set up CI/CD from Git?
Every push runs tests and builds an artifact, an image or package, tagged with the commit. That same artifact is promoted from staging to production and never rebuilt. Track time from merge to production and the rollback rate; if both are high, the pipeline needs work.
- 3
How do I separate environments?
At minimum, staging and production with distinct databases, credentials and accounts or projects. Staging should match production in runtime version, migrations and configuration. No production credential should be reachable from staging or from developer machines.
- 4
How should I handle env variables and DATABASE_URL?
Keep secrets in the platform's secret manager or a dedicated secrets service, never in the repository. Each environment gets its own DATABASE_URL with a least-privilege user and an encrypted connection. Validate on startup that every required variable is present and fail fast if one is missing.
- 5
What do I need for DNS and domains?
Register the domain under a company account, not a personal one, and manage DNS with a provider that has an API so records can be automated. Lower TTLs before migrations, use auto-renewing certificates and give staging its own subdomain. Document who has access to each account.
Common mistakes
- Sharing one database between staging and production.
- Rebuilding the image for production instead of promoting the one already tested in staging.
- Registering the company domain under a developer's personal account.
Tools and comparators
Guides to go deeper
- Deployment & CI/CD · 8 minDeploy Your App Fast Without EC2, VPC or IAM: A PaaS Guide
- Deployment & CI/CD · 5 minDeploying a frontend from Git to AWS
- Deployment & CI/CD · 10 minEnvironment variables and DATABASE_URL in production: a full guide
- Networking & DNS · 9 minLink a GoDaddy, Namecheap or Google Domains domain to AWS Route 53
Want a recommendation for your case?
Tell us your volume and the options you are weighing. We reply in writing with the numbers of your real usage; no commitment.
Request advice
No provider pays for its position. Indexes come from LLM Stats; prices from each provider's standard API. How we measure
Other solutions
The Codifly briefA clearer perspective.
A clearer perspective.
In your inbox.
Analysis, guides and new technology comparisons.