Vibe coders, set up a local environment

I was talking to someone recently who was interviewing “vibe coders.”

The takeaway was grim. Most of them don’t have a staging environment. They push code straight to production and hope for the best.

I get it. Vibe coding is about speed. You prompt, you ship, you move on. But if you’re building something real, something with users and their data, pushing untested code to prod is how you lose trust overnight. One bad migration, one broken auth flow, and you’re scrambling to fix something you could’ve caught on your own machine in two minutes.

You can run your entire Supabase stack locally. Your database, auth, edge functions, email, all of it. Here’s my setup.

OrbStack, not Docker Desktop

Docker Desktop works but it’s slow and heavy. OrbStack boots in about 2 seconds. Docker Desktop takes 20-30. OrbStack uses 60% less RAM and about 4x less power when idle. If you’re on a Mac, just switch. orbstack.dev.

Run Supabase locally

Most vibe coders I’ve talked to develop directly against their production database. Every schema change, every edge function test, every experimental migration hits real user data. I’ve seen people drop columns in production because they were “just trying something.”

Local Supabase is free, instant, and private. No quota, no latency, no risk. The setup:

1. Install OrbStack
2. supabase init in your project root
3. supabase start pulls the images and boots everything
4. Open localhost:54323, that’s your local dashboard

Write migrations here. Break things here. When it works, push it with supabase db push. If something goes wrong, it goes wrong on your machine, not on your users’ accounts.

Mailpit for email testing

Supabase Auth sends emails: signups, password resets, magic links. In production those go to real inboxes. Locally, Mailpit catches all of them.

brew install mailpit, open localhost:8025. Every email your local Supabase sends shows up there instantly. You can see the HTML, the headers, the attachments. No more sending test password resets to your own Gmail and checking spam.

Don’t commit your .env

I see this constantly. .env files pushed to git with Supabase keys and API tokens sitting right there. Put your secrets in .env at the project root. The Supabase CLI picks them up automatically. Add .env to .gitignore before your first commit.

My daily workflow

This is how I work on my app every day:

1. supabase db pull to grab any remote changes
2. Make schema changes locally in Studio or raw SQL
3. supabase db diff -f migration-name to generate a migration
4. supabase db reset to test it clean
5. If it passes, supabase db push
6. supabase functions deploy for edge functions

Everything is tested before it touches prod. That’s it. Five minutes to set up, and it’s the difference between a professional workflow and crossing your fingers every time you deploy.