We Moved evolred.com Off Vercel. Here's the Honest Maths.

A note on framing before we start. There is a particular flavour of self-hosting blog post that has been doing the rounds recently — the one where someone moves off a managed platform, claims it saved them 90%, posts a screenshot of a trivial monthly bill, and concludes that managed hosting is a scam. We do not really agree with that genre. Vercel did not rip us off. We just stopped needing what we were paying for. There is a difference, and the difference is where this post lives.

For the last year evolred.com — the marketing site, blog, lead-capture, and a handful of small APIs — sat on Vercel. We were happy. Things deployed when we pushed. Preview URLs worked. The CDN was fast. None of that was the problem.

The problem was that the site stopped looking like a serverless workload. The traffic shape changed, the data shape changed, and the cost of the thing we used Vercel for stopped lining up with the cost of the thing Vercel was good at.

We moved to a self-hosted VPS managed by Dokploy. The migration took an afternoon. The maths since has been better than we expected, and worse than the rage-quit blog posts would have you believe. Both are interesting.

What changed about the site that made the move make sense

A year ago this site was three pages and a contact form. Today it is the marketing surface, an apps catalogue with structured-data schema, twenty-something MDX articles, four service deep pages, programmatic OG image generation, the contact form, the support form, the newsletter, the support staff-and-customer email pipeline, an in-page nav with active section tracking, and a small set of analytics-mirroring routes for ad-blocked traffic.

Most of those workloads are not edge-friendly. The OG-image renderer wants Node, not the Edge runtime. The Plunk integrations want a long-lived TCP-friendly Node fetch. The newsletter rate limit lives in process memory because we genuinely do not want a Redis dependency for ten signups an hour. None of this is exotic. None of it is expensive. It is just plain Node, which Vercel will of course host, but Vercel's pricing model is sharp on serverless function invocations and that is what we kept paying for.

We also stopped wanting the parts that sold us on Vercel originally. Preview URLs are great when you have a team. We are one engineer for now. Atomic deploys are great when you ship multiple times a day. We ship a couple of times a week. Edge caching is wonderful for spiky read-heavy workloads. Our traffic does not spike — it just steadily climbs.

When the things you are paying a premium for stop being the things you actually need, the maths does not need to be dramatic for the move to be correct.

What Dokploy is, and why we picked it over the alternatives

Dokploy is one of a small wave of tools that look at Vercel/Render/Fly.io and say what if we did this on a VPS we already owned. The closest peer is Coolify; Kamal is in the same family from the Rails world. They all wrap Docker, give you a dashboard, handle SSL via Let's Encrypt, expose webhooks for git deploys, and otherwise stay out of your way.

We picked Dokploy specifically because:

• The dashboard is unfussy. Adding the project, the env vars, and the build command took about ten minutes.
• It speaks Docker Compose natively. We were not anchored to Vercel-specific build conventions, so a Dockerfile plus the next.config.mjs output: 'standalone' setting was all the migration we needed to do.
• It does not try to abstract the underlying server away from us. When we want to look at the Node process or tail the logs, we SSH in. That is a feature, not a regression.

Whether you pick Dokploy or Coolify or Kamal genuinely does not matter. They all converge on the same answer. What matters is whether you want a VPS in your life.

What the move cost us

Honest list, no flattering omissions.

No more preview URLs out of the box. Dokploy supports environment branches, but it is not a one-line add. We have not bothered. For a one-engineer team this is a non-issue. For a four-engineer team it would be the first thing we built.

No edge runtime. Everything runs at the origin in one region. We added Cloudflare in front for caching and TLS termination, which mitigates the latency hit for static assets. The dynamic routes still hit the origin, but the routes are fast and the audience is not globally distributed yet.

Build minutes are now our problem. When the build hangs, nobody is watching it for us. Dokploy gives you logs but not the polished build-failure UI Vercel does. We have not yet been bitten by this; we do expect to be.

Background jobs need a plan. Vercel Cron handled our small scheduled tasks. We replaced them with a Node cron and a small queue. It is fine, but it is another thing to operate. If you have meaningful background work, this is the line item to think hardest about.

What we got back

Some of these are emotional rather than financial. We are listing them anyway because they are real.

Cost predictability. A VPS at a known monthly price is a known monthly price. Function-invocation pricing is fine until your blog has a good week and the bill quietly doubles. We were not getting bill-shocked by Vercel — but the headroom feels different when nothing is metered.

Fewer abstractions to debug. The 500 we hit on the support API a fortnight ago turned out to be a bad env var. On Vercel we would have learnt that from a function log. On Dokploy we logged into the box and tailed the running process. The fix path was shorter.

The whole thing fits on one box. The marketing site, the apps catalogue, the support endpoints, the small queue worker, the cron scheduler — all of them on a modest VPS. There is a particular kind of clarity in being able to draw the architecture on the back of an envelope and have it actually fit.

We can run things that would have been awkward on serverless. Long-running processes, background workers, cron jobs that take more than a few seconds, anything stateful — they are all just processes now. Not exotic. Not premium. Just processes.

Who should not do this

To be clear: Vercel and the platform-tier hosts are still the right answer for a lot of teams. If any of these apply, stay where you are.

You are a team of more than two engineers and you genuinely use preview URLs every day. Replicating that workflow on a VPS is doable but not worth your time.

Your traffic is genuinely global and latency-sensitive. The edge model is not a marketing line — for a mass-market product, it is the difference between a 60ms and a 240ms response in Sydney.

You are not interested in operating servers. We mean this without judgement. Operating a VPS, even a managed one, is a small but real ongoing cost in attention. If you would rather pay money to never think about it, pay the money. The hours you save are real.

Your application is actually serverless-shaped — heavy bursty traffic, cold-start tolerant, lots of independent functions. Self-hosting an inherently serverless workload is the worst of both worlds.

What we would tell someone considering it

If you are running a Next.js app of this rough shape and you have started feeling vaguely uneasy about the bill — not "this is robbery", just "I am paying for things I am not using" — give Dokploy or Coolify a half-day. The migration is small enough that you will know within an afternoon whether the resulting setup is one you can live with.

If you cannot live with it, you have lost half a day. If you can, you have moved a recurring monthly cost down a notch and got a setup you can reason about end to end. We are six weeks in and we have not regretted it once. We also will not be writing a triumphalist post about how we saved 90% on hosting, because we did not. The savings are more boring than that, and the boring kind tend to be the kind that last.

---

Thinking about migrating off a platform host but not sure if your workload fits? Migrations like this are the sort of one-week scoped engagement that lives inside our tech consultancy work — happy to walk through the maths for your specific stack.