Best Serverless Container Platforms for Node.js SaaS Apps in 2026

Best Serverless Container Platforms for Node.js SaaS Apps in 2026

For many Node.js SaaS teams, there is a large gap between a traditional PaaS and Kubernetes.

You may want Docker/OCI portability, automatic HTTPS, autoscaling, private networking, managed identity, revisions, jobs, logs, and scale-to-zero economics — but you may not want to operate Kubernetes control planes, node groups, ingress controllers, CNI plugins, cluster upgrades, Helm charts, or cluster autoscalers.

That gap is where serverless container platforms fit.

For Node.js SaaS in 2026, the strongest options to evaluate are:

1. Google Cloud Run
2. Azure Container Apps
3. Amazon ECS Express Mode
4. DigitalOcean App Platform
5. Koyeb

There is also an important 2026 AWS change: App Runner should no longer be a new-customer default. AWS moved App Runner into maintenance and stopped accepting new customers after April 30, 2026. Existing services remain operational, but AWS recommends Amazon ECS Express Mode for new containerized web applications and APIs.

Quick Recommendation

Choose Google Cloud Run when you want the strongest pure serverless-container model: scale to zero, high configurable concurrency, services, jobs, worker pools, strong Node.js guidance, revisions, and deep GCP integration.

Choose Azure Container Apps when Azure is your standard, KEDA-based event scaling matters, or you want Consumption and Dedicated workload profiles plus revision traffic splitting without running AKS.

Choose Amazon ECS Express Mode when AWS is your primary cloud and you want simplified ECS/Fargate deployment while keeping the underlying AWS resources fully visible and customizable.

Choose DigitalOcean App Platform when you want predictable container pricing, simpler operations, Git/container deployment, managed data services, and a smaller cloud surface area. Request-based autoscaling became GA in May 2026.

Choose Koyeb when global lightweight compute, per-second billing, autoscaling, and scale-to-zero are important without adopting Kubernetes.

2026 Comparison

Platform	Best For	Scale to Zero	Pricing Signal	Key Strength
Google Cloud Run	Pure serverless container experience	Yes	Request/instance CPU+RAM with monthly free grants	Strong concurrency, revisions, jobs, mature serverless UX
Azure Container Apps	Azure-native + event-driven workloads	Yes on Consumption	vCPU-seconds + GiB-seconds + requests; Dedicated also available	KEDA scaling, revisions, managed identity
Amazon ECS Express Mode	AWS-native container hosting	Not the same pure request-driven zero model	No Express fee; pay Fargate + ALB + CloudWatch + transfer	ECS flexibility without initial ECS boilerplate
DigitalOcean App Platform	Predictable SMB/startup hosting	Available for eligible services	Containers from $5/month	Simple pricing, request autoscaling, integrated platform
Koyeb	Global lightweight serverless compute	Yes, public preview	Per-second instances	Small instances, global footprint, scale-to-zero

1. Google Cloud Run

Cloud Run remains the cleanest implementation of “give the cloud a container and do not make me operate servers.”

A typical Node.js SaaS path is:

Artifact Registry -> Cloud Run service -> HTTPS + IAM + autoscaling + revisions -> Cloud SQL / Memorystore / Pub/Sub / Storage

Current request-based monthly free grants, based on us-central1 pricing, include 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests. Instance-based billing has free grants of 240,000 vCPU-seconds and 450,000 GiB-seconds.

Cloud Run currently supports maximum concurrency up to 1,000 requests per instance. That is especially relevant for Node.js because I/O-heavy APIs can often serve many concurrent requests while waiting on PostgreSQL, Redis, payment APIs, and other network dependencies.

Do not blindly set concurrency to the maximum. The correct number is the highest value that still satisfies latency, memory, event-loop delay, database-connection, and downstream rate-limit SLOs.

Google’s current Node.js optimization guide recommends starting the process directly with node, rather than npm start, where possible, to reduce startup overhead:

CMD ["node", "dist/server.js"]

For latency-sensitive endpoints, configure minimum instances; for low-value or intermittent endpoints, allow scale to zero.

On August 27, 2026, Google introduced Cloud Run instances for long-lived workloads that do not fit the normal request-driven service model. Together with services, jobs, worker pools, and GPU support, this shows Cloud Run expanding into a broader managed container execution layer.

Best fit: stateless Node.js APIs, webhooks, workers, and jobs on GCP where Kubernetes is unnecessary.

2. Azure Container Apps

Azure Container Apps is especially strong for event-driven Node.js workloads because autoscaling is built around KEDA concepts.

HTTP -> Node.js API Container App
Service Bus / event source -> KEDA -> Node.js worker replicas

The Consumption plan currently includes monthly free grants per subscription of:

• 180,000 vCPU-seconds
• 360,000 GiB-seconds
• 2 million HTTP requests

When an eligible app scales to zero, no resource-consumption charge applies.

Container Apps can also keep minimum replicas alive. When replicas meet documented idle conditions, Azure can bill them at reduced idle rates instead of active rates.

Current scaling limits allow a revision to use a minimum of 0 replicas and a maximum up to 1,000 replicas. Rules can be HTTP, TCP, or custom KEDA rules.

Revisions are immutable snapshots. In multiple-revision mode you can split traffic, for example:

v1 -> 90%
v2 -> 10%

Then observe metrics and either increase v2 or roll back.

Azure also supports Dedicated workload profiles for workloads that need single-tenancy characteristics, specialized hardware, or predictable allocated capacity.

Best fit: Azure-native SaaS, Service Bus/Event Hubs workers, event-driven processing, or teams that need revision traffic control without AKS.

3. Amazon ECS Express Mode

AWS’s serverless-container recommendation changed materially in 2026.

App Runner moved into maintenance. For new web/API container workloads, AWS now recommends Amazon ECS Express Mode.

With ECS Express Mode, you provide the container image plus the required IAM roles. Express Mode orchestrates a Fargate-based ECS service, HTTPS endpoint, load balancing, networking, autoscaling, and monitoring.

A major differentiator is transparency: the resources stay in your AWS account and remain directly accessible. This gives you a simple starting point without hiding ECS, Fargate, ALB, IAM, CloudWatch, and related infrastructure behind a closed PaaS abstraction.

Express Mode can automatically consolidate up to 25 services behind one Application Load Balancer where the networking configuration permits, reducing the “one small service, one ALB” cost problem.

There is currently no additional Express Mode fee. You pay for the resources created to run the application, including:

• Fargate compute
• Application Load Balancer
• CloudWatch logs and metrics
• data transfer
• attached AWS services

On July 1, 2026, AWS added custom task-definition support to ECS Express Mode. This allows advanced task-level configuration such as observability/security sidecars, custom health checks, ulimits, Linux runtime settings, and FireLens log routing while keeping Express Mode’s simplified deployment workflow.

Do not assume ECS Express Mode has the same zero-idle economics as Cloud Run. Its main value is AWS-native simplicity plus ECS flexibility, not necessarily the lowest possible cost for a rarely used endpoint.

Best fit: AWS SaaS already using RDS/Aurora, ElastiCache, SQS, EventBridge, S3, KMS, IAM, and CloudWatch.

App Runner in 2026

AWS formally announced that App Runner would stop accepting new customers after April 30, 2026. Existing App Runner services continue to work and receive security/availability support, but AWS says no new features are planned.

Existing customers do not need an emergency migration solely because of maintenance status. New applications should evaluate ECS Express Mode instead.

4. DigitalOcean App Platform

DigitalOcean App Platform is more PaaS-like than Cloud Run, but it is attractive when predictable monthly cost is preferable to hyperscaler billing complexity.

Current shared CPU container pricing starts at:

Plan	Price
1 vCPU / 512 MiB	$5/month
1 vCPU / 1 GiB fixed	$10/month
1 vCPU / 1 GiB scalable	$12/month
1 vCPU / 2 GiB	$25/month
2 vCPU / 4 GiB	$50/month

Dedicated CPU plans currently start at $29/month. Additional outbound bandwidth above the included allowance is $0.02/GiB.

A major 2026 improvement is request-based autoscaling, which became generally available on May 20. Services can scale from HTTP metrics such as:

• requests per second
• p95 request duration

Request-based autoscaling works with shared and dedicated CPU plans. CPU-based autoscaling remains available for appropriate plans.

This matters for Node.js because request pressure is often a better signal than average CPU for I/O-heavy APIs.

App Platform supports builds from source or prebuilt containers, managed health checks, workers, jobs, log forwarding, recent revision rollbacks, and managed database integration.

Best fit: small-to-mid SaaS teams that want predictable pricing and a compact cloud instead of dozens of infrastructure primitives.

5. Koyeb

Koyeb combines container deployment with per-second infrastructure billing and global placement.

Current Standard CPU prices include:

Instance	Spec	Price
Nano	0.25 vCPU / 256 MB	$0.0036/hour
Micro	0.5 vCPU / 512 MB	$0.0072/hour
Small	1 vCPU / 1 GB	$0.0144/hour
Medium	2 vCPU / 2 GB	$0.0288/hour
Large	4 vCPU / 4 GB	$0.0576/hour

The current Pro platform plan costs $29/month with $10 of included compute. Scale costs $299/month with $100 of included compute and a 99.9% SLA.

Koyeb’s Scale-to-Zero feature is currently in public preview. Supported Standard CPU/GPU services can use min instances = 0. The default idle period is five minutes; paid plans can configure longer idle periods.

Koyeb can autoscale from multiple factors, including CPU, memory, and request rate. With multiple rules, it selects the largest required instance count so capacity is not under-provisioned.

Best fit: globally distributed lightweight APIs and teams that want per-second infrastructure economics without a Kubernetes control plane.

Node.js Architecture Rules

Tune concurrency

Node.js is an I/O-concurrent runtime. A request may spend most of its lifetime waiting on PostgreSQL, Redis, object storage, or an external API.

Higher per-instance concurrency can reduce container count dramatically, but every concurrent request also consumes memory, sockets, database pool capacity, and downstream quota.

Load test CPU, RSS/heap, event-loop delay, p95/p99 latency, database wait time, and error rate before selecting the production concurrency value.

Protect the database

Serverless compute can scale faster than PostgreSQL connections.

100 instances x pool max 10 = 1,000 possible DB connections

Use a bounded local pool and, where needed, an external transaction pool/proxy such as RDS Proxy, PgBouncer/Supavisor, Prisma Accelerate, or another managed pooler.

Keep state outside containers

Treat container filesystems and process memory as ephemeral.

Store durable state in:

• PostgreSQL/MySQL
• Redis/Valkey
• queues
• object storage

Do not keep the only copy of an upload in /tmp or store shared login sessions in an in-process Map.

Handle graceful shutdown

Serverless instances terminate during scale-in, deploys, and maintenance. Node.js must drain correctly.

process.on("SIGTERM", async () => {
  server.close();
  await worker?.stop();
  await dbPool.end();
  await telemetry.flush();
  process.exit(0);
});

Stop advertising readiness before accepting new work, then drain existing work inside the platform’s termination window.

Use workload identity

Prefer short-lived cloud identity over static credentials in environment variables:

container identity -> short-lived token -> database/queue/storage/secrets

Use Google service identity, Azure managed identity, or AWS task roles as appropriate.

Use immutable deployment identities

Do not deploy only latest.

Use image digests or immutable version tags and keep revisions available for rollback.

Cold Start Optimization

Cold-start latency is roughly:

image pull + sandbox/container start + Node.js startup + module loading + app initialization + first dependency connection

Use multi-stage builds, smaller runtime images, direct node startup, lazy initialization where safe, and on-demand database connections.

Do not load large optional datasets or create maximum-size connection pools before the HTTP server can become ready.

Cost Model

Serverless containers are most attractive when utilization is variable.

For a steady 24/7 workload with consistently high CPU utilization, fixed/reserved container or VM capacity may be cheaper.

Model all of these:

• active CPU and memory
• minimum/idle capacity
• requests
• load balancers
• private networking/NAT
• egress
• logging/metrics
• database and cache

Cloud Run and Azure Container Apps can have extremely low compute cost for intermittent services because of scale-to-zero and monthly free grants.

ECS Express Mode has no Express surcharge, but Fargate + ALB + CloudWatch should be modeled together.

DigitalOcean provides an easier fixed monthly container model.

Koyeb charges instance time by the second and can reduce effective runtime through scale-to-zero.

When to Move to Kubernetes

Do not move only because traffic is high. Managed serverless container platforms can handle significant volume.

Move when you actually need controls such as:

• custom scheduling
• service mesh
• complex network policy
• controllers/operators
• DaemonSets
• unusual persistent storage
• advanced node/GPU placement
• a common Kubernetes platform across many teams/clouds

If the problem is only cost or latency, tune the serverless service before taking on a cluster.

Final Recommendation

For Node.js SaaS in 2026:

• Google Cloud Run is the strongest general-purpose serverless container default.
• Azure Container Apps is the strongest Azure/event-driven option.
• Amazon ECS Express Mode is now the AWS default to evaluate for simplified container deployment and replaces App Runner in new architectural decisions.
• DigitalOcean App Platform is ideal for predictable pricing and simpler operations.
• Koyeb is compelling for global lightweight compute, per-second billing, and scale-to-zero.

The architectural rule is simple:

Use serverless containers when you want the container as the application boundary, but you do not want the cluster as the operational boundary.

Keep services stateless, tune Node.js concurrency, bound database connections, use workload identity, handle SIGTERM, and use immutable revisions.