← Blog
Engineering

The Vercel alternative built for AI coding agents

Yura OakMikhail Erin
Yura Oak and Mikhail ErinAugust 1, 2026

Vercel runs containers now. It still does not run processes. Since Ship 2026 you can push a Dockerfile to Vercel and split a repo into several backends with Vercel Services, but each one is a Vercel Function underneath: 300 seconds by default, a read-only filesystem, nothing kept between requests. Lizard runs what your Claude Code, Codex, or Cursor session actually wrote — a long-lived process in a Firecracker micro-VM — with first-party Postgres, Redis, and S3, and --json on every command.

Updated 7 August 2026. Rewritten after Vercel Ship 2026 on 30 June and the Vercel Services beta on 1 July. Build pricing corrected to per-CPU-minute, Fast Origin Transfer added to the cost model, and the spend-limit and Hobby claims fixed.


What Vercel shipped in 2026, and what it changes

Vercel closed most of the gap on packaging in mid-2026 and none of it on runtime. Here is the honest ledger.

ShippedDateWhat it changesWhat it does not
Dockerfile on Vercel Functions30 June 2026Any OCI image with an HTTP server runs on Vercel: Go, Rails, FastAPI, nginx, FFmpeg, ChromiumThe image runs under function limits — 300s default, 800s max on Pro, 4 GB and 2 vCPU ceiling
Vercel Container Registry30 June 2026docker push vcr.vercel.com/..., OIDC login through the Vercel CLINothing about how the image runs
Vercel Services (beta)1 July 2026Frontend and several backends in one project, one preview URL, private bindings between themEach service is still a function, with the same limits, and every internal call bills as a Service Request
WebSockets (beta)22 June 2026Native bidirectional connections, no third-party relayA connection is one invocation, pinned to one instance, and dies at maxDuration
Queues, Workflows, Cron2026Background work has a managed homeThe work runs as invocations, not as a process you own

So the old complaint — "Vercel can't run my Dockerfile" — is dead. The real one is narrower and still true: a container on Vercel is a request handler in a box, not a process. Vercel's own docs put it plainly: each container "takes a request, returns a response, and keeps nothing in between", the filesystem is read-only apart from a 500 MB /tmp, and an instance with no traffic scales to zero after 5 minutes.

Write a queue consumer that polls all day, a scheduler holding state in memory, or a WebSocket server meant to hold a connection for an hour, and none of them fit.


Why developers look for Vercel alternatives

Vercel does its job well. It just draws the box in a different place than an agent needs.

  • Containers, not processes. A Dockerfile deploys, then inherits Vercel Function limits: 300 seconds by default, 800 on Pro, 1800 in beta, a 4 GB and 2 vCPU ceiling, a read-only filesystem with a 500 MB /tmp, and a SIGTERM after 5 idle minutes. That is a good request handler. It is not a home for a daemon, a queue consumer, or a job that runs all day.

  • Databases come from the marketplace. Postgres, Redis, Mongo, and vector stores on Vercel are third-party products from Neon, Upstash, and Supabase. One command installs them, but you end up with a second vendor, a second account, a second bill, and a network hop you don't control.

  • No shell, no disk. You can't open a shell in a running container on Vercel, and there is no persistent disk. When a deploy behaves differently from local, your agent is guessing from logs.

  • Spend limits alert, they don't stop. Vercel Spend Management mails you at 50%, 75%, and 100% of the amount you set. Pausing production is a separate switch you have to turn on, and Vercel checks spend "every few minutes", so a runaway job keeps billing past the line either way. What's missing is the other half: CPU, memory, network, and a dollar figure per service that your agent can read while the thing is running.

  • Next.js pulls hard. The framework is open source and self-hosts fine, ISR and middleware included. But the Edge runtime, the image pipeline, and the deployment primitives are Vercel's, and the more you use them, the more a move costs later.


Why Lizard

  • Two commands, not a config directory. lizard up detects your stack, builds it, and boots it in a Firecracker micro-VM. lizard add postgres redis s3 provisions all three and sets the environment variables on the service. No YAML, no dashboard.

  • Structured output everywhere. Every command takes --json. Deploys, logs, events, metrics, secrets: your agent parses the result instead of scraping a terminal. The agent guide ships inside the CLI too, so lizard skills get core returns instructions matched to the installed version.

  • What you deploy is a real process. App or worker, HTTP port or none, alive for ten seconds or ten days. No max duration, no scale-to-zero SIGTERM, no read-only root. Each service gets its own Firecracker micro-VM, a *.onlizard.com domain, and TLS on the first deploy.

  • You can get inside a running app. lizard ssh runs a command in the live VM, lizard run runs a local command with project and service secrets injected, and lizard logs streams build and runtime output. lizard metrics shows CPU, memory, network, disk, and cost per service while it runs.

  • Sandboxes for generated code. Throwaway micro-VMs you create on demand, run untrusted code in, and pause. Pausing snapshots memory, filesystem, and running processes, so resuming picks up where you left off instead of reinstalling packages. When the app works, promote it to a service with lizard up.

  • Any stack, no setup. lizardpack detects Go, Node, Python, Rust, Ruby, PHP, Java, and static sites, then writes a real multi-stage Dockerfile on the build node, so you don't need Docker locally. If your repo already has a Dockerfile with a build step, it is used as is.


Lizard vs Vercel

CriteriaLizardVercel (as of August 2026)
Unit of deploymentLong-lived process in a Firecracker micro-VM, app or worker, no time limitContainer or function, 300s default, 800s max on Pro, 1800s in beta
DockerfileBring one, or let lizardpack write itSupported since June 2026, via Dockerfile.vercel and Vercel Container Registry
Several services in one repoOne lizard up per directory, each its own VMVercel Services, beta, each service billed as a function plus $0.50 per million internal calls
FilesystemFull read-write root plus volumesRead-only, with a 500 MB /tmp
Idle behaviourProcess stays upScales to zero after 5 minutes, SIGTERM with a 30s grace period
WebSocketsOrdinary long-lived connectionsBeta, one invocation per connection, pinned to one instance, ends at maxDuration
DatabasesFirst-party Postgres, Redis, S3 in one command, same region, one billMarketplace: Neon, Upstash, Supabase, one command, separate vendor
Debugging a live applizard ssh into the VM, plus logs and metricsLogs and observability, no shell into a running container
Persistent diskVolumesNone
Agent output--json on every command, plus a versioned skill inside the CLI--json on CLI subcommands, MCP server
Cost visibilityPer-second billing, cost per service in the CLISpend alerts at 50/75/100%; pausing production is opt-in
FrameworkAny stack, lizardpack writes the DockerfileAny framework, tuned hardest for Next.js

What Vercel costs, and what Lizard costs

Both bill on usage, and the rates are not close. Every figure below was checked against the published price lists on 7 August 2026, and the Vercel side uses iad1, one of its cheapest regions.

ResourceLizardVercel (iad1, its cheapest tier)Gap
CPU$0.0278 per vCPU-hour ($0.00000772 a second)$0.128 per Active CPU-hour4.6× on Vercel
Memory$0.0139 per GB-hour ($0.00000386 a second), on measured use$0.0106 per GB-hour, on provisioned size1.3× on Lizard per GB, but see below
Egress to the internet$0.05 per GBFast Data Transfer, $0.15 per GB past the first 1 TB, up to $0.35 in other regions3× to 7× on Vercel
App to edgeNot billedFast Origin Transfer, $0.06 per GB from the first byte, up to $0.43 elsewhere, no included amountn/a
RequestsNot billed$0.60 per million invocations, plus $2.00 per million edge requests past 10 millionn/a
Service-to-service callsNot billed$0.50 per million Service Requestsn/a
BuildsNot billed$0.0035 per CPU-minute — see the row belown/a
Disk$0.16 per GB-monthNo persistent diskn/a
Object storage$0.015 per GB-month, egress freeBlob at $0.023 per GB-month, plus operations and transfer1.5× on Vercel before operations
SeatsNot billed. Hobby is $5 a month, Pro $29 with $29 of credit$20 per seat a month, with $20 of creditn/a

Vercel builds are priced per CPU-minute, not per minute

A build minute on Vercel costs $0.0035 multiplied by the number of vCPUs on the machine, so the headline rate understates the bill by 4× to 30×.

Build machinevCPUMemoryCost per build minute
Standard48 GB$0.014
Enhanced816 GB$0.028
Turbo3060 GB$0.105
Elastic (default for new Pro teams)4–30, auto-assigned8–60 GB$0.014–$0.105

Vercel's own worked example: a build that takes 2 minutes 34 seconds on Enhanced rounds up to 3 minutes and bills 3 × 8 × $0.0035 = $0.084. Twenty deploys a day on that machine is $50 a month before a single request is served. Lizard builds on its own build nodes and does not bill for them.

Why the memory row is not what it looks like

The Lizard rate per GB is 31% higher than Vercel's. The number of GB Lizard counts is several times smaller, because the two platforms are not measuring the same thing.

Vercel bills provisioned memory. Their docs put it plainly: memory is billed for the entire instance lifetime, and stays reserved for your function while it waits on I/O. Configure a 4 GB function and you pay for 4 GB from the first request to the last, whatever the code is actually holding.

Lizard bills measured memory. Once a second the node agent reads MemTotal - MemAvailable from inside the VM and bills that number. Reclaimable page cache does not count, because MemAvailable already counts it as free. A service sized at 4 GB whose app holds 400 MB is billed for 400 MB.

One hour of that 4 GB service:

  • Vercel: 4 GB × $0.0106 = $0.0424

  • Lizard: 0.4 GB × $0.0139 = $0.0056

7.6× cheaper on the one line where the Lizard rate is higher. Over a month, $4.06 against $30.95.

What makes it safe to sell memory this way is what happens underneath. The Lizard node agent watches each micro-VM's page-fault rate and its share of a host core; when a VM goes quiet, its guest pages are marked cold, and after several confirmed-idle cycles they are pushed out with MADV_PAGEOUT into a zswap pool — lz4-compressed, held in up to half the host's RAM, spilling to an NVMe swapfile only if that pool fills. At roughly 3:1 compression a node carries far more memory than it physically has, and pages fault back in as the guest touches them. Eviction goes out in 8 MB batches so the fault storm never stalls a neighbouring VM. None of that reaches you. What reaches you is a bill for what your app was holding.

One busy service, one month

A single service on 1 vCPU and 1 GB, working the whole time, 730 hours:

  • Lizard: 730 × $0.0278 + 730 × $0.0139 = $30.43

  • Vercel: 730 × $0.128 + 730 × $0.0106 = $101.18, before one request or one byte is counted.

That is 3.3× more, and it is the worst case for Lizard: a service pinned at full load is the one case where what Lizard measures equals what you provisioned. It also flatters Vercel, because you cannot hold one container up for 730 hours there at all — it scales to zero after 5 idle minutes and a single invocation caps at 800 seconds. The figure is what the same CPU and memory cost on the Vercel meter.

A working API, one month

50 million requests, 40 ms of CPU each, 200 GB out, 200 deploys, three people on the team. Both sides are configured with the same headroom, 2 vCPU and 4 GB, and only one of them charges for headroom.

The measured figures: CPU is the 556 vCPU-hours the requests actually cost plus about 15 more for the guest kernel and the agent ticking over; memory is around 1.5 GB, being two replicas holding roughly 600 MB each on top of a small guest kernel, with page cache excluded because MemAvailable counts it as free.

Vercel ProCostLizard ProCost
Active CPU, 556 hours$71.11CPU, 570 vCPU-hours measured$15.84
Provisioned memory, 4 GB alive on average$30.95Memory, 1.5 GB measured average$15.22
Invocations, 50 million$30.00Egress, 200 GB$10.00
Edge requests, 40 million past the free 10$80.00Requests$0
Fast Origin Transfer, 200 GB from the app to the edge$12.00Builds$0
Fast Data Transfer, inside the first 1 TB$0Disk$0
Builds, 200 deploys × 3 min on 4 vCPU$8.40Seats$0
Three seats, less the $20 credit$40.00
Total$272.46Total$41.06

6.6× cheaper, and it is worth seeing where that comes from, because it is three separate things.

On CPU both platforms bill real work: Vercel stops the clock while a function waits on I/O, and Lizard reads the guest's own idle share every second. Same unit, so the gap is only the rate, 4.6×.

On memory the units differ, and the difference is bigger than the rate. Vercel charges the 4 GB you configured for as long as the instance is alive. Lizard charges the 1.5 GB the VM was measurably holding. A rate 31% higher on a number 2.7 times smaller comes out at half the cost.

Then there are three lines that add $122 to the Vercel bill and do not exist on the Lizard one: invocations, edge requests, and Fast Origin Transfer. Fast Origin Transfer is the quiet one — $0.06 for every gigabyte the app hands to the edge, from the first byte, with no included allowance. A dynamic API pays it on every response, on top of the Fast Data Transfer the same bytes trigger on the way out.

Split that API into a frontend and a backend with Vercel Services and a fourth line appears: $0.50 per million Service Requests for calls between them.

The headroom deserves saying out loud. That service is sized at 2 vCPU and 4 GB and used about a third of it. The other two thirds cost nothing on Lizard, because nothing measured them. Size a Vercel function the same way and the memory line starts charging from the first second.

The job Vercel will not take

A queue consumer or a WebSocket server sized at 0.5 vCPU and 512 MB, up all month, costs at most $15 on Lizard, and less than that whenever it is waiting rather than working.

On Vercel it has no price, because it has no shape. A container scales to zero after 5 idle minutes, so a poller has nothing to poll from. A WebSocket connection is a single invocation pinned to one instance and ends at maxDuration, 800 seconds on Pro. You reach for Vercel Queues, Workflows, or Cron and rebuild the job as invocations, or you host it somewhere else and pay a third bill.

Where Vercel costs less

A project nobody visits, on a plan you are allowed to use. Vercel Functions scale to zero, so an idle Pro project bills almost nothing for compute and you pay the $20 seat. A Lizard service bills every second it is up, busy or idle.

The Hobby plan is free, with 4 CPU-hours, 360 GB-hours, and a million invocations included, but Vercel's fair use guidelines restrict it to non-commercial personal use — so it is not an option for the app you are selling.

The lines cross as soon as the app has real users, and past that point Vercel meters requests, CPU, and origin transfer, the three things it prices several times higher. For code you are only testing, use a Lizard sandbox: pause it and CPU and memory stop billing, with memory, disk, and processes snapshotted so it resumes where it stopped.


How to deploy with Lizard

Install the CLI, run one command.

# Install
npm i -g @lizard-build/cli

# Deploy your app (from any directory)
lizard up

The build runs on Lizard's build nodes and comes back with a live *.onlizard.com URL and TLS.

Need backing services? Same directory, one line:

lizard add postgres redis s3

All three are provisioned and wired into the service as environment variables. Keep them in the same region as the app, which lizard regions will list for you, and the traffic stays local.

Then there's the loop your agent actually lives in:

lizard logs --build --json    # why the build failed
lizard events --json          # deploy history and replica status
lizard metrics --json         # CPU, memory, network, disk, and cost
lizard ssh "printenv"         # look inside the running VM
lizard redeploy               # try again

Who switches from Vercel to Lizard

The agent building a SaaS. API, worker, frontend, Postgres. On Vercel the worker isn't a request handler, so it gets rebuilt as a Workflow or moved off the platform, and the database comes from a third party. On Lizard the agent runs lizard up in each directory and lizard add postgres, reads the JSON when service three fails, fixes it, and redeploys. One session, one platform, one bill.

The team using Cursor. A Python API, a Node frontend, a Redis cache, and a queue consumer that runs all night. All of it deploys the same way, scales with lizard scale, and bills per second, so a staging copy of production costs what staging actually uses.

The solo founder. You want a live URL with a real backend behind it, not a container that scales to zero between visitors. Start free with $5 of credit and no card. When you outgrow that, Hobby is $5 a month.


Stop configuring and ship

Your whole stack from one CLI. Free to start, $5 a month when you're ready.

Get started free → lizard.build/login

No credit card required.


FAQ

Vercel supports Dockerfiles now. Do I still need an alternative? Depends on what is in the image. If it serves HTTP and finishes inside 800 seconds, Vercel will run it, and running it there is reasonable. If it is a daemon, a poller, a scheduler holding state in memory, or anything that must stay up between requests, Vercel will not: a container there runs under Vercel Function limits, keeps nothing between requests, writes only to a 500 MB /tmp, and gets a SIGTERM after 5 idle minutes. Lizard runs the process as written, for as long as you want.

Is Lizard a good Vercel alternative for full-stack apps? Yes, and that's the main reason people switch. Lizard runs long-lived processes, so APIs, workers, WebSocket servers, and jobs all deploy the same way, and its Postgres, Redis, and S3 are first-party rather than marketplace products.

How is Lizard different from Vercel for AI agents? Both have agent tooling. The difference is what the agent can reach. Every Lizard command takes --json, the usage guide ships inside the CLI so it always matches the installed version, and the agent can open a shell in the running VM, read cost per service, scale it, and provision databases without touching a dashboard.

Does Lizard work with Claude Code, Codex, and Cursor? Yes. Install the skill with npx skills add lizard-build/skill -g, then tell your agent to deploy. It handles services, secrets, addons, and domains.

How does Lizard pricing compare to Vercel? Cheaper on every line except one, and that one reverses on inspection. Rate for rate: a vCPU-hour is $0.0278 on Lizard against $0.128 of Active CPU on Vercel, egress is $0.05 a GB against $0.15, memory is billed on what the VM measurably holds rather than on the size you provisioned, and Lizard has no per-request charge where Vercel bills $0.60 per million invocations, $2.00 per million edge requests, and $0.06 per GB of Fast Origin Transfer with no included amount. Builds are free on Lizard; on Vercel they cost $0.0035 per CPU-minute, which is $0.014 a minute on a 4-vCPU machine and $0.105 on Turbo's 30. Seats are free on Lizard; Vercel Pro is $20 each with a $20 usage credit. One busy 1 vCPU, 1 GB service running all month costs $30 on Lizard and $101 on Vercel, before a single request is counted. A working API on 50 million requests a month comes to $41 against $272. The exception is an idle project: Vercel Functions scale to zero, while a Lizard service bills every second it is up.

Does Vercel Spend Management stop a runaway bill? Not by default. Setting a spend amount turns on notifications at 50%, 75%, and 100%. Pausing production deployments is a separate switch you have to enable, projects have to be resumed one by one afterwards, and Vercel checks spend "every few minutes", so usage keeps accruing past the line. On Lizard, lizard metrics --json returns the accruing cost per service, so your agent can read it and act while the thing is running.

What is Vercel Fast Origin Transfer? Fast Origin Transfer is Vercel's charge for bytes moving from your app to Vercel's edge network, billed at $0.06 per GB in iad1 and up to $0.43 per GB in other regions, from the first byte, with no included allowance. It is separate from Fast Data Transfer, the edge-to-visitor charge, which includes the first 1 TB. A dynamic API pays both on the same response. Lizard bills egress once, at $0.05 per GB.

Can I migrate from Vercel to Lizard? Yes, and an agent can do most of it: redeploy each service, provision Postgres, Redis, and S3, move the secrets over, attach domains, import the data. If you already have a Dockerfile — including one you wrote for Vercel Functions — bring it and it will be used as is.

Does Lizard support frameworks other than Next.js? All of them. lizardpack detects Go, Node, Python, Rust, Ruby, PHP, Java, and static sites, and writes the Dockerfile for you. There is no platform-specific config to add.

Can my agent run untrusted code? That's what sandboxes are for. Each one is a Firecracker micro-VM you create on demand, pause with its full state snapshotted, and resume instantly. Promote a working sandbox to a service with lizard up.


Useful sources

Build with AI. Ship with Lizard.

You don't need a platform team to go live. Your whole cloud, one CLI command away.

Try for free

No credit card required

We use cookies for essential site functionality and analytics. See our Cookie Policy.