Vercel vs Self-Hosted (Kamal/VPS) for Storefronts

For most Next.js storefronts under meaningful traffic, Vercel is the right default — it removes deployment, edge caching, and image-optimization plumbing from your plate entirely. Self-hosting with Kamal on a VPS becomes the better call once your traffic is steady and predictable, your bill on Vercel is growing faster than your revenue, or you need control over runtime behavior (queues, background jobs, long-running processes) that a serverless platform makes awkward. Neither option is universally correct; the decision hinges on traffic shape, team size, and how much operational work you're willing to own. This guide breaks down the real tradeoffs — cost curves, cold starts, ISR/revalidation behavior, image optimization, observability, and rollback — so you can make the call with actual numbers instead of platform marketing.

A quick framing note before the comparison: this is written for teams building or evaluating Next.js and headless-commerce storefronts specifically, not general web apps. Commerce storefronts have a distinct traffic profile — spiky around sales events, latency-sensitive on product and checkout pages, and dependent on a commerce backend (Shopify, Medusa, Commerce Layer, etc.) that itself adds network hops. That shape matters more here than in most "Vercel vs self-hosted" writeups.

The Two Models, Briefly

Vercel is a managed platform built by the maintainers of Next.js. You push to a git branch, it builds and deploys automatically, and your app runs across a global edge network with per-request serverless functions, built-in ISR (Incremental Static Regeneration) support, automatic image optimization, and preview deployments for every pull request. You pay for compute, bandwidth, and a handful of platform features (Edge Config, Vercel Blob, Analytics) on a usage-based model layered on top of a plan tier.

Self-hosted with Kamal means you run Next.js yourself — typically as a Docker container — on a VPS you provision (Hetzner, DigitalOcean, OVH, a bare-metal box, whatever). Kamal (formerly MRSK, from the Rails/37signals team) is a deployment tool that handles zero-downtime rolling deploys, health checks, and basic orchestration over SSH, without requiring a full Kubernetes cluster. You configure your own reverse proxy (Kamal ships with Traefik-style routing built in), your own TLS, your own logging pipeline, and your own scaling strategy — usually starting with one or two boxes behind a load balancer.

Both are legitimate production choices in 2026. The Next.js docs officially support standalone output for containerized self-hosting, and Kamal has matured into a genuinely low-ceremony way to run Docker apps on plain VPS boxes without adopting Kubernetes. This isn't a "one is right, one is a trap" comparison — it's a genuine tradeoff matrix.

Cost: Where the Curves Cross

This is the question most teams actually care about, and the honest answer is: it depends on traffic shape, not just traffic volume.

Vercel's pricing is usage-based on top of a plan — you pay for function invocations, execution duration, bandwidth, and image optimization transformations. For a low-to-moderate traffic storefront, this is often cheaper than provisioning your own infrastructure, because you're not paying for idle capacity. A store doing a few thousand sessions a day can run comfortably on Vercel's Pro tier with predictable, modest monthly cost.

The economics shift as traffic climbs, particularly with bandwidth-heavy commerce catalogs (large product image galleries, video, big JSON payloads from the commerce API) or with high concurrent function invocation counts during sales spikes. Vercel bandwidth and function-duration charges compound with scale in a way that a fixed-price VPS does not. A fixed monthly VPS cost is easier to budget against and doesn't punish you for a successful Black Friday — you paid for the box either way. This is the classic serverless-vs-provisioned tradeoff, and it applies here just as it does anywhere else: serverless wins on low-and-variable load, provisioned wins on steady-and-high load.

The honest caveat: self-hosting cost isn't just the VPS bill. It's the VPS bill plus the engineering time to configure, monitor, patch, and scale it — and that time has a real cost even if it never shows up on an invoice. Teams that underestimate this line item are the ones who "save money" on hosting and lose it on engineering hours debugging a misconfigured reverse proxy at 2am during a launch.

Cold Starts and Latency

Vercel's serverless functions can cold-start, particularly for less-frequently-hit routes or in regions with lower traffic. For a storefront, this matters most on dynamic routes — checkout steps, cart mutations, personalized recommendation blocks — where a few hundred milliseconds of cold-start latency is directly visible to a shopper mid-purchase. Vercel has invested heavily in reducing this (fluid compute, smarter warm-pooling), and for high-traffic routes it's rarely noticeable in practice, but it's a real variable you don't fully control.

A self-hosted Node.js process on a VPS has no cold starts in the serverless sense — the process is already running, listening, and warm. What you trade for that is: you now own capacity planning. If a single box is undersized for a traffic spike, you get slow responses or dropped connections instead of a scaled-out serverless fleet quietly absorbing it. Kamal deployments to multiple boxes behind a load balancer address this, but it's manual scaling work you're signing up to do, not something the platform does for you automatically.

ISR, Revalidation, and Edge Caching

Incremental Static Regeneration is one of Next.js's most useful features for commerce — it lets product and collection pages serve from cache almost all the time while staying fresh after a price change or inventory update. On Vercel, ISR and its on-demand revalidation (path-based and tag-based revalidation) are first-class, fully managed, and integrate with Vercel's global edge cache out of the box. This is genuinely one of Vercel's strongest advantages for storefront workloads specifically, since product data changes constantly and stale pricing is a real business risk.

Self-hosted Next.js supports ISR too — the standalone build handles on-disk regeneration — but you lose the global edge distribution layer. A single VPS region means everyone hits the same origin; you'd need to add your own CDN (Cloudflare in front of the origin is the common pattern) and be deliberate about cache invalidation across that additional layer. It's solvable, and Cloudflare-in-front-of-Kamal is a well-trodden pattern, but it's another piece you're assembling and maintaining rather than getting for free.

Image Optimization

Product photography is the single heaviest asset class on most storefronts, and Next.js's built-in image component is only as good as the optimization pipeline behind it. Vercel's image optimization is managed, scales automatically, and is billed per transformation — convenient, but it's also one of the line items that can surprise teams with large, frequently-changing catalogs.

Self-hosted, you have two real options: run the Next.js built-in image optimizer yourself (fine, but it's CPU work your box now has to absorb) or offload it entirely to a dedicated image CDN (Cloudflare Images, imgix, a headless commerce platform's own asset CDN). Many commerce backends already serve optimized images from their own CDN — in which case neither Vercel's nor a self-hosted image pipeline is doing much work anyway, and this axis matters less than it first appears.

Observability, Rollback, and Operational Maturity

Vercel gives you deployment logs, function-level tracing, and instant rollback to any previous deployment out of the box — no setup required, and every preview deployment doubles as a full staging environment reachable by a URL. This built-in observability is easy to undervalue until you're missing it at 1am during an incident.

Kamal's rollback story is solid at the deployment-mechanics level — it does zero-downtime rolling restarts and you can redeploy a prior image tag quickly — but everything above that layer (structured logging, error tracking, uptime alerting, metrics dashboards) is bring-your-own. That typically means wiring in something like Sentry, Grafana/Prometheus, or a hosted log aggregator yourself. It's absolutely doable and plenty of serious production teams run exactly this stack, but it's real setup and maintenance work that Vercel simply hands you for free.

Team Size and Operational Appetite

This is the variable that gets underweighted in most comparisons. A solo founder or a two-person team building a storefront should, in almost every case, default to Vercel — the time saved not configuring TLS, reverse proxies, log pipelines, and scaling policy is worth far more than the incremental hosting cost, because that time is better spent on the product and the store itself.

A team with existing DevOps capability — people who already run Docker in production, already have monitoring conventions, already know how to reason about a VPS fleet — faces a much smaller marginal cost to self-host, and stands to gain the most from the cost-predictability and control benefits at scale. If your team already runs other services on Kamal or a similar setup, adding a storefront to that fleet is a much smaller lift than standing up the equivalent operational maturity from zero.

A Decision Framework

• Traffic is low-to-moderate and variable (a new store, seasonal spikes, unpredictable growth): favor Vercel — you avoid paying for idle capacity and get global edge caching for free.
• Traffic is high and steady, or predictably spiky at large scale (established DTC brand, known sales-event patterns): model both cost curves explicitly — a fixed-price VPS fleet frequently wins here, particularly on bandwidth-heavy catalogs.
• Team has no dedicated DevOps capacity: default to Vercel regardless of cost math — the operational time saved is usually worth more than the money.
• Team already runs Docker/Kamal infrastructure for other services: self-hosting the storefront is a smaller incremental lift and may be worth it purely for consistency and control.
• You need long-running processes, background workers, or non-HTTP protocols (queue consumers, websockets held open for long durations, scheduled batch jobs tightly coupled to the storefront app): self-hosting avoids fighting serverless execution-time limits.
• You need every ounce of built-in ISR/edge-cache/rollback tooling with zero setup: Vercel's integration with Next.js internals is deeper than anything you'll assemble yourself quickly.

A Third Option: Hybrid

Some teams split the difference: run the storefront on Vercel for the DX and edge benefits, but self-host adjacent services (a headless commerce backend, a search index, background job workers) on a Kamal-managed VPS fleet where the workload genuinely needs long-running processes. This is a common and sensible pattern — it puts each workload on the hosting model best suited to its shape rather than forcing an all-or-nothing platform decision. If you already run a Medusa or similar backend, that piece is often better suited to a VPS than to serverless functions regardless of what you decide for the storefront itself.

Where Polo Themes Fits

Polo Themes has built its Shopify and Figma product lines around getting merchants to a well-designed storefront fast, and we're extending that same approach into Next.js and headless-commerce starters — production-grade templates built to deploy cleanly on either model, with sane defaults for ISR, image handling, and environment configuration baked in from the start rather than bolted on later. That line isn't available to buy yet, but it's a direction we're actively building toward, informed by exactly the tradeoffs covered in this guide. In the meantime, if you're evaluating storefront foundations more broadly, our existing Shopify theme catalog and Figma UI kits are worth a look, and we cover related storefront-architecture topics on the blog as we publish them.

Frequently Asked Questions

Is Vercel too expensive for a small storefront?

Usually not. For low-to-moderate traffic, Vercel's usage-based pricing tends to be cheaper than provisioning and maintaining your own VPS, because you aren't paying for idle capacity or engineering time to manage infrastructure. Cost concerns tend to surface at higher, sustained traffic volumes — model your specific bandwidth and function-invocation numbers before assuming either direction.

Can I self-host Next.js without Kamal?

Yes — Kamal is one deployment tool among several (others include Dokku, Coolify, or a hand-rolled Docker Compose + systemd setup). Kamal's appeal is minimal ceremony compared to Kubernetes while still giving you zero-downtime rolling deploys and health checks over plain SSH, which is why it's become a popular choice for teams self-hosting Rails and Next.js apps alike.

Does self-hosting mean giving up ISR?

No. Next.js's standalone output supports ISR and on-demand revalidation when self-hosted — you just don't get Vercel's global edge cache distribution for free. Most teams that self-host and want that benefit put Cloudflare (or a similar CDN) in front of the origin and handle cache invalidation at that layer themselves.

What's the safest way to decide?

Model your actual numbers — current or projected bandwidth, function invocations, and image transformations — against Vercel's published pricing, and compare that to a realistic fixed VPS cost plus an honest estimate of the engineering hours to configure and maintain it. Weigh that against your team's existing DevOps capability. The framework in this guide is a starting point; the real answer is specific to your traffic and your team.