Vercel Deployment Workflows for Solo Developers

Vercel makes deployment easy. Maybe too easy. The default setup (push to main, auto-deploy) works great until you push a bug to production at 11 PM and your users notice before you do. As a solo developer, you don't have a QA team or staging reviewers. You need a deployment workflow that protects you from yourself.

Here's the setup I use for RAXXO Studio that balances speed with safety.

The Two-Project Setup

I run two Vercel projects for the same codebase:

• raxxo-studio-dev - the test environment, deployed at a .vercel.app URL
• raxxo-studio - production, deployed at studio.raxxo.shop

Git auto-deploy is disabled on production. Every production deployment is a manual decision. This means I can push to main all day long without affecting real users.

The Deployment Flow

My actual workflow looks like this:

1. Make changes locally, test with npm run dev
2. Push to main (no production impact since auto-deploy is off)
3. Deploy to dev: npx vercel link --yes --project raxxo-studio-dev && npx vercel --prod --yes
4. Test on dev URL, check mobile, verify API routes work
5. When satisfied: npx vercel link --yes --project raxxo-studio && npx vercel --prod --yes
6. Re-link to original project: npx vercel link --yes --project raxxo-studio

The re-linking step matters. Vercel CLI stores the linked project in .vercel/project.json. If you forget to re-link after deploying to dev, your next vercel --prod goes to the wrong project.

Environment Variables: Dev vs Production

Both projects share most environment variables (database, API keys), but auth is different. Development uses test Clerk keys, production uses live keys. This means you can sign in with test accounts on dev without creating noise in your production auth system.

Set environment variables separately for each project in the Vercel dashboard. Never use the CLI to set env vars - it's too easy to set them on the wrong project after relinking.

Disabling Git Auto-Deploy

Add this to your vercel.json:

{
  "git": {
    "deploymentEnabled": false
  }
}

This is the single most important safety measure for a solo developer. Without it, every push to main is a production deployment. With it, you always have a manual gate between your code and your users.

Preview Deployments for Branches

Even with auto-deploy disabled on production, Vercel still creates preview deployments for branches and pull requests. This is useful when you want to test a feature branch without deploying to either environment.

Push a branch, Vercel builds it, gives you a unique URL. Share it with a friend for feedback, test it on your phone, then merge or discard. The previews auto-expire after a while.

Rollback Strategy

Vercel keeps every deployment. If you push a bad production build, you can instantly roll back to the previous one from the dashboard. Click Deployments, find the last working one, click the three-dot menu, Promote to Production. Takes 30 seconds.

I also use git tags before major deployments:

git tag pre-feature-x && git push origin pre-feature-x

This gives me a clear point to roll back to in the codebase, not just in Vercel.

Build Optimization

Build times matter when you're deploying multiple times a day. A few things that keep Vercel builds fast:

• Use typescript.ignoreBuildErrors: true if you're iterating quickly (not for everyone, but it prevents TS errors from blocking deploys)
• Minimize server-side dependencies. Every package increases cold start time
• Use the outputFileTracingIncludes config to explicitly include files your API routes need instead of letting Vercel's tracing guess

Monitoring After Deploy

After every production deployment, I check three things:

1. Runtime logs in Vercel dashboard - any errors in the first 5 minutes?
2. The main user flow - can I sign in, upload a video, get results?
3. API response times - anything slower than usual?

For a solo developer, automated monitoring is overkill at first. Just build the habit of checking after each deploy. When you have paying users, add uptime monitoring (Vercel has built-in checks, or use something like Better Stack).

The Solo Developer Safety Net

The whole system comes down to one principle: never let a deployment happen without an intentional decision. Automation is great for testing, terrible for production when you're the only one watching.

RAXXO Studio uses this exact workflow for all deployments. Try the app at studio.raxxo.shop.