Netlify Alternatives

A designer I work with sent me a screenshot on a Monday morning: her portfolio site — a tidy static build, maybe four hundred visitors a month — was refusing to deploy. Not broken. Refusing. Netlify's credit limit had been hit on the free plan, and because the free plan's 300 credits are a hard cap with no automatic top-up option, the site sat there, existing but frozen, until the month rolled over or she reached for a card. She wasn't being cheap. She just hadn't understood that Netlify had moved new accounts onto credit-based plans in September 2025 and that "free forever" now came with a meter attached.

I don't think credit-based pricing is dishonest — arguably it's more honest than flat rates that punish the many to subsidise the few. But it changed the character of hosting on Netlify. This is a platform I've recommended for years for static sites and JAMstack builds: git-push deploys, deploy previews for every pull request, serverless functions, edge logic, forms, identity. The developer experience remains excellent. The billing model is now the thing to understand before you commit, and it's the main reason people come to me asking about alternatives.

To be fair to Netlify: the change was announced openly, documented in a changelog, and the free tier still exists rather than being quietly abolished. I've seen far worse repricing events in this industry. My objection isn't to meters — it's to customers discovering the meter the way my designer friend did, mid-deploy, with a client deadline behind them. Read the pricing page as a systems document, not a brochure, and most of the surprises disappear. Here's when leaving makes sense, when it doesn't, and where I'd point a static or app workload instead.

When it makes sense to leave Netlify

The credit wall becomes your uptime problem

The free plan gives you 300 credits a month and stops — hard limit, no auto recharge. On the paid side, Personal runs 1,000 credits for about $9 a month and Pro gives 5,000 credits for roughly $19–20 per member per month at time of writing (the pricing page and the changelog have shown slightly different figures, so check the current page). The failure mode is specific: credits are consumed by builds and deploys, so a busy development month — a redesign with fifty preview builds, a content-heavy week — burns the meter faster than the quiet production traffic ever would. If your deployment cadence is spiky, a fixed-credit plan is a bet against your own workflow. When that bet starts making you ration deploys, you've found your reason to leave.

Per-member pricing at team scale

Pro is billed per member. A five-person team on Pro is five seats at roughly $19–20 each per month, before any usage beyond the credit pool — call it $95–100 a month for the team at time of writing. For a serious product that's fine. For an agency that wants every client to poke at deploy previews, per-seat pricing punishes collaboration. Do the arithmetic on your actual seat count and compare it against platforms that price per project or per resource instead. The gap widens with every person you add.

When the platform stops being a good fit

Netlify is a static-and-functions platform, and it's superb within that shape. But a growing number of sites want a persistent server: WordPress, a Rails or Django app, a game server, background workers, cron that runs longer than a function timeout allows. Some of those can be bent onto Netlify with adapters and third-party databases; at some point you're fighting the platform. There's also the lock-in question — Netlify Forms, Identity, and split testing are lovely until you want them somewhere else, at which point they're migration projects. If your architecture has quietly accumulated Netlify-specific features, price the extraction before the platform does something you dislike.

Support at the tier you can afford

Platform support is gated by plan in the usual way: community and docs on the free tier, better response times as the price rises. For hobby projects that's fine — the docs are genuinely good. For anything with revenue attached, "ask the community" is not a support plan. If you've had a production incident where the answer was a forum thread, you already know which of these paragraphs you're in.

When you should stay

Stay if your workload is what Netlify is for: static sites, documentation, marketing sites, JAMstack front ends with API backends elsewhere. The free tier remains generous for genuinely small sites — the 300 credits go a long way when you deploy a few times a week, and deploy previews are still one of the best collaboration features in the industry. A client reviewing a pull request on a real URL is a workflow you don't give up lightly.

Stay if your usage is steady and predictable. Credit pricing punishes spiky usage; if you know you deploy roughly N times a week and N fits comfortably in your pool, the model works in your favour and the per-seat cost is predictable. Diary the meter, set a usage alert, and move on with your life.

Stay also if you're using the platform-specific features heavily and they're earning their keep. Netlify Forms with spam filtering, Identity for simple auth, edge functions for personalisation — if those replace three vendor subscriptions, the consolidation is worth real money. Lock-in is only a problem when the relationship sours; if the platform is doing the work, staying is rational. Just know where the exit is before you need it.

The alternatives

These split into two camps: PaaS platforms that keep the git-push workflow (Render, Railway, Koyeb) and cloud servers where you run things yourself (Cloudways, Akamai, Kamatera). Prices at time of writing.

Render — the closest thing to Netlify with a server

Render keeps the git-connected deploy model but gives you real web services, background workers, cron jobs and managed Postgres. There's a genuine free tier — free web services and datastores for previews and small projects — with a Hobby tier at $0 plus compute and a Pro tier around $25 per member per month plus compute at time of writing. For a JAMstack site that grew an API, or a Node/Python/Rails app that wants the Netlify workflow without the credit meter, this is my first stop. The mental model shift: you pay for compute you run, not for deploys you make.

Railway — for usage-priced app hosting

Railway bills by the second for what your app actually uses, with small plan fees on top — the pricing page's whole pitch is "pay only for what your app uses, by the second". You attach databases, workers and services into one project and scale each independently. For developers whose usage is spiky but whose apps are idle much of the day, per-second billing beats a fixed credit pool. The risk is the inverse of Netlify's: a runaway process bills you in real time. Set budget alerts on day one — Railway makes that easy, and I've been grateful for it.

The other thing I like about Railway is how it handles the middle stage of a project's life: that awkward phase where the site needs a database, a background worker and a cron job but doesn't yet need an ops team. One project, a handful of services, one bill. On Netlify that same shape means three vendors and a glue layer; on Railway it's a diagram you can draw on a napkin.

Koyeb — for serverless-shaped containers with a free tier

Koyeb runs containers on a serverless model: instances that scale to zero, per-second compute billing, and a free tier that includes one small instance (0.1 vCPU, 512MB, scaling to zero after an idle hour) in Frankfurt or Washington at time of writing. Paid compute starts from a couple of dollars a month for their eco instances. It's the most Netlify-like of the PaaS options in feel — you push code and it runs — while being unapologetically container-based. Good for APIs and small services; less mature ecosystem than Render.

Cloudways — for PHP and WordPress workloads that need to stay up

Cloudways is a managed layer over real cloud servers — Vultr, DigitalOcean, Linode, AWS, Google — with a control panel, staging, and support that handles the server for you. Managed plans start around $10–14 a month for a 1GB Vultr instance at time of writing, with a 2GB tier around $20. This is the answer when "static site" has quietly become "WordPress multisite with WooCommerce and three cron jobs" — which happens to half the JAMstack projects I've watched. You get an always-on server instead of functions, and the migration from Netlify is really a rebuild on a different architecture.

Akamai Nanode 1GB — for developers who want the raw box

The Nanode 1GB is the classic small cloud server: 1 vCPU, 1GB RAM, 25GB SSD, about a terabyte of transfer, $5 a month at time of writing — flat, unbilled-per-deploy, unbothered by how often you push. It's Akamai's (formerly Linode's) entry instance, available in dozens of locations. You run the web server, the TLS certificates, the backups, everything. For a developer comfortable with a terminal, $5 a month and a weekend of setup buys what Netlify Pro costs $20 per member to approximate. For anyone not comfortable with a terminal, it's a trap — factor your own time honestly.

I keep a Nanode running for exactly one client's staging environment, and the total cost of ownership is a Saturday a month of patching and backups. That's the deal: you pay in attention what you don't pay in dollars. On a Nanode you're also one apt-get away from your own security incident, so automate the updates and keep the backups off-box. The $5 price is real; the free work that accompanies it is the part people forget to budget.

Kamatera — for configurable cloud at hourly prices

Kamatera sells configurable cloud servers with hourly or monthly billing — their cheapest configurations advertise from about $4 a month or half a cent an hour at time of writing, and you choose CPU type, RAM and storage à la carte across a wide location list. It's the option for people who know exactly what spec they want and dislike paying platform margins for it. No hand-holding, no git integration, no preview URLs — just infrastructure at commodity prices. I've used it for batch-processing boxes and staging servers where the bill needed to be boring.

How to switch without downtime

Static sites move easily; it's the platform features that bite. Work in this order.

First, inventory what Netlify actually does for you. The site files are trivial — it's a build from a git repo, and that repo is yours. The lock-in list is everything else: form submissions (export them), Identity users (they don't migrate), split tests, edge functions, redirects and headers in netlify.toml (rewrite them for the new target), environment variables (copy them before you lose access), and any functions using Netlify-specific APIs.

Second, build the new setup while the old one serves traffic. On a PaaS like Render or Railway, connect the same repo and configure the build command; on a VPS, stand up the web server and deploy the built output. Test on the platform's preview URL or a staging domain. Check the behaviours people forget: 404 pages, trailing-slash redirects, canonical URLs, forms posting to the right endpoint.

Third, DNS is the swap. Netlify manages your DNS if you delegated nameservers there, which means migration includes re-delegating DNS — the slowest possible switch. Lower TTLs first, move DNS to your registrar or the new provider, then point the records. If you only use a CNAME or ALIAS record at a third-party registrar, you're lucky: flip the one record and you're done. Budget 24–48 hours for stragglers either way.

Fourth, run both platforms in parallel for a week. Keep the Netlify site up until every resolver, CDN cache and bookmark has moved over. Watch the new host's logs for 404s that tell you what forgot to migrate. Only then cancel Netlify — and export anything remaining first, because account closure takes your dashboard history with it.

One habit worth building regardless of where you land: keep your infrastructure describable in a file. Build command, environment variables, redirects, DNS records — write them down as you deploy. I've done enough of these migrations to know that the worst enemy isn't Netlify's export options; it's a project whose configuration only ever existed as settings clicked together in a dashboard nobody screenshotted.

How we evaluate hosting providers

We judge hosting by the bill you get in month thirteen, not month one. For usage-based platforms that means modelling your real usage — deploys, seats, compute hours — against the pricing structure, because the headline number is meaningless on a metered product. Then we weigh what the platform actually does versus what you're assembling from add-ons, the honesty and readability of the pricing page, support quality from real interactions, and how hard the exit is. We don't publish benchmarks we can't reproduce or prices we can't source; where a figure shifts or I couldn't pin it exactly, I say "at time of writing" and point you at the page that will settle it. Renewal and metered reality first, marketing last.