[Graphite MQ] Draft PR GROUP:spec_87443f (PRs 3773)

[graphite-app]

This draft PR was created by the Graphite merge queue.
Trunk will be fast forwarded to the HEAD of this PR when CI passes, and the original PRs will be closed.

The following PRs are included in this draft PR:

• #3773

[railway-app]

This PR was not deployed automatically as @graphite-app[bot] does not have access to the Railway project.

In order to get automatic PR deploys, please add @graphite-app[bot] to your workspace on Railway.

[railway-app]

This PR was not deployed automatically as @graphite-app[bot] does not have access to the Railway project.

In order to get automatic PR deploys, please add @graphite-app[bot] to your workspace on Railway.

[claude]

PR Review: Cloud Staging Deployment

This PR adds a new Docker-based deployment configuration for the cloud staging environment. The changes are well-structured and follow the existing patterns in the repository.

Positive Aspects

1. Consistent with existing patterns: The new cloud-staging.Dockerfile closely mirrors the production cloud.Dockerfile, which is excellent for maintainability
2. Proper multi-stage build: Uses builder pattern to minimize final image size
3. Railway configuration: The railway.cloud-staging.toml follows the same structure as railway.cloud.toml
4. Runtime env var substitution: Correctly leverages the existing docker-entrypoint.sh for dynamic configuration
5. Build caching: Uses BuildKit cache mounts for pnpm store and turbo cache to speed up builds

Observations & Minor Considerations

1. Cache ID Differs from Production

The cache IDs in the new staging Dockerfile are different from production:

• Staging: s/6fcfa400-4a51-4df5-9345-2918f7aca8b7-/pnpm/store
• Production: s/47975eb7-74fd-4043-a505-62b995ff5718-/pnpm/store

Analysis: This appears intentional to isolate caches between environments. This is generally a reasonable approach, though it means staging and production won't share cache layers. If cache isolation is intentional, this is fine. If you want cache sharing for faster builds, consider using the same cache ID.

2. Default DEPLOYMENT_TYPE

Both Dockerfiles set ARG DEPLOYMENT_TYPE="staging" as the default.

Question: Should cloud.Dockerfile default to "production" instead? Or is this value always overridden at build time? If the latter, this is fine; otherwise, production deployments might accidentally use staging as the deployment type.

3. File Duplication

The new Dockerfile is 100 lines and nearly identical to cloud.Dockerfile. This is expected for Dockerfiles since they don't support inheritance well, but it does mean maintenance burden if changes are needed (you'll need to update both).

Suggestion: Consider adding a comment at the top of both files referencing each other, so future maintainers know to keep them in sync.

Security

No security concerns identified:

• Uses official base images (node:22-alpine, caddy:alpine)
• No hardcoded secrets
• Proper security headers configured in Caddyfile
• Runtime env var substitution prevents secrets in built artifacts

Performance

Well-optimized:

• Multi-stage builds minimize final image size
• BuildKit cache mounts for dependencies and build artifacts
• Static asset caching with max-age=31536000
• Gzip compression enabled

Testing

No test changes included: This PR only adds infrastructure files. Verify that:

1. The staging deployment builds successfully on Railway
2. Runtime env var substitution works correctly
3. Health check endpoint returns 200

Code Quality

Clean and well-documented:

• Clear comments explaining each section
• Follows existing conventions
• Proper file organization

---

Recommendation: LGTM with minor questions

The PR is ready to merge. The questions above about cache IDs and deployment type defaults are worth clarifying but don't block merging if they're intentional design decisions.