A beginner opens six tabs — Vercel, Cloudflare, Supabase, Neon, GitHub, AWS — and every logo seems to promise "hosting." A modern application can genuinely use seven services and still be one product. The confusion is natural, and the cure is a single question: not *which platform wins*, but *which job is each platform doing?*

One product, seven jobs

Read this stack top to bottom — it is the whole lesson in one diagram:

Builder changes project files
  → GitHub or GitLab stores the versioned project and runs checks
  → Vercel deploys the web experience and request-driven functions
  → Cloudflare manages DNS, edge delivery, and optional Workers/Queues
  → Supabase or Neon stores durable Postgres data
  → Cron / worker handles scheduled or long-running work
  → AWS is a later option when the simpler stack has a real limit

Each arrow is a handoff with an owner. Learn each role in plain language.

Each role, plainly

GitHub / GitLab — the versioned home, not the host. Your repository is the project's controlled source of truth: code, history, branches, code review, and deployment triggers. A git push causes a platform to build and deploy a preview or production version. Automated checks run from the same place. What they are *not*: the app host, the database, or the place users visit. See the GitHub Actions docs and GitLab CI/CD docs for current behavior — the durable idea is truth-plus-checks-plus-triggers. (This connects back to your Git and branches lessons: the workflow below assumes you know branches and pull requests.)

Vercel — the web experience and its functions. Hosted frontend deployments, preview URLs for every branch, serverless functions beside the pages, environment settings, and scheduled jobs. The fastest honest route from repository to live site for a web product. Good first choice when the product *is* a website with endpoints.

Cloudflare — the network edge in front of everything. Domain and DNS control, content delivery, edge protection, plus Workers, Queues, and storage options when you need them. It often sits in front of the public product deciding how traffic reaches it. Think of it as the front gate and the fast lanes, not the building itself.

Supabase — the backend foundation. Managed Postgres plus authentication, storage, APIs, realtime features, and functions, per the Supabase docs. Often the product's data home: users, records, files metadata, access rules. It pairs with an app running on Vercel or Railway — it does not replace that app.

Neon — serverless Postgres with branching. Managed Postgres designed to work well with preview and deployment workflows: branch the database the way you branch code. Reach for it when the product needs a clean Postgres that composes with a Git-driven workflow. Supabase-or-Neon is a choice of data home, not two homes.

AWS — the broad platform, kept secondary. Excellent technology with an enormous surface: dozens of services, service-by-service pricing, and real engineering decisions per service. In today's AI-building world it is usually a *secondary* choice — correct once the project has an existing AWS organization, unusual infrastructure requirements, serious scale, or a team that needs deep control. Many serious products never move there because focused managed services stay simpler to operate. Do not build an AWS-shaped solution for a problem you do not have.

The beginner stack as a relationship

The most useful first stack is four services with clear handoffs:

GitHub repository → Vercel preview/production deployment
  → Supabase database → Cloudflare DNS in front

Push to a branch; Vercel builds a preview URL; checks run; a reviewer clicks the preview; merge to the main branch triggers production; Supabase holds the data throughout; Cloudflare points the domain at the result. A single builder can start with two or three of these — repository plus deployment plus database — and add DNS when the product goes public.

The deployment connection relies on the branch workflow: work on a branch, open a pull request (GitHub) or merge request (GitLab), let automated checks run, inspect the preview deployment, then merge to the branch that triggers production. If that sentence felt fast, revisit the Git and branches lessons first — they are the canonical home for that workflow, and this lesson assumes it.

Actions and CI: repository automation, not production workers

GitHub Actions and GitLab CI/CD are automated work triggered by repository events: run tests on every pull request, build and deploy on merge, run scheduled maintenance, enforce checks. Their schedules overlap with cron in some situations — a nightly test run, a weekly dependency check. But they are not a replacement for a durable production worker: CI runners are time-boxed, built for builds and checks, and the wrong home for user-facing background jobs with retries and queues. Class 26 draws that line permanently.

The source-of-truth rule

Four belongings, four homes — memorize this:

| Belongs | Home |

|---|---|

| Source code | Git (GitHub / GitLab) |

| Secrets | The deployment platform's environment settings |

| Data | The database |

| User uploads | Object storage (Lesson 25.5) |

Never put secrets in a repository. Never treat a deployed server as the only copy of a project. When something breaks at 11 p.m., this table tells you where the recoverable copy lives.

Practical exercise: write STACK-OWNERSHIP.md

Create STACK-OWNERSHIP.md for one project with five columns:

| Responsibility | Chosen service | Why it is there | Where its credentials live | What happens if it goes down |

|---|---|---|---|---|

| Repository | | | | |

| Deployment | | | | |

| Domain / DNS | | | | |

| Database | | | | |

| Storage | | | | |

| Scheduled / background work | | | | |

| Monitoring | | | | |

Start with all seven rows even if a cell says "not yet — local only." The honest "not yet" is the point: it shows which jobs have no owner today. "Why it is there" must name the workload reason ("preview URLs per pull request"), not the logo's reputation. "Credentials" must name the actual home ("Vercel environment settings," "password manager vault," never "in the repo").

Finish line: a filled table where you can point to every service in your stack and explain its job without calling all of it "the backend."

Verify: pick any row and ask: "If this service emailed me that it was shutting down tomorrow, what is my first move?" If the table cannot answer — no credential location, no fallback — the row is decorative.

Common failure mode: listing seven services for a project with one user. Start from the workload, choose the fewest services that solve it, document who owns each responsibility, and add services only when a concrete need appears.

Check your understanding

1. Which platform owns the versioned source of truth, and which two things is it *not*? 2. What sits in front of the product deciding how traffic reaches it? 3. Why is scheduled CI not a substitute for a production worker? 4. Recite the four belongings and their four homes.