Deploy the managed cloud to Cloudflare with Alchemy (Workers, Containers, host tunnels)

[michaelshimeles]

What

Everything that can run on Cloudflare now does, declared in apps/web/alchemy.run.ts:

• Site: SvelteKit on Workers via Alchemy. Vercel adapter, analytics and deploy path removed. prod owns the custom domain (www redirect), Web Analytics, and the R2 artifact bucket.
• Control plane + gateway: Cloudflare Containers, each owned by a Durable Object behind one edge Worker (apps/web/edge/worker.ts) that fronts api., gateway. and the preview wildcard. The Worker signs each caller's address for the control plane (same HMAC the gateway uses) and passes through a valid gateway signature, so admission sees end users, not the Worker runtime. The gateway trusts CF-Connecting-IP from the edge.
• Hosts (ADR 0005, docs/nehemiah/adr/0005-cloudflare-containers-and-host-tunnels.md): keep their WireGuard address as identity; reached through a per-host Cloudflare Tunnel at <address label>.<host tunnel domain> (10.64.0.7 → 10-64-0-7.hosts.…) behind a Cloudflare Access service token. Selected by NEHEMIAH_HOST_TRANSPORT / NEHEMIAH_GATEWAY_HOST_TRANSPORT; overlay remains the default so ADR 0002 deployments are unchanged. nehemiahd can present an Access token toward the control plane's /internal routes.
• Dockerfiles for both services; .github/workflows/deploy-cloudflare.yml deploys prod on main and pr-<n> site previews.

Verified

• go vet + go test green for gateway/ and nehemiahd/; repo-wide check, lint, test green (all workspaces).
• Both container images build (linux/amd64) and start under the exact production env the stack sets; the control plane proceeds to the database connection, the gateway listens.
• Deployed stage live (site only) to the Goshen Labs account: https://boring-computers-website-live-n4ughwik5hat5bf5.michaelwasihun96.workers.dev

Not yet deployable: prod

• boringcomputers.com is not a zone in the Goshen Labs Cloudflare account.
• The available OAuth login lacks DNS, R2, Access and Web Analytics scopes; the runbook lists the API token permissions needed.
• Production secrets (Postgres with sslmode=verify-full, Clerk, OTel, gateway credentials) must be provided as CI secrets/variables.
• A wildcard below the apex (*.hosts.<site>, *.<preview domain>) needs Advanced Certificate Manager or its own zone.

Made with Cursor

[greptile-apps]

Confidence Score: 2/5

Not safe to merge: production secrets can be exposed to pull-request code, and deployed host tunnels will fail to start.

Findings

1.   Protect Production Secrets ▶
2.  Grant Tunnel Credential Access ▶

Fix with agent prompt

### Issue 1
.github/workflows/deploy-cloudflare.yml:66-103
Same-repository pull requests can execute branch-controlled dependency and deployment code while production Cloudflare and application secrets are present in the job environment. The workflow permits same-repository PRs, checks out their merge commit, runs dependency lifecycle code, and invokes the checked-out deployment script with Cloudflare credentials and additional application secrets. A contributor or compromised branch could disclose those credentials or use them to alter production infrastructure. Use isolated preview credentials for pull requests, or require an approval-protected deployment that runs only reviewed, protected code.

**How this was verified:** The checked-out pull-request code path and its injected production secret environment were confirmed by an executed configuration check.

### Issue 2
infra/cloudflare/cloudflared.service:36-40
The installation commands create `/etc/cloudflared` as `root:root` with mode `0750` and the tunnel credential as `root:root` with mode `0600`, but the service runs as an unrelated transient identity through `DynamicUser=yes`. That identity cannot traverse the configuration directory or read the credentials, so cloudflared cannot start the configured tunnel. The service will repeatedly restart and the control plane and gateway cannot reach the host.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

• Pull-request deployment code can access production Cloudflare and application secrets.
• The cloudflared service cannot access its tunnel configuration or credentials under its configured service identity.
• These failures must be resolved before merging.

_{Reviews (1) · Last reviewed commit: "docs(cloudflare): runbook for containers..."}

[greptile-apps]

Protect Production Secrets

Same-repository pull requests can execute branch-controlled dependency and deployment code while production Cloudflare and application secrets are present in the job environment. The workflow permits same-repository PRs, checks out their merge commit, runs dependency lifecycle code, and invokes the checked-out deployment script with Cloudflare credentials and additional application secrets. A contributor or compromised branch could disclose those credentials or use them to alter production infrastructure. Use isolated preview credentials for pull requests, or require an approval-protected deployment that runs only reviewed, protected code.

How this was verified: The checked-out pull-request code path and its injected production secret environment were confirmed by an executed configuration check.

Artifacts

Evidence from the check

• The executed shell script reads the selected Git revision and asserts the PR trigger, same-repository gate, unchecked checkout ref, executable deploy path, and injected Cloudflare credentials; it shows the vulnerable source configuration.

Command output from the check

• Captured output from executing the supplied check against `HEAD^` (37ce7a8), exiting 0 and showing the same PR-controlled deployment path with injected secrets.

Command output from the check

• Captured output from executing the supplied check against `HEAD` (5444898), exiting 0 and showing the same PR-controlled deployment path with injected secrets.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/deploy-cloudflare.yml
Line: 66-103

Comment:
**Protect Production Secrets**

Same-repository pull requests can execute branch-controlled dependency and deployment code while production Cloudflare and application secrets are present in the job environment. The workflow permits same-repository PRs, checks out their merge commit, runs dependency lifecycle code, and invokes the checked-out deployment script with Cloudflare credentials and additional application secrets. A contributor or compromised branch could disclose those credentials or use them to alter production infrastructure. Use isolated preview credentials for pull requests, or require an approval-protected deployment that runs only reviewed, protected code.

**How this was verified:** The checked-out pull-request code path and its injected production secret environment were confirmed by an executed configuration check.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Grant Tunnel Credential Access

The installation commands create /etc/cloudflared as root:root with mode 0750 and the tunnel credential as root:root with mode 0600, but the service runs as an unrelated transient identity through DynamicUser=yes. That identity cannot traverse the configuration directory or read the credentials, so cloudflared cannot start the configured tunnel. The service will repeatedly restart and the control plane and gateway cannot reach the host.

Knowledge Base Used: Host runtime and virtual machine service

Artifacts

Evidence from the check

• The executed shell script creates the documented root-owned modes and compares root access with an unprivileged DynamicUser analogue, demonstrating the permission boundary.

Command output from the check

• Captured numbered service lines show the root-only installation modes, configured credential path, ExecStart path, and DynamicUser setting under test.

Command output from the check

• The executed script shows root can read both files while the unprivileged analogue receives Permission denied for config and credentials, confirming the service identity cannot access them.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: infra/cloudflare/cloudflared.service
Line: 36-40

Comment:
**Grant Tunnel Credential Access**

The installation commands create `/etc/cloudflared` as `root:root` with mode `0750` and the tunnel credential as `root:root` with mode `0600`, but the service runs as an unrelated transient identity through `DynamicUser=yes`. That identity cannot traverse the configuration directory or read the credentials, so cloudflared cannot start the configured tunnel. The service will repeatedly restart and the control plane and gateway cannot reach the host.

**Knowledge Base Used:** [Host runtime and virtual machine service](https://app.greptile.com/goshen-labs/-/custom-context/knowledge-base/boringcomputers/nehemiah/-/docs/host-runtime.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•  Same-repository PR code runs with Cloudflare and application secrets ▶

  • Bug
    • A same-repository PR that changes a permitted path can trigger the deploy job. The job admits that PR at lines 45-48, checks out its PR merge commit at line 51, runs npm ci at line 56, and runs the checked-out web deploy script at line 67. The same process environment contains CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID at lines 69-70, plus the application/deployment secrets at lines 96-103. Thus a contributor who can create a branch in the repository can alter package lifecycle scripts, the web deploy script, or deployment/build inputs and exfiltrate credentials before or during deploy.
  • Cause
    • The pull_request workflow deliberately permits same-repository heads but combines their checked-out code with repository secrets. The fork-only restriction does not protect against untrusted or compromised same-repository contributors/branches.
  • Fix
    • Do not expose production/deployment secrets while executing PR-controlled code. Split preview deployment into an unprivileged PR workflow using a least-privilege preview-only Cloudflare credential, or require trusted post-merge/manual deployment from protected code. If secrets are indispensable, check out only a reviewed protected ref and do not execute any PR-provided scripts or dependencies.

•  DynamicUser cannot traverse or read cloudflared configuration and credentials ▶

  • Bug
    • The installation instructions create /etc/cloudflared as root:root mode 0750 and credentials.json as root:root mode 0600, but the unit runs with DynamicUser=yes. A focused execution reproduced that an unprivileged service identity cannot open either the config path (directory traversal denied) or credential path (traversal/read denied), so cloudflared cannot load its configured tunnel credentials and will exit; Restart=on-failure then causes restart attempts.
  • Cause
    • The unit has no fixed service user or supplementary group matching the root-owned directory, and DynamicUser assigns a transient non-root identity. The directory grants execute only to root and root group, while the credential grants read only to root.
  • Fix
    • Provision the files for the service identity instead: use a persistent User=cloudflared/Group=cloudflared with the directory and credentials owned/readable by that account, or retain DynamicUser=yes and use systemd-managed credentials/state mechanisms that make the credential available to the dynamic identity with appropriately restricted permissions. Ensure the config directory is traversable by that identity.