Vercel is the most convenient way to run a Next.js application, and the most expensive in a currency that shows up on no invoice: sovereignty. Deploy there and you hand your application and your users' data into the reach of US law. That's not a scandal, it's a design decision, and too few decision-makers make it on purpose.
The reflex to treat Next.js and Vercel as one inseparable package is marketing, not fact. Next.js is an open-source framework under the MIT licence. Vercel is the company behind it, running a managed platform with an excellent developer experience. The two are related, but they are not the same thing. You can run Next.js on your own infrastructure in Germany, with almost every feature and very similar performance. The question is not whether that works technically; it works, officially and documented. The real question is whether you want to carry the operational responsibility that Vercel's convenience takes off your hands.
Why jurisdiction, not certification, is what counts when you run Next.js on Hetzner instead of Vercel
Vercel runs primarily on AWS across roughly twenty regions, and the default location for Vercel Functions is the United States. The company is certified under the EU-US Data Privacy Framework, uses Standard Contractual Clauses including the UK Addendum, and holds SOC 2 Type 2 and ISO 27001. All of that is real and not worthless. It just doesn't solve the problem it claims to solve.
Because the problem is not encryption in transit or the audit level of the data centre. The problem is the reach of the law. Vercel is a US company and therefore remains subject to US law, including the CLOUD Act. That act lets US authorities compel American providers to hand over data, regardless of where that data physically sits. A DPF certification and SCCs address the transfer of data, not jurisdiction over the provider. That's a categorical difference, and glossy legal brochures like to blur it.
The certifications are documented and verifiable; the jurisdiction question follows from the general legal position, which we cover in more detail elsewhere. For a marketing landing page with no personal data, all of this is irrelevant. For a system that processes customer data, health data or trade secrets, it's the decisive point, especially in light of NIS2 and rising demands for data localisation. Argue here with "but we're DPF certified" and you've either missed the question or you're hoping your data protection officer won't ask it.
What Next.js can actually do self-hosted
The biggest misconception around this topic is that self-hosting costs you half the feature list. It doesn't, and the official documentation is unambiguous. A Node.js server and Docker support every Next.js feature; only pure static export is constrained. The recommended build path is output: 'standalone', a lean, self-contained artefact that drops into a container without the full node_modules ballast.
The two features people worry about most are, in practice, unremarkable. Image optimisation via next/image runs self-hosted with zero config under next start, because Next.js uses sharp internally; only edge cases like glibc memory tuning need manual work. Middleware too, or the proxy convention it's renamed to from version 16 onwards, runs self-hosted without configuration. What you lose is not the function but its globally distributed execution on an edge network. That's a performance detail, not a loss of capability, and for the vast majority of DACH applications with a European user base it's a detail that disappears into the noise.
The genuinely hard part is something else, and I name it deliberately, because honest architecture is where the difference is made. Incremental Static Regeneration works automatically only as long as you run one next start instance with a persistent disk. The moment you scale horizontally across several instances behind a load balancer, you need a custom cacheHandler, typically on Redis or S3, plus coordinated cache tags, a shared encryption key for Server Actions and a stable deploymentId. That's precisely Vercel's core value proposition, and it isn't trivial to rebuild. For a single instance with decent vertical scaling, and a Hetzner AX41 is surprisingly large, the question never even arises.
Hetzner, Coolify and Docker: the concrete stack
Here's how we build it. A Hetzner dedicated server, say an AX41 for around 39 to 49 euros a month, in a German data centre, GDPR-compliant and with no third-country transfer. On top of that Coolify, an Apache-2.0 licensed open-source platform that handles what makes Vercel so pleasant day to day: git-push deploys, PR preview URLs, automatic SSL via Let's Encrypt and zero-downtime deploys. Next.js is built as a standard Docker image, output: 'standalone', and runs as a container.
One clarification belongs here: Coolify is not a Next.js adapter. It simply builds and runs the standard Docker build, and therefore inherits the Next.js docs' assurance that Docker supports every feature. The cache handler and the infrastructure behind it remain your responsibility, which, for a single instance, as noted, is no responsibility at all. The cost ratio to Vercel gets quoted in comparison blogs as ten to twenty percent; treat that as a rough, heavily setup-dependent rule of thumb, not a benchmark. The direction is reliable, the decimal place is not.
The honest full reckoning looks like this. We budget the clean initial build of a self-hosted stack as a one-off of 5,000 to 20,000 euros, depending on complexity. Running operations sit at 2 to 5 hours a month for updates, monitoring and backups. You can start from 20 to 50 euros a month; if you need high availability with redundant instances and a separate database, you land at a few hundred euros. Against that stands Vercel Pro at 20 US dollars per user per month, plus overages for build minutes and transfer; SAML SSO is a paid add-on, and Enterprise has no public list price (as of mid-2026, verify; Vercel's pricing is highly volatile). The decisive dynamic underneath: self-hosted costs fall over time, because the setup is in place. Managed costs rise with the project's success, because you pay per success. Miss that and you make hosting decisions on the demo price instead of the three-year curve.
Can Vercel's developer experience be rebuilt?
Partly, and I won't defend the answer too optimistically. Coolify covers the most important DX building blocks: you push to a branch, a build starts, a preview URL appears. For the daily work of a mid-sized team, that's close enough to Vercel that the switch stops hurting after two weeks. Auto-SSL and zero-downtime deploys are solved problems, not tinkering.
What you don't get one-to-one is the depth of the Vercel ecosystem: the global edge network, the granular analytics, the Speed Insights built into the workflow, the tight interplay of Edge Functions and ISR across regions. Those things are genuinely better on Vercel, and it would be dishonest to dispute it. The point is not that Vercel is bad; Vercel is excellent. The point is that this convenience demands a return that isn't paid in dollars but in control over your data and in a vendor lock-in that builds up quietly. We see the same pattern with databases: Supabase versus Firebase is at heart the same European sovereignty question, just one layer deeper in the stack. Think frontend and data through consistently and you answer both questions the same way.
The uncomfortable point: self-hosting is operational responsibility
Now the part consultants like to skip, because it complicates the thesis. Self-hosting shifts responsibility, it doesn't eliminate it. Vercel patches for you, scales for you, keeps the edge warm for you. Take that on yourself and you take it on for real: apply Coolify updates, harden the operating system, test backups, not just set them up but practise restoring them, and in a scaling scenario stand up the cache handler correctly.
And some things genuinely are hard. Vercel's Edge Functions run at dozens of locations simultaneously; you don't rebuild that on a German server, and for global user bases with latency demands that's a real disadvantage. The multi-instance ISR case described above is engineering work that can go wrong if you underestimate tag coordination and shared keys. Run an application with a global audience and hard latency targets, with no ops capacity in-house, and Vercel legitimately buys the effort back. That's not capitulation, it's a clean make-or-buy decision. Run-the-business tasks that nobody at your end can or wants to carry belong outsourced, as long as you know what you're outsourcing.
The mistake isn't choosing Vercel. The mistake is choosing Vercel without ever asking the sovereignty question, then being surprised when the data protection officer or a NIS2 audit asks it for you. A deliberate make-or-buy decision made with eyes open is always defensible. A default decision you never actually made never is.
What I tell decision-makers
Separate the two questions Vercel deliberately fuses: do you want Next.js? And do you want Vercel as your operator? The first answer is often yes; Next.js is an excellent framework, and we've laid out in full why it holds up as a technological foundation. The second answer hangs solely on your data-protection mandate and your ops capacity, not on the framework.
If you process sensitive data, fall under NIS2, or have a data protection officer who takes the job seriously, then self-hosted on Hetzner with Coolify and Docker isn't an exotic option but the obvious answer. The stack is proven, the costs are predictable and falling, and the performance is practically indistinguishable from Vercel for European user bases. What you give up, edge convenience and a bit of DX polish, is nameable and plannable.
If you have no ops team, no sensitive data model, and a global audience with hard latency targets, then Vercel is the honestly better choice, and I wouldn't talk you out of it. Just make that decision actively. A technology decision is always a decision about power and dependency. Leave it to the default and you buy your provider's interests along with the product, and you only notice when the exit gets expensive.
