Repository navigation
feat: shared backend on Cloud Run with a workshop password - #1
Conversation
- runtime/Dockerfile and ignore files: the image holds only server.ts and env.ts, and a source deploy uploads nothing else (no .env) - deploy_runtime workflow: builds the image, deploys to Cloud Run through Workload Identity and checks that the password gate is on - runtime_ci workflow: typechecks the runtime and builds the image on pull requests - runtime/deploy: one-time Google Cloud setup script and the steps - point tool/workshop.config.json at the deployed backend
- the runtime, the step 03 server, setup and doctor read CLAUDE_API_KEY and hand it to the Anthropic SDK as ANTHROPIC_API_KEY - the deploy workflow passes the CLAUDE_API_KEY repository secret to Cloud Run - update the examples, the README and the deploy steps
Statyk7
left a comment
Statyk7
left a comment
There was a problem hiding this comment.
Thanks for this Pietro, the design is solid: Workload Identity with no key file and a repo + main condition, a runtime service account with no roles, .env kept out of the image, a smoke test that asserts the 401, a constant-time comparison, and local runtimes unchanged.
Tested on this branch: runtime typecheck passes; Flutter analyze and app tests pass in steps 01 to 03; password gate on a local copy (/info 200 without a code, run without or with a wrong code 401, right code passes, stop without a code 401, preflight 204); runtime_ci passes; the deployed /info answers 200 with CORS open.
Not tested: the deploy workflow itself (needs the secrets and only runs on main), Safari or Firefox, Windows.
Before merging (details inline):
setup.mjscan print the password in clear.- Cold start versus the doctor's 8 second timeout.
- The
CLAUDE_API_KEYrename breaks existingANTHROPIC_API_KEYsetups.
Suggestions: spend caps and using the session header, deployer permissions and pinned actions, tests for the gate, checking the password in setup, and the README's PowerShell command. The PR description also still mentions runtime/deploy/README.md, which the last commit removed.
Happy to send a follow-up with these if that helps.
- key: name it ANTHROPIC_API_KEY everywhere again - gate: move the password gate to runtime/gate.ts, log and cap runs per session and in total, and test it with node:test in runtime_ci - setup, doctor: mask the password by argument, check it up front with an empty run, wait longer for a cold hosted backend - deploy: keep the key and password in Secret Manager, give the deployer run.developer and make the service public from setup_gcp.sh, use --cpu-boost, add a warm_runtime workflow - actions: pin to commit SHAs and add Dependabot - docs: one-line flutter run, note that a build made with the password contains it
runtime/deploys to Cloud Run (deploy_runtimeworkflow, Workload Identity, no key file); PRs typecheck it, test the password gate and build the image (runtime_ci). The key and the password live in Secret Manager, and a manualwarm_runtimeworkflow keeps the service awake before an event.X-Workshop-Codeand a randomX-Workshop-Sessionon every run (--dart-define=WORKSHOP_CODE); the runtime checks the code only whenWORKSHOP_CODEis set, so local runtimes are unchanged./infoand the CORS preflight stay open. The gate (runtime/gate.ts) logs each run with its session id and caps runs per session and in total (MAX_RUNS_PER_SESSION,MAX_RUNS_TOTAL).tool/setup.mjsandtool/doctor.mjscheck the password up front with an empty run, and only ask for it when the backend needs one;tool/workshop.config.jsonpoints at the shared backend.ANTHROPIC_API_KEYeverywhere.runtime/deploy/setup_gcp.sh(secrets, deployer role, public access). Run it again after the first deploy.Before merging, add two repo secrets:
GCP_WORKLOAD_IDENTITY_PROVIDERandGCP_SERVICE_ACCOUNT. The oldCLAUDE_API_KEY,ANTHROPIC_API_KEYandWORKSHOP_CODErepo secrets are not used.Tested: the deployed service (401 without the code, streamed model runs,
doctor.mjs), the gate tests, and step 02 in Chrome. Secret Manager and the deployer role are set up in the project, but the workflows themselves have not run yet, and neither have the Flutter tests.