Vercel app testing

Test the apps you deploy to Vercel before the deploy goes live

Vercel ships your app the moment you push, but the deployment breaks where your laptop did not. Kane CLI drives your live Vercel URL in a real browser, runs the flow in plain English, and returns a pass or fail. Free to install.

npm install -g @testmuai/kane-cli

or read the documentation

Why test apps deployed to Vercel

Vercel turns a Git push into a live deployment: a global edge network, serverless and edge functions, preview URLs per pull request, and instant production promotion. That speed is the point, but the deployed app runs in the cloud, not on your machine.

That is where Vercel deployments break. An env var set locally is never added to Production, a SPA route 404s on refresh without a rewrite, a function that passes in dev throws in the cloud, and an ISR page serves stale content you cannot reproduce.

Kane CLI is the second pair of eyes. Describe the journey in plain English and it drives your live Vercel URL in a real Chrome browser, signs in, and checks each step on production. Vercel deploys from Git, so your agent can run it.

Kane CLI verifying a deployed app flow in a real browser

What Kane CLI tests on your Vercel deployment

Env vars, functions, routing, and the production build, verified on the live URL.

Environment variables in production

Confirm the deployed app reads the values it needs. Vercel does not load your local .env for deployments, so a key that works in vercel dev can be unset in Production and blank out the page. Catch it before users do.

SPA routes and 404 on refresh

Open a deep link and reload it. Client-side routes do not exist as files, so without a rewrite in vercel.json the live deployment returns a 404 on refresh while your local dev server hides the problem.

Serverless and edge functions

Trigger the functions behind your forms and APIs and confirm they return instead of throwing. Functions that pass locally often fail in the cloud on cold starts, region, or runtime differences you cannot see from your laptop.

API routes, CORS, and 405s

Walk the calls your frontend makes and confirm they succeed. Catch the 405 on a method Vercel does not route, the cross-origin request the browser blocks because CORS headers were never set, and the silent fetch that never resolves.

Production build, not just local dev

Run against your production or preview domain to catch hydration mismatches between server and client HTML, blank screens from a failed build chunk, and assets that 404 after a redeploy with a new commit hash.

ISR and stale caching

Verify the page that should refresh actually does. ISR only runs on the deployed Vercel app, never in local dev, so a cached 404 or stale data that you cannot reproduce on your machine quietly reaches every visitor.

Build up confidence before the deploy goes live

Start in your terminal

Validate on the cloud

Release with confidence

Built for the push-then-verify loop

Kane CLI and KaneAI share the same automation engine and dashboard.

Built for the push-then-verify loop

Vercel builds and ships your app the moment you push. Kane CLI proves the live production or preview deployment works for a real user before that deploy reaches anyone.

Verify the live deployment, not the code that looks right

Code that passes on your laptop passes in the cloud far less often than it should. You or your coding agent point Kane CLI at the live Vercel URL, and it drives the deployed app in a real browser to confirm the flow, not the local run.

Evidence you can share

Every run produces a persistent video, a step trace, and a replay link you can drop into a PR, a Vercel deployment comment, or a team message.

Test your Vercel deployment in three steps

Install Kane CLI

Run npm install -g @testmuai/kane-cli and sign in with your TestMu AI account. Nothing to wire into your Vercel project or build settings.

Point it at your Vercel URL

Use the production domain or the per-deployment preview URL Vercel generates on each push. Run flows from the terminal, or tell Cursor, Claude Code, or Codex to run them after a deploy.

Describe the flow and verify

Write the journey in plain English: open the page, sign in, submit, confirm it loaded. Kane CLI drives a real browser, verifies each step, and returns a pass or fail with evidence.

Get Started With Kane CLI

🎉 Launch offer: Bonus credits for the first 3 months on paid plans

Choose the right plan for you

Local test authoring via CLI

Auto-heal & vision

View test cases on UI

Test Manager

Free

/month

200 Credits

Resets in every

30 days

Free tier

Starter

$19

/month

2000 Credits

Launch: 4,000 Credits (+100%)

Bonus for first 3 months

Free tier

Get the technical rundown

Blog

A look at Kane CLI. What we built, what it does, and where it is headed.

Read the blog

Documentation

Everything you need to install, configure, and run Kane CLI in under 2 minutes.

View documentation

GitHub

Browse the source, file issues, and follow the roadmap on GitHub.

Open GitHub

Frequently asked questions

Install Kane CLI, then describe the journey in plain English, for example "open the production URL, sign in, submit the form, and confirm the success page loads." Kane CLI drives your live Vercel deployment in a real Chrome browser, runs the flow against the actual production or preview URL, checks each step, and returns a pass or fail with video evidence. Run it from the terminal, or let your coding agent run it on every push before you promote a preview to production.

Vercel builds and ships your app the moment you push, but the deployed app runs in a different place than your laptop. The classic break: it works in vercel dev and breaks in production because an environment variable was added locally but never set in the Production environment on the dashboard, since Vercel does not read your .env file for deployments. Add SPA routes that 404 on refresh without a rewrite in vercel.json, serverless and edge functions that error only in the cloud, and ISR pages that serve stale content, and a local pass tells you nothing about the live site. Kane CLI verifies the real deployment in a browser before users hit it.

The full user journey on your production or preview URL: sign in, form submits, navigation, and the screens rendering instead of going blank. It catches the 404 on refresh from missing SPA rewrites, serverless and edge function errors that only appear in the cloud, API routes returning 405 or CORS failures, hydration mismatches between the server-rendered and client-rendered HTML, and ISR pages serving stale data. It checks each step, not just the final screen, and flags the exact point where the deployment breaks.

Yes. Vercel deploys straight from your Git repo, so a coding agent like Cursor, Claude Code, or Codex that edits that repo can verify its own work. Point that agent at the guide at testmuai.com/kane-cli/agents.md and it will install Kane CLI, run flows against the preview URL with the --agent flag, read the structured results, and fix the unset env var or broken function before the deploy is promoted. Push to Vercel, hand off to your agent, verify with Kane CLI, in one loop.

Yes. Authenticate with your TestMu AI credentials, pass --headless and --timeout, and gate your pipeline on the exit code: 0 on pass, 1 on fail, 2 on setup or auth errors, and 3 on timeout. Run your critical flows against the Vercel preview URL on every pull request, so a missing environment variable, a broken serverless function, or a 404 on refresh never gets promoted to production.

The CLI is free to install and use. Local runs are free; cloud runs on the TestMu AI grid are billed against your TestMu AI plan. Start on the free tier and verify your Vercel deployment end to end without a credit card.

Teach your agent to test what it deploys to Vercel

Vercel deploys straight from your Git repo. Point your coding agent at the Kane CLI guide and it will install, authenticate, and verify the flows against your preview URL in a real browser on its own.

Point your agent to: testmuai.com/kane-cli/agents.md