Dockerfiles on Vercel vs VPS: What to Use in 2026

A client rang me in early January, absolutely buzzing. "Gautam, I just read that Vercel does Docker now. We can shut down our DigitalOcean droplets, yeah?" He was running three droplets, two of them at $24/month each, one at $48. He had a spreadsheet ready. He wanted to save money and he wanted to save it immediately.

I told him to hold off for two weeks while I actually tested it. Good thing he listened.

Here's the thing: Vercel's container support is genuinely impressive. And a VPS is still not dead. Both of those sentences are true at the same time, and the nuance between them is worth understanding before you start docker push-ing everything to Vercel's infrastructure and wondering why your WebSocket connections keep dropping.

What Vercel Actually Announced

Vercel's Docker support, rolled out through their Build Output API and later formalised for general use, lets you ship a Dockerfile and have Vercel handle the container runtime. No more being confined to Next.js conventions or serverless function file structures. You write your Dockerfile, Vercel builds it, runs it.

That is a genuine shift. Before this, if you had a FastAPI backend or a custom Node server doing something exotic, you were either contorting it into a serverless function shape or keeping a VPS running alongside your Vercel frontend. The latter is what most of us did. It was annoying but it worked.

What the Runtime Actually Looks Like

Vercel's container runtime isn't bare-metal Docker. It's closer to what you'd get on a managed container service. Your container gets a request, Vercel routes it, the container handles it. Persistent processes work. You can run something like a Python WSGI server or a Go HTTP binary. Long-running tasks within a single request lifecycle are fine.

But the constraints matter. Containers can scale to zero. Cold starts exist. And crucially: you do not get persistent disk storage. If your app writes to the local filesystem and expects those files to be there on the next request, you're going to have a bad time.

Where Vercel Containers Actually Shine

I've been running a Django REST API on Vercel containers since March. It's a relatively simple read-heavy service for a media client, mostly GET requests, hitting a Neon Postgres database. No file writes. No background jobs. No WebSockets.

It's been excellent. Deploy previews work. The GitHub integration means every PR gets its own environment. The cold start latency on this particular container sits around 800ms to 1.2 seconds on first hit after idle, which sounds bad but is acceptable when the client's traffic is bursty and predictable.

The cost for that service? Around $20/month with Vercel's Pro plan factored in. The equivalent on a DigitalOcean App Platform would be similar. A raw droplet would be cheaper, but we'd be managing it ourselves.

The Scenario Where This Is a Clear Win

Think about the typical agency project. A marketing site with a headless CMS, a lightweight API for a contact form or some custom logic, and a need for fast deploys. Previously you'd have Vercel for the frontend and a $6 droplet for the little API. Now you can put everything on Vercel, use one dashboard, have deploy previews for the API too. Fewer things to maintain. Fewer things to forget to update.

For freelancers handling five to fifteen client sites, that operational simplicity is worth real money even if the compute cost is slightly higher.

Where a VPS Still Wins. Clearly.

Right. Here's where I need to be direct, because the enthusiasm around Vercel containers has led some developers to make expensive mistakes.

Persistent filesystem operations. If your app generates PDFs and stores them locally before pushing to S3, fine, that specific operation works. But if you're running something like a self-hosted Meilisearch instance that writes its index to disk, you need persistent storage. Vercel doesn't give you a mounted volume. You'd need to add something like a managed Meilisearch service or run it on a VPS. Full stop.

WebSockets and long-lived connections. Vercel's serverless and container environments have request timeouts. I ran into this with a Seahawk project in late 2024, before the Docker support even landed. We were building a real-time collaborative tool for a small SaaS client. Tried everything to make it work on serverless infrastructure. Eventually moved the WebSocket server to a $12/month Hetzner VPS. Problem gone. The VPS has been running uninterrupted since.

Background workers and cron at scale. Yes, Vercel has cron jobs. They're fine for simple scheduled tasks. But if you're running something like Celery workers that process a queue of jobs continuously, you want a process that just... runs. A VPS does that trivially. On Vercel containers, you're working against the grain.

Cost at volume. This is the one that surprises people. At low to medium traffic, Vercel containers are competitive. But at genuinely high request volumes, the per-request pricing starts to compound. A $48/month Hetzner dedicated server handles traffic that would cost several hundred dollars on Vercel at peak. My client who wanted to shut down his droplets? One of them was running a high-traffic internal dashboard. I ran the numbers. Keeping the droplet was £18/month cheaper even after accounting for occasional maintenance time.

The Specific Workloads I'd Never Move to Vercel

Let me be concrete. These are the things I actively route to a VPS regardless of what Vercel releases:

Self-hosted databases. Even a small Postgres replica for read performance. Vercel is not a database host. Use it with Neon, Supabase, or PlanetScale, but don't try to run Postgres itself there.
Media processing. FFmpeg jobs, image resizing queues, anything CPU-intensive with unpredictable runtimes. A $20 Hetzner VPS with 2 vCPUs handles this better and cheaper.
Internal tooling that runs 24/7. Monitoring agents, log aggregators, custom proxy servers. These should just be running. Always. Scaling to zero is the enemy here.
Anything that touches a GPU. Self-evident, but worth saying.

And conversely, here's what I'd confidently put on Vercel containers today:

Lightweight REST APIs (FastAPI, Express, Gin) with no persistent state
Containerised Next.js or Remix apps with custom server configuration
Internal APIs that get hit during business hours only (scale-to-zero is actually great here)
Any service where you genuinely want per-PR deploy previews

The Hidden Cost Nobody Talks About: Operational Complexity

I've built over 12,000 sites across the years at Seahawk. The number one thing that bites agencies and freelancers isn't compute cost. It's ops overhead.

A VPS sounds cheap at $6/month. And it is cheap. But then you're patching it, monitoring it, configuring Nginx, setting up fail2ban, occasionally SSHing in at 11pm because something's behaving oddly. That's not free. That's time, and time is expensive.

Vercel removes all of that. So does Railway, Render, and Fly.io. The real competition here isn't "Vercel vs a VPS in a vacuum." It's "managed platform tax vs ops time tax." For solo operators and small agencies, the managed platform tax is usually the better deal.

Back in 2019 a client handed me a brief that included managing their Ubuntu server. I quoted accordingly. Six months later I was still getting paged about disk space alerts on a server I technically "managed" but had completely deprioritised. I've been much more deliberate since then about what infrastructure I take ownership of versus what I pay a platform to own.

The Framework I Actually Use to Decide

Not a magic flowchart. Just a set of questions I ask on every new project:

Does this service write to disk and expect those writes to persist? If yes, it needs a VPS or managed storage.
Does this service hold long-lived connections (WebSockets, SSE, gRPC streams)? If yes, VPS or a platform that explicitly supports it like Fly.io.
Is this service CPU-bound for extended periods? Vercel containers have a CPU ceiling. VPS wins.
Does the team need deploy previews and GitOps without thinking? Vercel wins.
Will traffic be consistent and high-volume? Run the numbers. VPS is usually cheaper above a certain threshold.
Is this a one-person show or a small agency that doesn't want to think about servers? Vercel is worth the premium.

If questions 1, 2, or 3 are yes, I'm reaching for Hetzner or DigitalOcean. Everything else is a conversation.

What 2026 Actually Looks Like for Infrastructure

Platforms are getting better at persistent storage. Fly.io has Fly Volumes. Render has persistent disks. Vercel will likely add something similar eventually, given how often it gets requested. The gap between "managed platform" and "VPS with full control" is narrowing.

But narrowing isn't the same as closed. And the economics of raw compute haven't fundamentally changed. A Hetzner CAX11 ARM instance at €3.79/month is still absurdly good value for the right workload. Nobody is beating that on a managed platform for equivalent compute.

The honest 2026 state of the world is this: the VPS is not dead. The VPS is increasingly optional. Those are different things.

Most new projects I start at Seahawk now default to Vercel or Railway unless something on that question list above triggers a different answer. We've probably reduced the number of active VPS instances we manage by about 40% over the past eighteen months. But the ones that remain are there for good reasons, and they're not going anywhere.

FAQ

Can Vercel containers replace Docker Compose for local-to-production parity?

Sort of, but not really. Docker Compose is about orchestrating multiple services together locally. Vercel runs a single container per deployment. If your stack has a web server, a worker, and Redis all defined in a Compose file, Vercel can handle the web server part. You'd still need to point at managed Redis (Upstash is the common choice) and handle the worker separately. Local parity is better than it was, but Compose-to-Vercel isn't a direct translation.

What happens to Vercel containers when they scale to zero?

The container process stops. When a new request comes in, Vercel boots it back up. That boot time is your cold start latency. For compiled binaries (Go, Rust) this is often under 500ms. For larger runtimes like JVM-based apps, it can be 2 to 4 seconds. This is worth testing in staging before you commit, because some clients will absolutely notice a 3-second first load.

Is Vercel's container support available on the free Hobby plan?

As of early 2026, no. Container deployments require at least the Pro plan. The Hobby tier still supports serverless functions and static sites. Worth checking Vercel's pricing page directly since this has changed before and will likely change again.

When should I use Fly.io instead of either Vercel or a raw VPS?

Fly is my go-to when I need persistent processes, global distribution close to users, and don't want to manage server configuration. It sits in an interesting middle ground. You deploy containers, but you get more control over regions, machine sizes, and persistent volumes than Vercel offers. I use it for long-running APIs and anything with WebSocket requirements that needs to be in multiple regions. The tradeoff is that the DX is slightly more involved than Vercel's GitHub integration.

---

The VPS is not something you should default to out of habit. But it's not something you should abandon out of excitement either. Know your workload. Run the numbers. And maybe wait two weeks before shutting anything down.

Dockerfiles on Vercel: Do You Still Need a VPS in 2026?