Node.js Hosting Platform Evaluation Criteria for Production Migration

Cloud infrastructure spending crossed $100 billion in a single quarter in Q3 2025 and stayed there, running $90.9B, $95.3B, $102.6B, then $110.9B, quarter over quarter. That's the market teams are dropping their apps into right now, not some settled, mature landscape with fixed prices, but one that's still climbing fast under everyone's feet. Picking a Node.js hosting platform for production is a decision about long-term reliability that goes beyond pricing and feature comparisons. It's a sequence of filters, and getting that order wrong means finding out what a platform really costs only after leaving it has become expensive.

Get the order right and most of the later arguments about price disappear on their own. A survey of 100 CFOs at SaaS and IT companies put average cloud spend at 10% of revenue, and that ratio climbs as the app grows, it doesn't shrink. Add the real cost of a production migration, DNS cutover, database migration, CI/CD rewiring, retraining whoever's on call, and the platform a team picks tends to outlive whatever plan they had for it. Heroku's shift to a "sustaining engineering model" in February 2026 (no new features, enterprise contracts closed to new customers) turned this from a someday-decision into a right-now decision for a lot of teams still parked on it. What follows is built for that kind of pressure, not a leisurely planning cycle.

How Node.js framework shape determines the hosting model before anything else

Before price, before compliance, before anything else: can the platform run the actual process model the app uses? Skip that question and everything that follows gets built on sand, and the sand shows eventually.

Node.js apps don't all behave the same way at runtime. Four shapes cover most production cases, and mixing them up is where teams waste the most time later:

• Express.js or NestJS APIs: a persistent process that binds to a port, needs health checks, and scales horizontally by running more copies.
• Next.js with server-side rendering or API routes: also a persistent Node.js server. It can't be exported as static files, full stop.
• Next.js as a fully static export: no Node server at runtime at all, just files sitting on a CDN.
• Nuxt: the same split as Next.js. A persistent Nitro-based server on one side, generated static output on the other.

NestJS adds a wrinkle worth flagging on its own: a TypeScript compile step has to run before the production process even starts. So the platform needs build and start as two separate, explicit commands, not one blended step that assumes the runtime is already sitting there ready to run.

Version support trips up more teams than framework shape does, honestly. As of July 2026, Node.js 24 is the active LTS release, and Node.js 22 sits in Maintenance LTS. Versions 18 and 20 are dead, end of life, no security patches coming. A platform that only offers "latest," with no way to pin a specific supported version, will break a deploy without warning someday, and it won't apologize for it. For new production builds, target 22 or 24. Nuxt now requires 22.x or newer. Next.js will technically run on 20.9, but targeting 22 or 24 for production is the safer choice given that those are the active supported lines.

Serverless platforms like Vercel handle stateless APIs, webhooks, and microservices well. They're a bad match for anything stateful, anything built around long-running connections, WebSockets or server-sent events especially. If that's the architecture, cross serverless-first platforms off the list right here, before comparing a single price tag. And while Bun runs faster in CI pipelines, Node.js 22 and up is still the more proven runtime for long-running production servers. Treat Bun support as a bonus on a platform, not a requirement to filter by.

Teams that skip this step end up deep in a pricing or compliance comparison for a platform that literally cannot run their app as built. That's wasted time, and every hour of it was avoidable.

What deployment model fit means for persistent-process vs. serverless-first applications

Persistent-process platforms, Render's web services, Railway, Fly.io, AWS Elastic Beanstalk, keep a container running continuously. That's the right model for Express APIs, NestJS services, anything using SSE or WebSockets, and server-rendered Next.js or Nuxt apps.

Serverless-first platforms like Vercel abstract the server away entirely, which fits stateless Next.js API routes, webhooks, and pages served off a CDN. Vercel's Fluid Compute brings cold starts down to around 250 milliseconds. That's fast, but it's still a cold start, and pretending otherwise just delays the problem for whichever workload can't tolerate lag on the first request.

A few numbers worth knowing before comparing platforms. Render's free tier sleeps after 15 minutes of inactivity, which rules it out immediately for anything that needs to be always on. Its Starter tier at $7 a month is the real entry point for always-on hosting, though most production workloads end up needing the $25-a-month Standard tier instead. Railway supports always-on persistent processes and throws in one-click Redis on its Hobby plan at $5 a month, a solid baseline for stateful or connection-heavy apps. Fly.io runs an auto-suspend model with per-second billing, keeping idle costs near zero, and its real strength is running Node.js at the edge, physically close to users, for apps where global latency actually bites.

Deployment fit also covers what happens off the main web process. Heroku's old Procfile model, where each process type, web, worker, cron job, becomes its own service, shows up again on platforms like Render. Any team running background workers or queue consumers alongside their API needs to check how a platform handles that before it looks at a single dollar figure.

There's also a real difference between a platform that can deploy the app and one that runs it correctly under real load. Health checks, zero-downtime deploys, restart behavior, horizontal scaling, those operational details are what separate something fine for staging from something actually ready for production.

How scalability characteristics diverge across platform types under real growth

Autoscaling by itself isn't a differentiator anymore. Nearly everyone offers some version of it now. What actually matters is how it scales and what it costs at each step up: horizontal or vertical, usage-based or instance-based, automatic or something a human has to trigger by hand.

Managed platforms like Render, Railway, and Vercel scale automatically, but that convenience costs visibility. Teams don't see exactly what's running underneath, or what each scaling step actually costs them. VPS-based platforms with a management layer on top, RunCloud or ServerAvatar for example, hand that control back to the team, but then someone on staff has to actually own those scaling decisions. Fine for a team with an operator. A liability for a team without one.

RunCloud's tiers show that cost curve moving in real time: Professional at $19 a month supports up to 50 servers, Business at $49 a month adds zero-downtime atomic deploys and team management, Enterprise at $399 a month scales to 500 servers and 50 team seats. AWS Elastic Beanstalk takes the opposite approach: full access to EC2 scaling, load balancing, and health monitoring, with no charge for the orchestration layer itself. Costs are pure resource costs, starting around $3 to $5 a month for a small app, but they climb with usage in ways that need someone actually watching the dashboard, not a set-it-and-forget-it mindset.

Multi-cloud serverless setups are growing fast, as teams chase best-of-breed features without betting everything on one vendor. That instinct is mostly wrong for small teams, though. Multi-cloud adds real operational overhead, and most startups don't have the headcount to absorb it. Single-cloud with a clear path to portability is the more honest goal right now, and BYOC (covered below) is what keeps that path open without locking anyone in.

The whole point here is catching two specific failure modes: platforms that scale automatically but get expensive fast at moderate traffic, and platforms that stay cheap early but need a human to step in manually every time they need to scale.

Why compliance posture must be evaluated before signing a contract, not after

SOC 2 and HIPAA requirements almost never show up early. They show up as a contract condition from an enterprise buyer, or a line item in fundraising diligence, usually well after the app is already live in production. By that point, switching hosting platforms is a multi-month project, not a weekend task, and everyone involved knows it.

Compliance really comes down to how a platform's practices hold up under scrutiny, not just which certifications it holds. It's about what the platform lets a team actually prove: audit logs, access controls, data residency, and a clear answer to who has access to what.

Shared-tenant PaaS platforms run into a wall here that no amount of paperwork fixes. The underlying cluster is shared across other customers and isn't visible to any single tenant, so there's no way to hand an auditor the infrastructure-level evidence they're often asking for. Teams that treat role-based access control, single sign-on, and alerting as compliance basics should confirm those exist before signing anything, not after the auditor asks for them. PandaStack, for instance, includes RBAC, SSO through Google and Azure, and built-in alerts starting at $12 a month.

Data residency is part of the same question: which cloud region the app actually runs in, whether the team can enforce that, and whether the platform can produce evidence that it's being enforced. Meaningful SOC 2 or HIPAA compliance really only works when the infrastructure runs inside the team's own cloud account rather than on shared infrastructure, because that's the only way to produce the cluster-level evidence auditors ask for. That's the structural argument for the tenancy model covered next.

For teams in healthcare, fintech, or enterprise B2B, deferring this check has a real price tag attached to it. A compliance remediation project bolted onto a platform that was never built for it almost always costs more than the migration would have cost at the start. Don't let the auditor be the one who breaks that news.

What cloud tenancy model determines about control, compliance, and long-term economics

Tenancy model is the piece most platform comparisons skip entirely. It's invisible on a pricing page. It only becomes visible the moment a team needs an audit trail, a custom network setup, or a cost export their CFO can actually use for anything.

Shared-tenant platforms, most traditional PaaS defaults fall here, run a team's workload on infrastructure the platform owns and shares across every customer on it. Easier to start with, but a team can't inspect the underlying cluster, can't enforce data residency beyond whatever region settings the provider exposes, and can't pull infrastructure costs into its own cloud bill.

Bring-your-own-cloud, BYOC, flips that arrangement. The team's workloads run inside its own cloud account rather than on infrastructure the platform controls. The team owns the cloud bill, can inspect and audit the infrastructure directly, keeps its own compliance evidence, and holds onto whatever pricing it already negotiated with its cloud provider, reserved instances or committed-use discounts included.

For any team that expects an audit within the next two years, BYOC should be the default, not a nice-to-have upgrade path someone gets to later. It gives a team the ease of a managed platform without giving up the control and economics of owning the cloud account underneath it. Compliance turns into something the team checks off, not a project that eats a quarter. And if the platform relationship ever ends, the VPC, the databases, the services, all of it stays in the team's own account. Nothing needs rebuilding from scratch.

AWS Elastic Beanstalk illustrates a related principle. The workload runs in the team's own AWS account, costs show up directly on the AWS bill, and the team controls the infrastructure end to end. The tradeoff is real: Beanstalk offers less abstraction than a modern PaaS and has a steeper learning curve to match it.

The economics compound over time, and slowly at first. At low scale, a platform's markup on shared infrastructure barely registers next to the convenience it buys. At growth scale, the gap between paying that markup and paying resource costs directly in a team's own cloud account turns into a line item someone on the finance team has to explain out loud.

How to read a platform's pricing model for what it will actually cost at scale

The gap between a platform's advertised starting price and what it actually costs under real production load is probably the single biggest source of platform regret out there. The number that matters is the total cost after factoring in everything beyond the sticker price. It's the cost structure at three times current traffic, and again at ten times.

Per-second or usage-based billing, a model Fly.io uses, is genuinely cheaper for apps with bursty or unpredictable traffic. But it only pays off if a team knows its cost envelope at peak load, not average load, or the first surprise invoice will do the explaining for them instead.

Per-user pricing works differently. Vercel Pro runs $20 per member per month; Netlify Pro is a flat $20 a month with unlimited members. A small, high-traffic team might find per-member pricing cheap. A large team running moderate traffic often finds it painful instead. Netlify's free tier, for reference, includes 300 credits a month along with 100 GB of bandwidth and 300 build minutes, numbers that show exactly which resource a growing team hits the ceiling on first: bandwidth, build minutes, or function calls.

Resource-based, transparent pricing, where a team pays for the compute it actually uses with no markup on idle capacity, lines platform incentives up with the team's own incentives. Idle resources on a dyno-based or always-on billing model are pure cost with zero return. That's the whole case against them.

Before committing, ask for a cost projection at expected P95 traffic, not average traffic, and build one yourself if the platform won't. A platform that can't produce that projection ahead of time is asking the team to find out the real number after it's already live. The 10%-of-revenue cloud spend figure from that CFO survey is a useful gut check here: a team already sitting at that ratio before it's even scaled has a cost structure problem that switching platforms alone won't fix, though a platform with better tenancy economics can bring that number down meaningfully.

Applying the criteria sequence to the platforms the market currently offers

Vercel fits Next.js apps using SSR or static export best, with zero-config setup, built-in OAuth, and a track record at scale (Zapier and Vapi both run on it). Cold starts land around 250 milliseconds with Fluid Compute. Pricing runs per member at $20 a month on the Pro tier, scaling with headcount rather than traffic. Its shared-tenant infrastructure caps how far it can go for regulated workloads. It clears the framework-shape and deployment-model filters for Next.js teams, then stalls on tenancy for anyone needing audit-ready infrastructure.

Railway is built for stateful or SSE-based Node.js apps that need an always-on persistent process, with one-click Redis and a Hobby plan starting at $5 a month. It clears deployment-model and scalability checks for small to medium stateful workloads. It's shared-tenant, and pricing tracks usage rather than seats.

Render offers the simplest path to a production-ready deploy, with predictable billing starting at $7 a month on Starter. Its free tier sleeps after 15 minutes of idle time, which rules it out for always-on production use, no exceptions. Git-based deploys, autoscaling, free SSL, and CDN come standard, with native Node.js support and a migration team for large database moves. Shared-tenant infrastructure caps its compliance posture. It clears the deployment-model bar for stateless APIs and full-stack apps.

Fly.io is the strongest option for global performance needs and cost control on bursty traffic, with per-second billing and auto-suspend keeping idle cost close to zero. It runs Node.js at the edge, close to users, which matters for latency-sensitive or globally distributed apps. It clears scalability and cost-transparency checks for that use case. It's shared-tenant too.

AWS Elastic Beanstalk runs workloads inside the team's own AWS account. There's no charge for the orchestration layer itself; resource costs run roughly $7 to $18 a month for a small app and climb from there with usage. It offers full control and full compliance evidence, at the cost of a steeper learning curve and more operational ownership than a managed PaaS asks for. It clears both the tenancy and compliance filters, but the team has to actually run the thing day to day.

DigitalOcean App Platform is a fully managed PaaS with straightforward Node.js deploys and predictable, transparent pricing, a reasonable fit for teams that want managed simplicity without losing a clear read on what they're paying for at each tier.