Git is a
Type 2 dimension table

The problem

The trade-off that used to favor clicking

Every hosted service — Supabase, Railway, Fly.io, Cloudflare, Stripe — ships with a web console. For a solo operator with a few settings and good memory, the console is the fastest path. For a two-decade stretch, that was the correct default. The axis along which it held: the operator is a human, inspection is cheap, drift is recoverable in an afternoon. Shops that adopted heavier tooling like Terraform did so at real cost and the payoff showed up only at scale.

The axis has moved. An agent is now in the loop — reading the repo, proposing changes, running the deploy, writing the retrospective. When that agent is asked "what is the current Site URL, and when was it last changed, and by whom?", a dashboard edit made six months ago is not merely inconvenient. It is invisible.

Four seams in the modern auth stack

Consider any greenfield auth shipped on the current stack: Astro on Railway, Supabase for auth, Migadu or a comparable provider for email. Four seams appear independent of team skill:

The root that produces all four

Patching each seam in isolation costs a PR. Patching the thing that generates seams costs a pipeline. In the case study behind this piece, the Supabase Site URL setting held http://eidosagi.com — http, no path. Set at project creation. Never revisited. Never seen. Nothing in the code said "assume http"; the code assumed https.

The approach

The fix has the same shape across every hosted service with a Management API: declarative file in the repo, CI step that reconciles hosted state to match the file on merge, scoped token as a repo secret. The file is the source of truth. The dashboard becomes a read-only picker.

[auth]
site_url = "https://eidosagi.com"
additional_redirect_urls = [
  "https://eidosagi.com",
  "https://eidosagi.com/auth/callback",
  "http://localhost:4321/auth/callback",
]

on:
  push:
    branches: [main]
    paths: ['supabase/config.toml']

jobs:
  push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: supabase/setup-cli@v1
      - env:
          SUPABASE_ACCESS_TOKEN: <secret reference>
        run: supabase config push --project-ref <project-ref> --yes

A Management API Personal Access Token — scoped, expiring, revocable — authenticates the push. Standing this up is one PR. The cost of not standing it up compounds silently across every subsequent config change.

If you want to do this yourself

The minimum viable pipeline is five steps. Each one below is a concrete action the reader can take; none of it is narrative about what we did.

1. Generate a Supabase Management API token scoped to your account. Copy it once; they don't show it again.
2. In your repo, add the token as the SUPABASE_ACCESS_TOKEN secret at Settings → Secrets and variables → Actions.
3. Commit a curated supabase/config.toml containing only the fields you've deliberately chosen — do not include defaults, which invite silent regressions when the vendor changes one.
4. Add a GitHub Actions workflow that runs supabase config push --project-ref <ref> --yes with the secret in env. Gate its paths: on the config file so unrelated commits don't fire the workflow.
5. Merge. Verify via the Management API that the hosted settings match the file. If they don't, the workflow's log tells you which field tripped.

Expand the same shape to every hosted service with a Management API. Cloudflare, Stripe, Fly.io, Railway each have equivalents.

The evidence

Versioning schema changes with forward-only migrations is the incumbent. 0001_init.sql, 0002_add_column.sql, each step overwriting the last. To answer "what was this field set to on March 1st?" a migration-based system requires replaying every migration in order up to that date.

Every commit touching the config file is implicitly a row in a Type 2 slowly-changing-dimension history table: field name, new value, valid_from (commit timestamp), valid_to (next commit touching the same field), author, message. The git log command is the SELECT statement.

$ git log -p -S 'site_url' -- supabase/config.toml
commit 96d520d  2026-04-22  Daniel Shanklin
feat: config-as-code pipeline for Supabase

-site_url = "http://localhost:4321"
+site_url = "https://eidosagi.com"

The entire history of a single field, across the life of the project, retrieved by any agent in one shell command. Author, timestamp, exact before-and-after, the commit message explaining why. The declarative part stops the drift. The git-as-history part makes the state queryable across time. Together they remove the entire class of "who changed this, when, and why" questions that otherwise dead-end at a screenshot of a dashboard someone opened two quarters ago.

The result

Dashboard-first was the right default when humans were the only operators and every change was inspected by the person who made it. That defence is gone the moment an agent has to reason about the same system — and at that point the decision flips. Not because the old pattern was stupid, but because the operating model is different.

The rule that falls out: if a dashboard click can change how production behaves, and an agent is going to operate on that production later, the click belongs in a file first. The file earns its place because it's the only artifact the agent can read. The git history earns its place because it's the only way the agent can answer historical questions without a human.

Migrations will lose to version-controlled config for the same reason XML lost to JSON: the thing that makes replay costly is what makes the format resistant to agent inspection. Every hosted service with a Management API is one PAT and one workflow away from this pattern. The work to adopt it is smaller than the work caused by postponing it.