sudo

g1t's staff console, at https://sudo.g1t.sh. It is organised the way customers know g1t: by workspace.

• Workspaces (the home page): every workspace, with its owners, members, who it is billed to, its terms, this month's usage against its limit, what it was charged and what it cost g1t. Search by workspace, owner, email or enterprise; filter to stopped or warning, comped or custom, or on an enterprise. A workspace's page shows its members, and under Billing its terms, who it is billed to (move it onto or off an enterprise), a credit form, a Stripe billing link, its ledger and its audit log.
• Enterprises: customers that pay for several workspaces with one bill, one limit and one set of terms. Each has its workspaces (add or remove them), combined usage, terms, credits, ledger and audit log.

Billing's internal account ids (ws_<slug> for a workspace's own, ent_… for an enterprise) are never shown as names; an enterprise's id appears only as small "Billing account id" text. Old /accounts/… links redirect to the workspace or enterprise they meant.

Cards stay on Stripe. sudo never shows a card field. To help a customer update their card or see invoices, staff make a Stripe billing link on the workspace's page (it is recorded) and send it to the owner.

It holds no data. Workspaces, owners and members come from identity's staff methods (admin_workspaces, admin_workspace; IdentityAdminApi in packages/contracts/src/identity.ts); everything about money goes to the billing service's (admin_*, BillingAdminApi in packages/contracts/src/billing.ts), where each change is recorded with the staff member's email. Both are reached over service bindings only, and nothing but sudo binds to them.

How it is locked

1. Cloudflare Access sits in front of sudo.g1t.sh and signs people in.
2. The worker checks Access's work on every request, the stylesheet included (run_worker_first): it verifies the Cf-Access-Jwt-Assertion JWT itself (RS256 against the team's published keys, audience, issuer, expiry), then requires its email to be in STAFF_EMAILS. That email is who every change is recorded as. See app/lib/access.ts.
3. It fails closed. Until ACCESS_TEAM_DOMAIN, ACCESS_AUD and STAFF_EMAILS are all set, every request gets a 403 saying sudo is not configured.
4. Changes are POSTs only, and only from sudo's own pages (Origin, or Referer, must be https://sudo.g1t.sh). Terms, enterprise moves, new enterprises and Stripe billing links show a confirmation step first; a credit needs the workspace's slug typed out.
5. The pages ship no JavaScript. The content security policy forbids every script and inline style; responses are no-store, noindex and cannot be framed. The worker has no workers.dev address or preview URLs.

Setting up Access (once, in the Cloudflare dashboard)

1. Zero Trust → Access → Applications → Add an application → Self-hosted.

   • Application name: sudo.
   • Session duration: short, such as 8 hours.
   • Public hostname: sudo.g1t.sh (path empty, so it covers everything).

2. Add a policy (g1t staff): action Allow, include Emails → the owner's address, and Emails ending in → g1t.sh for everyone with a g1t address (the same entries as STAFF_EMAILS, where a domain is written @g1t.sh). Add more staff here and in STAFF_EMAILS; either one alone is not enough.

3. Save, then open the application's Overview (or Basic information) and copy the Application Audience (AUD) tag.

4. Find the team domain under Zero Trust → Settings → Custom pages (or Team name and domain): it looks like <team>.cloudflareaccess.com.

5. Put both into wrangler.jsonc:

   "vars": {
     "ACCESS_TEAM_DOMAIN": "<team>.cloudflareaccess.com",
     "ACCESS_AUD": "<the AUD tag>",
     "STAFF_EMAILS": "syntaqx@gmail.com, @g1t.sh"
   }

   jsonc

6. Deploy: scripts/deploy.sh sudo (after billing and identity, whose admin_* methods it calls).

Visit https://sudo.g1t.sh: Access asks you to sign in, then the workspaces list opens. Anyone else gets Access's own refusal; anyone Access lets in who is not in STAFF_EMAILS gets a 403 from the worker.

Signing in through WARP

Staff signed in to the Zero Trust org in the Cloudflare One agent (WARP) reach sudo without the login page: the org allows WARP sessions as Access sign-ins (8 hours), the sudo app accepts them, and the g1t staff policy is also on the WARP enrollment app, so staff can enroll their devices. The same two checks still apply: the Access policy, and STAFF_EMAILS.

Working on it

npm run typecheck -w @g1t/sudo
npm test -w @g1t/sudo     # JWT verification, forms, money, the workspace join
npm run build -w @g1t/sudo

npm run dev serves the pages, but every request is refused without a real Access token, by design.