zgbrenner writes the manual for self-hosting Gary

A new deployment guide spells out exactly how to stand up this fork yourself - and where the usual shortcuts break.

infrastructuresecurity

Most teams kicking the tyres on a legal-AI tool eventually ask the same question: can we actually run this ourselves? zgbrenner just answered it with a plain-English deployment guide. The catch it documents is worth knowing up front - Gary's engine does real work like converting Word documents to PDF and handling uploads, which means it needs a proper always-on server. You can't squeeze it onto the cheap, on-demand hosting that suits a simple website; only the user-facing front end can live there.

The guide also draws a hard line around secrets. Anything baked into the part of the app that runs in the browser is visible to anyone, so signing keys and database credentials stay on the server side. Obvious to a web developer, easy to get wrong if you're not - and getting it wrong leaks credentials.

So what Anyone weighing whether to self-host Gary now has a clear map of what it takes and where the landmines are.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from zgbrenner/gary, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
80791bc7 Merge pull request #4 from foolish-bandit/claude/gary-us-simplification-AjDDT Zack Brenner 2026-05-19 ↗ GitHub
0b6ee888 docs: add Vercel deployment path and clarify Supabase env errors Claude 2026-05-19 ↗ GitHub
commit body
Prepare Gary for a simple one-person Vercel deployment. Documentation
and a clearer missing-env error - no product features, no Clerk, no
database migration, no Cloudflare changes.

- Add docs/VERCEL_DEPLOYMENT.md: plain-English guide covering what
  Vercel hosts (the Next.js frontend only), what Supabase handles,
  why the Express backend stays separate (needs LibreOffice and a
  long-running server), required public vs private environment
  variables, GitHub import steps, project settings (Root Directory =
  frontend, default build/output), preview deployments, custom
  domains, troubleshooting, and a "Future Clerk login" note.
- Add frontend/.env.vercel.example: public NEXT_PUBLIC_* values
  separated from server-side secrets, with explicit warnings never to
  put provider / Supabase service-role / database / JWT / Clerk
  secrets in NEXT_PUBLIC_* variables. Includes a clearly-labeled
  future-only Clerk section.
- supabase.ts and auth.ts: replace the cryptic "supabaseUrl is
  required" failure with a clear message naming the missing variable
  (NEXT_PUBLIC_SUPABASE_URL / NEXT_PUBLIC_SUPABASE_ANON_KEY) and
  where to set it. Also accept the standard
  NEXT_PUBLIC_SUPABASE_ANON_KEY name while still falling back to the
  legacy NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY, so existing
  deployments keep working. Runtime safety is unchanged - missing
  config still throws.
- README: add a brief "Deploying Gary on Vercel" section and link the
  new guide; docs index links it too.
- .gitignore: allow .env.vercel.example to be committed.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-535.md from inside the repo you want the changes in.

⬇ Download capture-thread-535.md