Private docs access and team secrets

Private Antora / internal docs (online, no VPN)

Antora output is static HTML. Access control is always at the edge or identity proxy, not inside Antora.

Multi-playbook (public site vs private site) is out for FTN: one online docs experience is preferred.

Option Tradeoffs Fit for FTN

Vercel / Cloudflare edge auth (Basic Auth or simple JWT gate on path prefixes)

Cheap to start; Basic Auth is coarse (shared password or per-user list). Edge middleware on Vercel Hobby has limits; Pro/team is fine for org docs. Pulumi can own the project + env. No rich roles unless you build them.

Good first step — protect /internal/** (or a dedicated internal hostname) with edge middleware + secrets from ESC.

OIDC reverse proxy (OAuth2 Proxy, Authentik, Clerk/Auth0/WorkOS in front of static host)

Most “official” for coworkers: Google Workspace / org IdP login, groups → who sees what. More moving parts (IdP app, callback URLs, session cookies). Best long-term if docs stay sensitive.

Best end state when Google Workspace for foodtrucknerdz.com is solid.

VPN / private network only

No public URL; high friction for coworkers.

Rejected for FTN.
Recommendation

Ship edge gate on Vercel (or Cloudflare in front of Pages) for internal components now; plan OIDC when Workspace SSO is painless. Pulumi infra can own DNS + the auth wiring; Bitwarden/ESC holds the shared Basic Auth secret or OIDC client secret.

Vault hosting (Bitwarden vs Vaultwarden)

FTN currently uses Bitwarden (cloud) as the human-readable source of truth for API keys and custom fields. If we ever self-host:

Do not treat GitHub org secrets or Vercel env alone as the filing cabinet — see below.

Linear (FTN)

Inbound email for creating issues (team-private):

foodtrucknerdz-d5625360e1d9@linear.app

Stored as Bitwarden custom field FTN Linear inbound email on the linear.app / ryan@foodtrucknerdz.com item, and as env FTN_LINEAR_INBOUND_EMAIL on Vercel (non-secret operational address).

GitHub Organization secrets?

  • Can Actions use them? Yes — that is what they are for.

  • Can humans read them back after save? No useful “reveal” in the UI; you overwrite, you do not browse. Fine for deploy keys CI needs; bad as a filing cabinet you will reopen later.

  • Should Square/Resend/etc. live only there? No. Keep Bitwarden (+ future ESC) as the readable source of truth; optionally also mirror CI-only values into GitHub Actions secrets.

Customer.io key soup

| Key | Typical use | |-----|-------------| | Tracking API Key | Client/server event tracking (identify / track) — often what app SDKs want. | | App API Key | Server App API (more privileged account/workspace operations). We stored FTN App API Key. | | Pipelines API Key | Separate Pipelines/CDP-style ingest; different UI. “Complete Setup” curl is optional theater if the key already works. |

Missing Tracking key in Bitwarden is OK until we wire browser/server analytics; App + Pipeline keys are enough to start backend experiments. Test mode is fine.

Follow-ups

  • Paste Square OAuth redirect URIs in Developer Console (Sandbox + Production) — see Square credentials.

  • Google Client ID + Facebook OAuth (reminders emailed to Ryan).

  • Yoti production after business verification; sandbox keys already distributed.

  • Stripe live keys when leaving sandbox.

  • Private docs edge gate in Pulumi when ready.