Vercel Alternatives for Full-Stack Apps, Not Just the Frontend
Every list of Vercel alternatives ranks platforms of different shapes against each other. The question that decides it is what you are actually deploying.
Open three lists of Vercel alternatives and the same names appear in a different order: Netlify, Cloudflare Pages, Render, Railway, Fly.io, and a self-hosted control plane on a rented box. The ranking is the part that does not work. Those are not competing products. They are four different shapes of hosting, and a table that sorts them by feature count is holding a CDN up against a container scheduler and declaring a winner.
Which is why the lists cannot help you, and why the answer changes completely depending on something none of them asks. A site that compiles to files and a Next.js application with a database, a queue and a nightly job are two unrelated hosting problems that happen to share a starting point. Until you have said which one you have, a ranked list is answering a question nobody asked.
Two adjacent questions are out of scope here. If you are leaving a platform and want to know what has to be unpicked before you can move at all, that mechanic is worked through in what you are actually detaching from Railway. If the real question is whether to run the platform layer on a server you administer, the ledger for that is in self-hosted PaaS versus managed. What follows is about the shape of your application and the shape of the thing that should be running it.
Why the swap question is shaped wrong
Vercel deploys the output of your build and a set of serverless functions, and as of writing that is the boundary of what it runs. It is very good inside that boundary. What it does not include, by design rather than by omission, is a process that stays alive between requests, a database, a queue, a scheduler, or a filesystem that survives the next deploy. Those are all real requirements of an ordinary application, and on Vercel each one is satisfied by something you buy separately and connect over the network.
Follow that through and the consequence is structural. An application that started as a frontend and grew a backend is, by the time it needs alternatives, distributed across a hosting platform, a database vendor, possibly a cache, an object store for anything users upload, and a scheduler for the jobs that have to run whether or not a request arrives. Nobody chose that architecture in a meeting. It accumulated, one integration at a time, because the platform underneath supplied the first piece and not the rest.
You are not moving one thing
This is why "what should I use instead of Vercel" resists a one-line answer. The thing you are moving is not a deployment. It is a set of decisions about where each part of your application lives, several of which were made implicitly, and a replacement platform will absorb some of them and leave others exactly where they are. The list of alternatives is the last step of that decision, not the first.
Four things a full-stack app needs that a frontend platform doesn't have
A platform that deploys build output and functions leaves exactly four gaps open: a process that stays alive between requests, state that has to live somewhere, work that runs on a schedule, and files that outlast a deploy. None of them is a defect. They follow from what that kind of platform is for, and every one of them is already a line item you pay for somewhere else, or a workaround you have already built.
A process that stays alive
A serverless function has a ceiling on how long it may run, and as of writing the exact ceiling varies by plan and has changed more than once, so the number matters less than the fact that one exists. Anything that wants to outlive a request runs into it: a WebSocket connection held open for a collaborative editor, a server-sent event stream, an import that takes four minutes on a large file, a worker that drains a queue continuously rather than in bursts. The usual workarounds are to split the work into chunks that each fit under the limit, or to move that one piece onto a second platform that runs containers, which is how a stack ends up with two hosting providers. The related tax on the same seam, an instance that has to be started before it can answer, is covered in why free-tier apps fall asleep.
State that lives somewhere
No database comes with the box, so you attach one, and the attachment has a property that surprises people the first time they meet it. A function is an instance that appears for one invocation, which means a naive database client opens a connection per invocation, and a burst of traffic turns into a burst of connections against a server that has a hard limit on how many it will hold. This is not the database misbehaving. It is a runtime with no long-lived process meeting a protocol that assumes one, and the fix is a pooler in between, which is a component you now operate or pay for. What the pooler is actually doing, and why the two ports matter, is in connection pooling with PgBouncer. A platform that runs a container sidesteps the problem rather than solving it, because the process is already there and holds its own pool, and managed PostgreSQL hosted in the EU is then an endpoint rather than an architecture.
Scheduled and background work
Every application acquires work that is not triggered by a visitor: expiring sessions, sending the digest, reconciling a payment provider, retrying whatever failed overnight. On a frontend platform these live as an add-on, usually a scheduler that calls one of your functions on a timer, which works and inherits the execution ceiling from the section above. On a platform that runs containers they are ordinary services, and a queue consumer is simply a process that is always running. If you have been keeping a job alive by having an external service ping a URL every five minutes, that is the workaround this gap produces, and managed cron jobs that run as a first-class service alongside managed Redis for caches and job queues is what replacing it looks like.
Files that survive a deploy
There is no writable disk, or more precisely there is one that disappears with the instance, so anything a user uploads has to go somewhere addressable from the moment it arrives. Why that is true of nearly every modern deployment target, not only this one, is explained in how git push to deploy actually works. The practical consequence is an object store in the stack from day one, and the thing to check on it is not capacity but transfer, since serving user media is mostly egress. On Runsite that line is object storage with no egress charges; elsewhere it is metered, and metered transfer is the part of a storage bill that grows with your traffic rather than with your data.
The bill is a different shape than the pricing page
Cost is the reason most people start reading about alternatives, and the pricing page is a poor guide to it, because the parts that move are not the parts printed in large type. Three things are metered rather than fixed as of writing: outbound bandwidth, function execution, and the number of people on the team. A plan price plus three meters is not a monthly cost, it is a monthly estimate, and the months where it is wrong are the months where something went right and traffic arrived. Worth checking separately, because it catches people at the worst moment: as of writing the free tier carries a restriction on commercial use, which is set out on Vercel's own pricing page and is the kind of clause that surfaces when a side project starts taking money.
The second half of the arithmetic is the one nobody puts in a comparison table. Because the platform supplies one piece of the application, the other pieces have their own invoices, and each of those is metered on its own terms. The database bills for storage and often for compute time. The object store bills for what it stores and, on most providers, again for every byte a visitor downloads, which is the mechanic taken apart in why downloading your own data costs so much. Add the scheduler, add the observability tool that replaced the logs you used to have. The total cost of a Vercel-shaped stack cannot be read off Vercel's pricing page in principle, which is why the number people quote from memory is usually the smallest of the several they pay.
Four shapes of answer, picked by what you deploy
With the gaps and the meters named, the candidates sort themselves into four shapes, and the question that picks one is what you are deploying rather than which platform ranks highest. The table below is deliberately built on the last column, which is the one that decides whether a migration was worth doing.
| What you are deploying | The shape that fits | What it changes | What it does not |
|---|---|---|---|
| Build output only, no server at request time | A static host with a CDN | Bandwidth model, build pipeline, the amount you operate | Anything that needs to run when a request arrives |
| A server that has to be running | A container platform | Execution ceilings, connections, schedules, background work | That the database and the object store still live somewhere |
| The same stack, and a customer asked whose law applies | A European operating company | The sentence you send to a security review | The amount of migration work, which is the same either way |
| The same stack, and the invoice is the problem | The platform layer on infrastructure you rent | Monthly cost, and how much of the operations you own | That somebody has to be awake when it breaks |
The first row is the honest answer more often than people expect. If what you deploy is the output of a build, a static host with a CDN is a smaller and cheaper thing than a platform with a functions runtime attached, and static site hosting with a global CDN and EU-hosted builds does the job for Astro, Hugo, Vite, SvelteKit and a Next.js static export. The lateral move belongs here too, and it should be named plainly: Netlify and Cloudflare Pages are the same shape of platform as Vercel, so moving between them changes the interface, the metering and the ecosystem, and leaves all four gaps from the previous section exactly where they were.
The second row is what most people who are unhappy with a frontend platform actually want. A container runs your process, holds its own connection pool, runs a worker next to the web server, and has no execution ceiling to design around. A European container platform that runs a long-lived process rather than a function is the same category as Render, Railway and Fly.io, and the comparison between two of those, including what their two billing models each get wrong, is in Render vs Railway.
The third and fourth rows describe the same application arriving from a different direction. If what pushed you was a question about jurisdiction, the group that answers it is platforms whose operating company is established in the EU: Clever Cloud, Scalingo, Upsun and Runsite among them, and what "European" can legitimately mean is set out in choosing a European Heroku alternative. If the constraint is the invoice, the answer is running Coolify, Dokploy, Dokku or Kamal on European hardware from Hetzner, Scaleway, OVHcloud, Exoscale or UpCloud, and what that hands you along with the saving is priced in what self-hosting a PaaS actually costs.
The Next.js question
For a large share of the people reading this, the worry underneath the search is not hosting in general but Next.js hosting in particular. The framework is developed by Vercel, and the reasonable version of the concern is not about licensing, which is permissive, but about the features whose behaviour depends on what is running underneath them. As of writing, the ones that come up are:
- Incremental static regeneration, which needs somewhere to hold and invalidate the regenerated pages.
- Image optimisation, which needs a process to transform images on demand and a cache to keep the results.
- Middleware on the edge runtime, which runs in a restricted environment rather than in a normal Node process.
- Streaming and partial rendering, which need the connection held open while the response is assembled.
None of these is proprietary, and the framework's own self-hosting documentation covers how each is supported outside Vercel, which is the source worth reading rather than any vendor's summary of it. What decides the outcome is the hosting shape from the table above. A static export removes the server entirely, and with it everything on that list that needs one, which simplifies a content site enormously and breaks an application. A container running the framework's own server keeps most of the list, because the implementation ships with the framework; the edge runtime is the exception, having been designed around infrastructure a container does not have. Which of the two your project wants is a decision in its own right and a subject for another article.
What ties you is the implementation, not the framework
Framework lock-in is the wrong thing to worry about here; the code travels. What travels less well is the set of features whose implementation was supplied by the platform, since those are the ones that quietly stop working, or start costing money you were not paying, on a host that supplies them differently. Check that list against your own application before you compare anything, and you will know which rows of the table are even open to you.
Where the operator is registered
One question survives every comparison in this article, and the lists almost never contain it. Vercel Inc. is a US company as of writing, which is stated in its own terms, and so are Netlify, Cloudflare, Render, Railway and Fly.io. Choosing a region does not change that. A region determines where the bytes are written, which is worth requiring and helps with latency, and it says nothing about which government can compel the company operating the service. Moving between US platforms is a change of billing model and interface with the jurisdiction question left exactly where it was.
If nobody has asked you whose law applies to your customers' data, this row of the table is not binding and you can skip it. If somebody has, or if you sell to anyone with a procurement process, the property that answers it is where the operating company is established, not where the region is. The three different things the word "European" gets used to mean, and which of them survives a security questionnaire, are set out in choosing a European Heroku alternative. Settling it while you are still choosing costs you an afternoon of reading; settling it afterwards costs you the migration twice.
How Runsite handles it
Starting with what does not exist. There is no import tool: Runsite does not read a Vercel project, does not convert a configuration file, and does not ship a Next.js adapter of its own. There is one region, Frankfurt, Germany, so if you need to serve Sydney from Sydney this is the wrong answer. Static assets are cached at edge locations, and that is a cache rather than an execution environment, which means code running at the edge is not something Runsite offers and middleware written for that runtime is not a thing to plan around here.
What it does have is the two shapes from the top of the table under one account. Static site hosting with EU-hosted builds covers a build that produces files, with unlimited sites and 100 GB of bandwidth a month on the free tier, automatic SSL on your own domain, and a preview URL per pull request. Web services on EU infrastructure cover the case where a process has to be running, from a free tier of one service at 0.1 vCPU and 256 MB up to 8 vCPU and 16 GB, with your Dockerfile used when you supply one and the stack detected for Next.js, Django, Rails, FastAPI and others when you do not. Deploys are rolling behind a health check with automatic rollback, a choice explained in blue-green versus rolling deployments, and active applications on the free tier do not cold-start; a service sleeps only after 14 days idle.
On the bill, the shape is the opposite of a meter, and the trade goes both ways. Plans are fixed monthly prices as of writing, from €5 to €180, so an application that idles for twenty hours a day may genuinely cost less on a consumption meter than it does here; the thing a fixed plan buys is knowing the number in advance. The pieces from the four gaps sit alongside it rather than at other vendors: managed PostgreSQL hosted in the EU and managed Redis from €5/mo, managed cron jobs, and object storage with no egress charges at €0.025 per GB per month after 5 GB free. All of it runs in the one region, there is no replication to non-EU regions, and a signed GDPR data processing agreement comes with every plan including the free one. Setup details are in the Runsite docs.
The short version
Vercel is a platform for build output and functions, and it is good at that. The reason a list of alternatives never resolves is that the names on it are four different shapes of hosting, and which shape you need is decided by four things your application either has or does not: a process that must stay alive, state that has to live somewhere, work that runs on a schedule, and files that outlast a deploy. Count how many of those you have before you compare anything. If the answer is none, you want a static host and you have been overpaying for a functions runtime you do not use. If the answer is most of them, you want a container.
Then check the two things that no feature matrix contains: which Next.js features you depend on and where their implementation comes from, and which legal entity is named in the terms you are agreeing to. Those decide whether a migration solves your problem or relocates it. If it turns out you want the second row of the table, a European platform that runs your container from your own Dockerfile has a free tier, and one service deployed onto it will tell you more in an afternoon than another ranked list will.