Hosting Beyond Kinsta: Vercel, Fly, Railway, Cloudflare, and Friends

This is part of an ongoing series I am writing as I work my way through the modern web stack from a WordPress developer’s perspective. The series is aimed at WordPress veterans who, like me, have built things on the web for years and feel quietly behind the curve. The goal is broad literacy, not deep mastery. By the end you should be able to read any modern stack list and know what each piece is doing.

Each post comes with an audio companion (10-15 minutes, generated via NotebookLM) for gym or commute listening. Press play below if that suits you better than reading.

Hook

Hosting is the area of the modern stack where the old mental models break down most aggressively for WordPress developers. Kinsta, WP Engine, Servebolt, even SiteGround back in the day: you knew what you were getting. A Linux box, Nginx or Apache, PHP, MySQL, SSH access, a control panel, monthly billing tied to plan tier. The model has not changed since 2010.

Then someone tells you their Next.js app runs on Vercel, the auth lives on Clerk, the database is on Neon, the email is sent through Resend, and the file uploads go to Cloudflare R2. Five services, one application. Where does it “live”? Who is the host? What does the bill look like? When you say “the production environment,” what do you actually mean?

This module untangles the modern hosting landscape. What changed, what each major platform actually is, and how a WordPress veteran should think about hosting when “where does the code run” has fragmented into multiple answers per project.

Core Concept

The biggest shift is that hosting used to be one thing and is now three things.

The runtime is where your application code executes. In WordPress this was always the same machine that served files and ran the database. In the modern stack, your code can run on a server (Node, Bun, Deno), at the edge (Cloudflare Workers, Vercel Edge), or partially as static HTML built ahead of time. The runtime decides what features your app can use and how it scales.

The data layer is where your data lives. Modules 6 and 8 covered this: managed databases, auth providers, storage services. The data layer is almost always separate from the runtime now.

The delivery layer is how visitors actually reach your app. A CDN that caches static assets close to users. An edge network that routes requests to the nearest runtime. DNS that maps your domain to the right service. WordPress users met this layer through Cloudflare (the CDN), but it was bolted on. In the modern stack it is often the platform itself.

Modern hosting platforms differ on how they package these three. Some bundle everything (Vercel for Next.js apps). Some specialise in one layer (Cloudflare R2 for storage, Neon for data). Some offer all three but configured separately (Fly.io, Railway).

Pricing reflects this. Traditional hosting bills you for the machine: $20/month for a shared box, $200/month for a dedicated one. Modern platforms bill you for what you use: invocations, bandwidth, build minutes, database compute hours, storage GB-months. This is “great until it isn’t” — fine for small apps, occasionally surprising for ones that blow up.

The WordPress Analogue

Mental model: Vercel is to Next.js apps what Kinsta is to WordPress.

Both are managed platforms that take a specific kind of project and run it well. Both bundle CDN, deployment automation, scaling, and observability. Both have an opinionated workflow (you push to git, the platform builds and deploys). Both lock you in just enough that switching off involves real work.

The one big difference: Kinsta runs one piece of software (WordPress) on one runtime (PHP-FPM + Nginx + MySQL). Vercel runs anything that builds with a Node.js-compatible toolchain, on at least three different runtimes (Node, Edge, static). The flexibility is what makes Vercel feel both magical and complicated.

The Landscape

The major hosting platforms in the modern stack, in rough order of when you would reach for each.

Vercel. The hosting company started by the creators of Next.js. The Next.js story is so polished here that “Next.js on Vercel” has become its own bundled noun. Image optimisation, ISR, edge middleware, deploy previews per pull request: all native. Works with other frameworks too (Astro, SvelteKit, etc.) but Next.js gets the deepest integrations. Free tier is generous for hobby projects; pricing escalates fast at scale.

Netlify. The older Vercel-equivalent. Strong on static sites, decent on serverless functions, less aggressive on the Next.js front but solid on other frameworks. The Jamstack pioneer, slightly behind Vercel on modern features in 2026 but still a credible default.

Cloudflare Pages and Workers. Cloudflare’s run-your-code platform, built on the Workers runtime. Wildly cheap at scale, fast at the edge, but has different runtime constraints than Node (Workers run a subset of Node APIs, which trips up many libraries). Best for apps that already commit to the Cloudflare ecosystem (R2, D1, KV, Durable Objects).

Fly.io. A platform that runs your app in containers on a global Anycast network. Closer to traditional VPS hosting than Vercel, but with modern deploy and scaling. Good for apps that need long-running processes, WebSockets, or specific runtimes that the serverless platforms do not support.

Railway. A polished platform for running services (web apps, workers, cron jobs, databases) in containers. Great DX, good for monolithic apps and side projects. Less focused on edge or static, more on “I have a Node app and I want it to just run.”

Render. Similar to Railway. Long-running services, managed databases, cron jobs, all behind a clean dashboard. Often the choice for teams escaping AWS but not wanting Vercel-style serverless.

AWS / Google Cloud / Azure. The hyperscalers. Maximum flexibility, maximum operational overhead. Most modern stacks avoid touching them directly until the team is large enough to justify the complexity. Vercel and Netlify both run on AWS under the hood; you are paying them to handle AWS for you.

Self-hosted (Coolify, Dokku, Caprover) on Hetzner / DigitalOcean / OVH. For developers who want the modern deploy workflow but on their own infrastructure. Sets up a PaaS-like experience on a VPS. Worthwhile for cost-conscious projects or specific regulatory needs.

For a default-stack 2026 project: Vercel for Next.js apps, Fly.io or Railway for non-Next.js Node apps, Cloudflare Pages for static or Workers-friendly stacks, self-hosted for cost-conscious side projects.

What This Changes for WordPress People

Three practical implications.

The first is that “where does this site live?” stops being a single answer. A modern client project might run on Vercel, with a database on Neon, with file uploads on Cloudflare R2, with email through Resend, with auth on Clerk. The architecture conversation needs more vocabulary, but the pieces compose well once you know them.

The second is that pricing forecasting gets harder. Kinsta is a predictable monthly bill. Vercel + Neon + Clerk + Resend is several smaller bills that can spike unexpectedly under load. For client work, this changes how you scope projects: you build a small pricing-sensitivity model rather than picking a plan tier.

The third is that “WordPress lives where WordPress lived” but the rest of the stack can be modern. Keep Kinsta or WP Engine for the CMS. Run a Next.js or Astro frontend on Vercel. Have the two share a Neon database for non-content state. Hybrid hosting is the actual sweet spot for many client projects, not “abandon WordPress.”

Watch Out

A few traps.

Cold starts can hurt. Serverless platforms spin up the runtime per request after idle periods. The first request after idle can take 500ms to several seconds. This matters for low-traffic apps where every request is a “cold start.” Modern platforms mitigate this (Vercel Fluid, Cloudflare warm starts) but it is not eliminated.

Bandwidth pricing is the silent killer. Compute pricing is usually predictable; bandwidth pricing is where a viral post or a runaway video embed bankrupts a side project. Read the bandwidth tier of any platform before you commit, especially if you serve audio, video, or large images.

Region matters. A Vercel function in iad1 (Virginia) is fast for US users and slow for EU users. The database in eu-west-1 is slow for both unless the app is also in Europe. Pair the runtime and the data layer in the same region for most projects; multi-region is genuinely hard.

Lock-in is real, but subtle. Vercel-specific features (ISR, edge middleware, image optimisation) will not work on Cloudflare or Netlify in the same way. Cloudflare-specific features (Workers KV, Durable Objects) will not work elsewhere. Build with portability in mind if you might ever move; commit to platform-specific features only when the productivity gain is worth the lock-in.

Free tiers are bait, sometimes. Several platforms have generous free tiers that quietly enforce hard limits if you exceed them (Supabase pauses the database after a week of inactivity on free tier; Netlify charges $20 for the first build minute over quota). Free tiers are great for prototypes; budget the paid tier from day one for anything client-facing.

Going Deeper

If you want to develop a real sense of when to reach for which platform, a few resources worth your time.

YouTube, gym or commute friendly:

• “Vercel vs Netlify vs Cloudflare in 2025” by various creators on the Theo channel and similar. Watch the comparisons critically; opinions vary fast.
• “Self-hosting with Coolify” by Dreams of Code (~20 min). Useful even if you stay on Vercel; understanding the alternative sharpens your thinking.

Official docs worth bookmarking:

• Vercel docs. The “Functions” and “Edge Network” pages explain what makes Vercel different from a traditional host.
• Cloudflare Workers docs. Read the “Compatibility” pages first; they tell you what Node APIs work and what does not.
• Fly.io docs. Worth a skim even if you do not use Fly; the documentation style is unusually opinionated and educational.

Next post in the series goes deeper on what “serverless” and “edge” actually mean, since both terms get used loosely and the difference matters.

Related

Beyond Shared MySQL: Cloud Databases for WordPress Developers

Is There a WordPress Replacement in 2026? I Went Looking

What’s Beyond WordPress?

Email Addresses to Set Up When Opening a Company

AI Model Hosting in 2026: A Field Guide

Why Modern Web Feels Alien to WordPress Devs