Platforms for Shipping: Vercel, Supabase & the AWS Alternatives

You built it — now ship it

In Part 1 you got an app running on your machine. This part is the second foundation: the platforms that put it online, and the AWS services that do the same jobs. The backend parts (3–5) just say "now deploy it" — because the how lives here. Read it once; the others link back.

Every web app needs two things

Vercel answers the first. Supabase answers the second. AWS does both — more pieces, more control.

Vercel — your deploy platform

Vercel hosts frontends (from the team behind Next.js). Connect a GitHub repo; every push builds and deploys, with a preview URL per branch and a global CDN.

npm i -g vercel
vercel            # preview deploy
vercel --prod     # production deploy

Static files vs Next.js pages on Vercel

"Deploying to Vercel" hides a distinction worth understanding, because it decides what your site costs to run and what can break at 3am. Three different things can answer a request, and only one of them runs code:

The build tells you which one you got. Run next build and read the route table — ○ is prerendered, and ƒ means a function runs on every hit:

$ next build

Route (app)
┌ ○ /                     ← prerendered at build, served from the CDN
└ ○ /_not-found

○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand

A page goes dynamic the moment it reads something that only exists per request — cookies(), headers(), searchParams, or an uncached fetch. That's not a failure; it's the correct answer for a logged-in dashboard. It's only a problem when it happens by accident to a page that could have been free.

Supabase — your backend platform

Supabase wraps a managed Postgres database with the services an app needs, so the database itself becomes your backend — no server to run.

The key idea: the database is your API (RPC)

With Supabase you often don't write API endpoints at all. You put logic in a Postgres function and call it by name — an RPC. The function is the endpoint:

// no URL, no route file — just call the function by name
const { data, error } = await supabase.rpc('submit_answer', {
  game_id: gameId, player_id: playerId, option_id: optionId,
});

Pair that with Row Level Security and the database can safely be your entire backend — the rules travel with the data instead of living in an API layer you have to remember to write.

How Supabase Auth actually works

Auth is the part people most often get wrong when they move to Supabase, because it doesn't work like the auth service you're used to. Most auth providers hand you a token and leave enforcement to you. Supabase hands you a token the database itself understands — and that one fact explains everything else about it.

The token is a database credential

Sign a user in and Supabase issues a short-lived access token (a JWT) plus a long-lived refresh token. The interesting part is what's inside the access token:

// the claims that matter
{
  "iss":  "https://abcd.supabase.co/auth/v1",
  "sub":  "9f8c…",            // the user id — this is auth.uid() in SQL
  "role": "authenticated",    // an actual Postgres role
  "exp":  1893456000
}

role is not a label your code checks — it is the Postgres role the query runs as. So when the browser talks to the database, your Row Level Security policies are the thing standing in the way, and they're enforced by Postgres rather than by an API layer you had to remember to write:

create policy "own rows only" on notes
  for select to authenticated
  using ( (select auth.uid()) = user_id );

That's why it's safe to query Supabase straight from the browser, and why "where do I put my API?" often has the answer "you don't need one".

browser ──token──▶ Supabase ──▶ Postgres
                                  │
                                  ▼  RLS reads auth.uid() from the token
                            only that user's rows come back

On the frontend (Next.js)

Install @supabase/supabase-js and @supabase/ssr. The browser gets a client built with your publishable key — safe to ship, because RLS is what protects the data:

// lib/supabase/client.ts
import { createBrowserClient } from '@supabase/ssr';

export const createClient = () => createBrowserClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
);

Server Components can read the session from cookies but can't write them, so refreshing an expiring token is the job of one file at the project root. In Next 16 that file is proxy.ts — middleware.ts is the deprecated name for the same thing. It refreshes the token and writes it back to both the request and the response.

Which call you reach for on the server matters, and the answer changed recently:

On a separate backend

You don't have to give up your own API. If you're running the Python service from Part 6, the frontend sends the same token it already has, in the header the whole web already understands:

Authorization: Bearer <supabase access token>

Your backend then verifies it locally. Supabase publishes its public keys, so there's no call back to Supabase on the hot path — fetch the key set once, cache it, and check the signature yourself:

# the project's public keys — cache these, don't fetch per request
https://<project-ref>.supabase.co/auth/v1/.well-known/jwks.json

# then, per request:
#   1. verify the signature against the matching key
#   2. check exp and iss
#   3. trust sub as the user id — never read the id from the body

Supabase Auth vs Cognito

They both issue JWTs and both publish a JWKS endpoint. The difference is what the token is for:

The AWS alternatives

AWS hands you individual services you assemble. Every job Vercel and Supabase do has an AWS counterpart:

Which should you choose?

Capture your deploy setup in CLAUDE.md

Write your platform choices where Claude Code sees them every session — so "deploy this" just works:

# CLAUDE.md

## Deploy
- Frontend: Vercel, auto-deploys on push to main; preview on every PR.
- Manual:   vercel (preview) / vercel --prod (production).
- Data:     Supabase project ref abcd — migrations in supabase/.

## Environments & secrets
- Local env in .env.local (gitignored). Never commit keys.
- anon key = public/client-safe; service-role key = server-only.
- Mirror NEXT_PUBLIC_* vars in Vercel → Settings → Environment Variables.

## AWS alternative
- Host: aws s3 sync ./out s3://<bucket> + CloudFront invalidation, or Amplify.

## Rule
- Every deploy comes from git — no manual uploads.

How Claude Code helps

Ask for the platform Skills by name and let Claude Code run the deploy commands: