When you're building something, your code and data exist in several different places at once. This is one of the most confusing parts of coding for anyone new to it — something works on your computer but not on the live site, or you made a change but it didn't show up. This map explains why.
What it is: Your laptop or desktop. The computer you're sitting at.
What lives here: Your code files as you write them, your terminal, your code editor (VS Code, Cursor, etc.), your local .env file with your secret keys.
What it's for: Where you write and test before sharing anything with the world.
Key rule: Changes you make here stay here until you push them to GitHub. Nobody else can see your local files.
Common confusion: "I changed the code but the website didn't update." — The website runs from GitHub or Vercel, not your local machine. You have to push first.
What it is: A website that stores copies of your code online. What lives here: Your code history — every saved version (commit) you've ever pushed, plus your branches and pull requests. What it's for: Backup, collaboration, and connecting to Vercel for deployment. Think of it as the warehouse that holds all your packages before Vercel ships them to the world. Key rule: Code on GitHub is not live on the internet yet. GitHub stores it. Something else (Vercel, your server) publishes it.
Your secret keys: Do NOT put API keys, passwords, or Supabase service_role keys in files you push to GitHub. Anyone can see public repos. Use .env files and add them to .gitignore.
What it is: A service that takes your code from GitHub and turns it into a live website — automatically, every time you push. What lives here: The built, published version of your frontend (React, Next.js, plain HTML, etc.) What it's for: Showing your website to the world. Every time you push to GitHub, Vercel notices and rebuilds your site in about 30-60 seconds. Key rule: Vercel handles the frontend only. Your database (Supabase) and automation tools (n8n) live elsewhere. Vercel just displays the interface.
Environment variables on Vercel: Your .env file on your local machine does NOT go to Vercel automatically. You have to go to Vercel → your project → Settings → Environment Variables and add each one manually.
What it is: A computer in a data centre somewhere in the world that runs 24 hours a day, 7 days a week. What lives here: Your backend code, Docker containers, n8n workflows, Telegram bots, scheduled jobs, anything that needs to run all the time. What it's for: The "always on" parts of your app — bots, automation, APIs, cron jobs. Key rule: Your VPS and your laptop are completely separate computers. Making a change on your laptop does nothing to the VPS. You have to SSH in (connect to it remotely) to make changes there.
Docker on VPS: If your app runs inside Docker containers (check if there's a docker-compose.yml file), the containers are sealed lunchboxes. Changes to the server itself — like running pip install on the server — don't reach inside the containers. To update what's inside, edit the code, update requirements.txt, and run docker-compose up --build to rebuild the containers.
"I changed the code but the VPS is still running the old version" — You pushed to GitHub but didn't pull on the VPS. SSH into the VPS and run git pull, then restart your service.
What it is: A hosted database and authentication service. It lives in the cloud — not on your VPS, not on Vercel. What lives here: Your app's actual data — user accounts, records, messages, files, anything your app stores and retrieves. What it's for: Storing and retrieving data from your app. Your frontend (Vercel) and backend (VPS) both talk to Supabase to read and write data. Key rule: Supabase is completely separate from everything else. It's always running. Changes to your code don't affect Supabase — only changes made in the Supabase dashboard or SQL editor affect it.
What it is: An automation tool — it connects different services and runs workflows automatically. What lives here: Your automation logic — "when this happens, do that" rules. What it's for: Moving data between services without writing code, sending emails, triggering actions, processing form submissions. Key rule: n8n has two types of webhook URLs — a test URL (only works while you're watching it in the n8n dashboard) and a production URL (always active). Forms on your live website must use the production URL.
You write code on ──────────────► Your Laptop
│
git push │
▼
Code backs up to ──────────────► GitHub
│
auto-deploy │
▼
Frontend goes live on ─────────► Vercel (your website)
│
│ talks to
▼
Your data lives in ────────────► Supabase (database + auth)
▲
│ talks to
Your backend runs on ──────────► VPS in Docker (bots, automation, APIs)
│
runs on │
▼
Your automation runs in ───────► n8n (workflows, webhooks)
When something breaks, the first question is always: Which environment is it in?
A broken Vercel deploy is a different problem from a broken Docker container, which is different from a Supabase RLS error. Knowing where the problem lives tells you where to look — and what kind of fix to apply.