foolish-bandit writes the deployment manual gary was missing

The fork's backend won't run where the rest of the project lives, so foolish-bandit documented exactly where it should run instead - and which keys never leave home.

infrastructuresecurity

Gary's backend leans on things a lightweight serverless host can't provide: it shells out to a desktop office suite to turn Word documents into PDFs, handles file uploads, and talks to cloud storage. foolish-bandit's answer isn't to rewrite any of that - it's a thorough, honest deployment guide pointing the backend at Railway or Render (general-purpose app-hosting platforms), with Railway flagged as the smoother path because the document-conversion dependency is already wired in. The guide even owns up to a naming inconsistency in the config rather than papering over it.

The part worth lingering on is the security boundary. The doc draws a hard line around the credentials that bypass database access controls, the storage keys, and the AI provider keys: those stay on the backend and never get shipped to the public-facing frontend.

So what Anyone planning to actually stand up this fork - or borrow its deployment pattern - gets a tested path and a clear rule for keeping secrets off the client.

View this fork on GitHub →

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

Commits in this thread

6 commits from foolish-bandit/gary, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
d2245301 Merge pull request #4 from foolish-bandit/claude/prepare-backend-deployment-2J0Le Zack Brenner 2026-05-07 ↗ GitHub
Document backend deployment on Railway/Render
014f57ae Merge pull request #5 from foolish-bandit/claude/remove-backend-bun-lockfile Zack Brenner 2026-05-07 ↗ GitHub
Remove backend/bun.lock so hosts use npm
24be1632 Document backend deployment on Railway/Render Claude 2026-05-07 ↗ GitHub
commit body
Adds backend/DEPLOY.md with install/build/start commands, the full
required-vs-secret env var matrix, host-specific (Railway, Render)
steps, frontend wire-up via NEXT_PUBLIC_API_BASE_URL, and a
post-deploy smoke test. Links it from the root README so it is
discoverable next to the existing frontend/Workers section.

https://claude.ai/code/session_019pRkhcGDRKQWHjzAnV5yCL
eac38d95 Remove backend/bun.lock so hosts use npm Claude 2026-05-07 ↗ GitHub
commit body
backend/package-lock.json is the active lockfile and the README + DEPLOY
docs prescribe npm. A stale bun.lock can mislead build detectors (Railway
Nixpacks, Cloudflare, Render) into provisioning Bun, which is exactly the
trap the frontend just hit.

https://claude.ai/code/session_019pRkhcGDRKQWHjzAnV5yCL
d872d0fc prep backend env for railway deploy SONOMOS 2026-05-07 ↗ GitHub
6404ba39 Merge pull request #19 from foolish-bandit/codex/pr-19-railway-backend-deployment-prep Zack Brenner 2026-05-07 ↗ GitHub
Backend deployment prep for Railway

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-157.md from inside the repo you want the changes in.

⬇ Download capture-thread-157.md