Deploying to the Cloud

"The cloud" is a broad term, but for deploying a Node app it comes down to a handful of patterns: PaaS (platform-as-a-service) platforms that take your code or container and run it for you, container orchestration services that run your Docker images at scale, and managed infrastructure (load balancers, managed databases, CDNs) that handles the operational work you don't want to do yourself. This page surveys the major options — Render, Railway, Fly.io, AWS, GCP, Azure — what each is best at, and the universal deployment practices that apply across all of them.

PaaS — fastest path to production

Platform	Standout strength	Notes
Render	Simple, predictable pricing; Docker and Git deploys	Good all-rounder; free tier available
Railway	Instant deploys, great DX, provisioned databases	Generous free tier; fast iteration
Fly.io	Global edge deployment, Docker-first, latency-sensitive apps	More ops surface than Railway/Render
Heroku	The original PaaS; very mature ecosystem	More expensive than newer entrants

PaaS platforms take your code or image and handle servers, TLS, and scaling — the right default for most teams

For the majority of Node apps, a **PaaS** is the right first choice: you push code (or a Docker image), and the platform handles provisioning servers, TLS certificates, routing, and scaling. You pay in dollars and some control (you can't tune kernel parameters), but you save weeks of infrastructure work. **Render** and **Railway** are the modern favorites — generous free tiers, Git-based deployments where a push to `main` triggers a redeploy, built-in managed Postgres/Redis, and simple environment variable management. **Fly.io** specializes in deploying Docker containers close to users globally, worth it if latency across regions matters. They all share the same interface: set your env vars in the dashboard, configure build/start commands, and point at your repo. Start here; move to containers/Kubernetes only when your scaling requirements genuinely justify the complexity.

Container platforms — AWS, GCP, Azure

Service	Platform	What it is
ECS / Fargate	AWS	Run Docker containers serverlessly or on managed EC2
App Runner	AWS	PaaS-like; auto-scales containers from a registry
Cloud Run	GCP	Serverless containers; scales to zero; per-request billing
Azure Container Apps	Azure	Serverless containers with Dapr and KEDA integration
EKS / GKE / AKS	All three	Managed Kubernetes for full orchestration control

The major clouds offer serverless containers (run an image, pay per request) up to full Kubernetes — start with the simplest that fits

When you need the major cloud providers' ecosystem (managed RDS, S3, IAM, VPCs, compliance certifications), they all have **container-first deployment services**. **AWS Fargate/ECS** and **GCP Cloud Run** are particularly popular for Node: you push a Docker image to a registry and the platform runs it, auto-scaling (Cloud Run can scale to zero), managing TLS and load balancing. This is often the sweet spot — more control than PaaS, far less operational overhead than managing your own Kubernetes cluster. **Managed Kubernetes** (EKS, GKE, AKS) makes sense when you have complex multi-service architectures, strict networking requirements, or teams with existing Kubernetes expertise; it's powerful but genuinely complex. A Cloud Run or App Runner deployment of your Docker image is often enough, and much simpler.

Universal deployment practices

Build once, deploy the same artifact everywhere — build the Docker image once in CI, push to a registry, deploy that exact image to staging and production (not rebuild-per-env).
Never build in production — production servers should run a pre-built, tested image; npm install + compile at deploy-time is slow and risky (a broken registry or transient network issue takes down your deploy).
Use managed databases and caches — let the cloud provider handle Postgres/Redis backups, patching, and HA rather than running them in your own containers in production.
Set NODE_ENV=production and all secrets via the platform's environment variable / secrets store — never bake them into the image.
Configure health checks on the platform — so it restarts unhealthy instances and stops routing to them during deploys.
Enable autoscaling — set min/max instance counts and a CPU/concurrency metric to scale on; let the platform handle traffic spikes.

Build one image in CI, use managed services for the database, inject secrets at runtime, and configure platform health checks

Regardless of platform, a few practices separate reliable cloud deployments from fragile ones. **Build once**: create the Docker image in [CI](/nodejs/ci-cd), push it to a registry (ECR, Artifact Registry, Docker Hub), and deploy that exact SHA to every environment — don't rebuild per environment, which risks subtle differences. **Managed data services**: Postgres and Redis in your own containers need you to handle backups, failover, and patching; the cloud's RDS/Cloud SQL/ElastiCache handles all of that and is well worth the extra cost. **Runtime secrets**: inject credentials via the platform's environment variable store or a secrets manager (AWS Secrets Manager, GCP Secret Manager) — never bake them into the image (as the [Docker page](/nodejs/docker) warns). And **platform health checks**: configure the liveness and readiness endpoints you built in [preparing for production](/nodejs/preparing-for-production) so the platform routes traffic correctly during rolling deploys and restarts unhealthy instances.

Eliminate servers entirely for event-driven workloads: [Serverless Node.js](/nodejs/serverless).