0.7.0 — auth emails as the app, confirmation-ready

Supabase's sign-up confirmation and password-reset emails now ship as supabase/templates/confirmation.html and recovery.html, wired in config.toml under [auth.email.template.*] (put your app's name in the header). Email confirmation still ships off (enable_confirmations = false); the comment beside it says how to switch it on locally, and localhost:4321's two links-site pages are on the local redirect list. The welcome endpoint's docs explain why, with confirmation on, the webhook should fire when the address is confirmed rather than when the row is inserted.

0.6.2 — a profile row belongs to its account, by foreign key

A new migration (20260917200000_users_follow_auth_users.sql) gives public.users.id a foreign key to auth.users(id) with ON DELETE CASCADE, and drops the on_auth_user_deleted trigger and handle_deleted_user() that deleted the row by hand. The id of a profile row IS the account's id, so the row is a child of the account and the database can be told so directly: it cannot be forgotten the way a trigger can, it also refuses a profile row for an account that does not exist, and it is one mechanism instead of two. Deleting an account still cascades on to devices, and delete_own_account() is unchanged.

The migration clears any profile rows whose account is already gone before adding the key, so it applies to a database that was restored or written to by hand. Package version stays 0.0.1 by design.

0.6.1 — keepalive(), so a free Supabase project never pauses

A new migration (20260910170000_keepalive.sql) adds public.keepalive(): STABLE, no arguments, reads no table, returns now(), EXECUTE granted to anon. Anything that pings on a schedule — Mosayic's keep-alive, a GitHub Actions cron, an uptime monitor — can call GET https://<ref>.supabase.co/rest/v1/rpc/keepalive with just the publishable key in the apikey header, and Supabase's inactivity clock resets. Like delete_own_account(), it exists in production the moment your first release runs the migrations — no API deploy needed. Package version stays 0.0.1 by design.

0.6.0 — account deletion two ways, and nightly backups

Account deletion — the one server-side thing the stores require before submission — now ships two ways. A SECURITY DEFINER Postgres function, delete_own_account(), arrives by migration (20260905120000) and is called with supabase.rpc: it deletes only auth.uid(), is executable by signed-in users only, and works the moment your first release runs the migrations — no API deploy needed. And the API keeps DELETE /auth/users/me (app/routes/auth_router.py), the same deletion done by the server with the service-role key. The mobile app (0.7.0) ships both and one constant picks: ACCOUNT_DELETION in src/lib/api.ts, 'database' by default.

Also since 0.5.4: the nightly database backup workflow (0.5.5), [inbucket] renamed to [local_smtp] in supabase/config.toml, and a CLAUDE.md that carries the production rule (never write to the hosted database by hand — schema changes are migrations that ride releases), the storage rules, and how this ships. Package version stays 0.0.1 by design.

0.5.5 — nightly database backups that ride the deploy robot

scheduled-backups.yaml is now a real nightly backup instead of a switched-off draft: every night at 03:27 UTC it dumps the production database (roles, schema, data) with the Supabase CLI and uploads the three files to a date-stamped folder in a Google Cloud Storage bucket you own — daily/ always, weekly/ on Sundays, monthly/ on the 1st, each tier pruned by a lifecycle rule on the bucket. Supabase's free tier keeps no backups; this is yours.

It needs no new secret. The dump reads the migrations workflow's DATABASE_CONNECTION_STRING and the upload runs as the deploy workflow's github-deployer account (GCLOUD_SERVICE_KEY — its storage.admin role covers the bucket), so set up automatic deploys first. Until both secrets exist it skips itself quietly, green. The one-time setup — a bucket, its retention rule, and two values in the env: block — is in the workflow's header; Mosayic's "Back up your database" card does it in one click. On Supabase Pro (daily backups included) disable it from the Actions tab. (Package version stays 0.0.1 by design.)

0.5.4 — clear the managed base image on every Cloud Run deploy

The deploy command — in gcp-deploy.yaml and the README's manual variant — now passes --clear-base-image. Cloud Run's managed base-image tracking can refuse a REdeploy of a --source service without it, which would have bitten the first release after any successful deploy. The flag is harmless on a first deploy, so it simply rides every deploy. (Package version stays 0.0.1 by design.)

0.5.3 — install curl so the uv installer can run in the Docker build

The base-image switch to python:3.12-slim (July 7 modernize commit) silently dropped curl from the image. The Dockerfile fetches uv's install script with ADD — which Docker downloads itself — but the script then needs curl or wget to fetch the actual uv binary, so every Cloud Run source build failed at that step with need 'curl or wget' (command not found). The first real deploy to exercise this Dockerfile (The Production Backend lesson) hit exactly that error. curl is now installed alongside ca-certificates and openssl — the same one-line fix already proven in a live Cloud Run deploy. (Package version stays 0.0.1 by design.)

0.5.2 — initial migration grants table privileges to the API roles

The initial schema migration now GRANTs table-level privileges alongside its RLS policies: authenticated gets SELECT/UPDATE/DELETE on users (row creation belongs to the SECURITY DEFINER trigger) and full DML on devices; service_role gets full DML on both. RLS policies only filter rows on top of the table ACL — on a database where Supabase's stock auto-grant defaults have been hardened away, the missing grants meant every query failed with 42501 before RLS was even consulted. Schema shape is unchanged, so generated types stay in sync. (Package version stays 0.0.1 by design.)

0.5.1 — deploy-key ceremony comment aligned with the course

gcp-deploy.yaml's one-time-setup comment now mints the github-deployer key into the workspace parent (outside the repo) and has you delete it by hand once gh has stored it — the same ritual as every other robot key — and notes how to extend --update-secrets with additional NAME=NAME:latest pairs. Comment-only change; no behavior differs. (Package version stays 0.0.1 by design.)

0.5.0

API deploys now ride releases: the gcp-deploy workflow is active on release-published, authenticating with a dedicated github-deployer service account through a single GitHub secret (GCLOUD_SERVICE_KEY, raw JSON — no base64). One-time setup lives in the workflow header; until it's done the workflow skips itself quietly. The old placeholder workflow (base64'd compute-account key, marked 'ignore for now') is gone.