The Myths (and Costs) of Running Node.js on Kubernetes

UpdatedSeptember 22, 2025

•5 min read•View as Markdown

The Myths (and Costs) of Running Node.js on Kubernetes

Luca Maraschi

Comments (3)

Join the discussion

Anton Melser10mo ago

What a load of rubbish. What, pray tell, do you want to replace it with? Bare metal? VPS? You think that is more elastic and cost effective? If you can run stuff on Lambda or similar, fine. But that's a fundamentally platform and set of affordances and constraints, that may or may not fit...

So you need to have proper SRE/DevOps engineers running your platform. How bout you "full stack script kiddies" realise that platform engineering is actually complicated and requires more that just knowing about the latest fashionable bundler!

Anders10mo ago

Good article. Some bulletpoints from my experience running an e-commerce shop on GKE - no clustering.

On GKE (GCP) one can leverage performance HPA for more aggressive autoscaling. Recommended - as baseline set of service can be kept smaller.
Use a distinct metrics-endpoint for HPA - one which is queried much more frequently compared to your “normal” metrics-endpoint.
Article optimizing-nodejs-performance-v8-memory-management-and-gc-tuning - great article. Ensure optimal memory segmentation as compute (CPU) is more expensive than data (memory). This was a very good improvement.
We use request per second, ELU and CPU as distinct metrics for autoscaling. They work good in combination.
Use a local DNS cache.
Use another allocator instead of malloc - jemalloc (even despite being archived) is a good choice. Manage to keep memory under control. THP are recommended for optimal allocation.

More points obviously - happy to discuss if anyone need input.

Ryan Hamonangan10mo ago

i have been manage node on k8s for years. from my experience. it depends based on application types.

is it b2b? employees only? set auto minimum higher on working hours.

is it only crud/db + some http call to another vendor? yeah burstable as this article mention

is it running some heavy duty worker. like sharp (image processing) / report server using puppeteer for example. so its nodejs but underneath it there is something like c++ Library. then autonscale based on metrics is good.

More from this blog

Run Nitro applications on Watt with @platformatic/nitro

Nitro is a server toolkit used by many JavaScript applications. You can use it on its own for APIs or full-stack servers, or combine it with Vite to get a familiar frontend workflow with a Nitro serve

Jul 28, 20269 min read

Run Nitro applications on Watt with @platformatic/nitro

Stop Pinning Everything: Quantifying Upgrade Risk in Durable Workflows

All durable execution engines give the same versioning advice: pin your runs. Temporal pins runs to worker builds. Vercel's Workflow SDK pins each run to the deployment that started it. Azure Durable

Jul 21, 202612 min read

Stop Pinning Everything: Quantifying Upgrade Risk in Durable Workflows

Run Durable Eve Agents on Kubernetes with Platformatic

Eve organizes AI agents in a simple way: use Markdown for instructions and skills, TypeScript for tools, and separate files for channels, schedules, and subagents. Behind this setup, Eve relies on the

Jul 16, 202611 min read

Run Durable Eve Agents on Kubernetes with Platformatic

Stop Request Stampedes at the Gateway with Platformatic Deduplication

Picture an online store launching a new product and sending out a mailing list campaign. Thousands of users click the same link at once. The product page, built with a Node.js app like Next.js, needs

Jun 30, 202611 min read

Stop Request Stampedes at the Gateway with Platformatic Deduplication

AWS ECS auto-scaler is broken (don’t worry, we’ve fixed it)

How Platformatic ICC Outperforms AWS ECS Target Tracking and Step Scaling

Jun 4, 202625 min read

AWS ECS auto-scaler is broken
(don’t worry, we’ve fixed it)

Platformatic Blog

173 posts

Kubernetes is hailed as the gold standard for scaling applications. But when it comes to Node.js, the story isn’t nearly as smooth. Running Node.js inside Kubernetes often feels like forcing a sports car to tow a freight train. The abstractions don’t line up. Node.js thrives on lightweight concurrency and bursty workloads, while Kubernetes insists on heavyweight CPU and memory reservations. The result? Bloated cloud bills, idle resources, and scaling delays that show up precisely when traffic spikes.

The irony is brutal to ignore: the platform meant to deliver elasticity can slow Node.js down and make it more expensive to run. Teams that blindly trust Kubernetes defaults discover too late that their “autoscaling” comes with lag, their “optimized” pods are overprovisioned, and their business is footing the bill for inefficiency.

Running Node.js in Kubernetes isn’t just a technical puzzle—it’s a financial one. And the companies that win will be the ones willing to question the hype and rethink how Node.js is deployed at scale.

Myth #1: Autoscaling Works Out of the Box

Scaling lag is real, and Node.js traffic bursts don’t wait.

The story we’re sold: Horizontal Pod Autoscaling (HPA) and Vertical Pod Autoscaling (VPA) make workloads elastic. Kubernetes will sense load, adjust replicas or resources, and your Node.js apps will scale seamlessly.

The reality is that autoscaling reacts too slowly to the kind of bursty, unpredictable traffic Node.js often faces. Metrics must be collected, averaged, and exceeded thresholds before scaling begins. Spinning up new pods still takes more time. By the time your application has scaled, the traffic spike may already have passed—leaving customers with slow responses and your team scrambling to explain why latency suddenly spiked.

Business impact: Scaling delays translate directly into revenue risk. Think checkout flows that time out, ads that don’t serve, or API responses that breach SLAs. For high-traffic systems, even a 30-second lag in scaling can mean lost conversions, unhappy customers, and contractual penalties.

Myth #2: Requests and Limits Are Just Tuning

It’s not about tuning—it’s a structural mismatch.

Kubernetes encourages developers to specify CPU and memory requests/limits. In theory, this is about fairness and stability. In practice, it doesn’t match the way Node.js actually uses resources.

Node.js is single-threaded at its core, with concurrency achieved through asynchronous event loops. CPU consumption spikes irregularly depending on garbage collection, event loop lag, or bursty traffic patterns. Memory usage can fluctuate based on how V8 optimizes execution. These dynamics don’t map neatly to Kubernetes’ rigid allocation model.

Teams end up choosing between:

Overprovisioning means paying for resources that mostly sit idle.
Underprovisioning risks runtime stalls, throttling, or outright crashes when Node.js hits unexpected peaks.

Both are costly in different ways: one eats your cloud budget, the other erodes reliability and customer trust.

Myth #3: Elasticity Equals Efficiency

Elastic scaling isn’t the same as cost-efficient scaling.

One of Kubernetes’ most significant selling points is cost control: scale up when you need capacity, scale down when you don’t. But this elasticity doesn’t always translate into efficiency for Node.js workloads.

Because of scaling delays and unpredictable bursts, most teams hedge by reserving extra capacity “just in case.” Those buffers are rarely used, but they show up every month in the cloud bill. And when autoscalers do kick in, the lag means you’re still burning money on idle nodes while waiting for new ones to start.

Business impact: Costs rise faster than traffic. The CFO sees cloud spend growing disproportionately, while the CTO insists the system is “elastic.” The truth is, elasticity without efficiency is an expensive illusion.

Myth #4: Kubernetes Is the Best Platform for Everything

Node.js isn’t Java. Stop treating it like it is.

It’s tempting to think of Kubernetes as the one platform to rule them all. But that assumption ignores the fact that Kubernetes was designed with a very different class of workloads in mind—long-running, multi-threaded services where adding replicas and adjusting resource slices work smoothly.

Node.js is different. It’s lightweight, bursty, and efficient when tuned for its concurrency model. Forcing it into the same mold as Java or .NET applications is like trying to manage a drone fleet with shipping-container logistics. Possible? Sure. Optimal? Not even close.

Rethinking Node.js in Kubernetes

So what does “good” look like? Running Node.js effectively in Kubernetes requires breaking free from the myths and bending the platform to fit Node.js, not the other way around.

Here are the shifts forward-looking teams are making:

Smarter scaling signals
Move beyond CPU and memory. Node.js exposes metrics like event loop lag, request queue depth, or custom business KPIs (e.g., checkout latency). These are better predictors of when to scale.
Finer-grained resource strategies
Instead of blunt CPU/memory limits, use instrumentation to understand actual runtime behavior and allocate resources dynamically. Pair with more innovative placement strategies (e.g., bin-packing Node.js workloads together).
Faster reaction loops
Reduce scaling lag by pre-warming pods, using more aggressive metrics polling, or leveraging advanced autoscalers that learn traffic patterns. For mission-critical apps, scaling needs to happen in seconds, not minutes.
Cost as a first-class metric
Don’t treat efficiency as a “bonus.” Model the cost of buffers, scaling delays, and overprovisioning alongside your uptime and latency SLAs. Tie engineering decisions to financial outcomes.
Cultural shift: Node.js ≠ JVM
Running Node.js well means embracing its nature: event-driven, asynchronous, resource-sensitive. Stop managing it like a monolithic enterprise app and treat it as the unique runtime it is.

So… The Bottom Line

Yes, Kubernetes can run Node.js. But efficient, scalable Node.js in Kubernetes requires a different mindset. The defaults are built for someone else’s workloads. If you accept them blindly, you’re signing up for higher bills, slower responses, and unnecessary complexity.

The real question isn’t whether Kubernetes can run Node.js. It’s whether you are willing to rethink how you run Node.js in Kubernetes—or will you let the myths bleed money and performance out of your stack?

Command Palette