You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Walkthrough

Restructured deployment docs: README now links to Docker and Heroku guides and troubleshooting; added a new Docker deployment guide; removed legacy Capistrano and Elastic Beanstalk pages; added a link-checker exclusion; updated two NEWS.md doc URLs.

Changes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 I nibbled through docs with careful hops and cheer,
Cleared old deployment trails and welcomed Docker near.
Links tidied, flaky URL tucked away,
News pointed forward, README lights the way.
Hop on, tiny docs — the burrow's neat today! 🥕

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR adds a comprehensive Docker deployment guide (docs/oss/deployment/docker-deployment.md) for React on Rails, covering multi-stage Dockerfiles, Kamal, Kubernetes, and Control Plane deployments, along with a Pro Node Renderer sidecar pattern and troubleshooting tips. The docs/oss/deployment/README.md is also updated with a structured index linking all deployment and troubleshooting guides. The documentation is well-structured and covers the right topics, but contains two factual errors that would cause confusion for users following the guide.

Key findings:

• cpflow command is incorrect: The Control Plane Deploy section shows cpflow deploy-image -a myapp with the comment # build + push image, but cpflow deploy-image only deploys an already-built image — it does not build or push. The missing cpflow build-image step means users would deploy a stale image without realizing it.
• Wrong environment variable for Node Renderer URL: The Kubernetes sidecar example sets REACT_ON_RAILS_PRO_NODE_RENDERER_URL, but React on Rails Pro reads ENV["RENDERER_URL"] for the config.renderer_url setting. The custom var name will be silently ignored, leaving the connection pointing to the default http://localhost:3800.
• node_modules in runtime image: The broad COPY --from=build /rails /rails in the runtime stage inadvertently includes node_modules from the build stage, adding unnecessary size to the production image. This is a P2 optimization suggestion.
• The docs/oss/deployment/README.md changes are clean — all linked files exist in the repository.

Confidence Score: 3/5

• The guide is documentation-only, but two factual errors (wrong cpflow command description and wrong env var name) would actively mislead users following the guide in production deployments.
• Both P1 issues involve incorrect technical information that would cause real operational problems: the cpflow section omits the required build-image step entirely, and the env var name for the Node Renderer URL doesn't match what the gem actually reads. These are not ambiguous edge cases — a user following the guide precisely would either deploy a stale image (cpflow) or have SSR silently falling back to ExecJS (wrong env var). Fixing both P1 issues plus the P2 node_modules note brings this to a clean merge.
• docs/oss/deployment/docker-deployment.md — specifically the Control Plane deploy commands (lines 376-378) and the Kubernetes Node Renderer env var (line 298-299)

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[docker build] --> B[Base stage\nruby:slim, ENV vars]
    B --> C[Build stage]
    C --> D[Install build deps\napt-get: build-essential, node-gyp]
    D --> E[Install Node.js via nodesource\n+ corepack enable]
    E --> F[bundle install\nRuby gems]
    F --> G[yarn install --frozen-lockfile\nJS dependencies]
    G --> H[COPY . .\nFull application]
    H --> I[assets:precompile\nBuilds client + server bundles]
    I --> |public/webpack/production/\nssr-generated/| J[Runtime stage\nFROM base — no Node]
    J --> K[apt-get: curl libpq5 only]
    K --> L[COPY gems from build\n/usr/local/bundle]
    L --> M[COPY app from build\n/rails — includes node_modules⚠️]
    M --> N[Create non-root user\nrails:1000]
    N --> O[ENTRYPOINT + CMD\npuma -C config/puma.rb]

    style I fill:#90EE90
    style M fill:#FFD700

_{Reviews (1): Last reviewed commit: "Add Docker deployment guide for Kamal, K..." | Re-trigger Greptile}

Review: Docker Deployment Guide - solid addition overall. Six issues flagged via inline comments: (1) COPY --from=build /rails /rails inflates runtime image with full source tree - line 72; (2) --frozen-lockfile is Yarn v1, Yarn Berry uses --immutable - line 52; (3) pnpm@latest is non-deterministic, pin the version - line 99; (4) misleading K8s Secrets tip since the manifest already uses secretKeyRef correctly - line 263; (5) :latest tag is an anti-pattern in K8s manifests - lines 186 and 383; (6) curl-pipe-bash nodesource install lacks a supply-chain security note - line 40. Minor: missing namespace in K8s manifest, docker-entrypoint requires Rails 7.1+, ssr-generated/ path is Pro-specific.

Review summary

Good addition - Docker deployment docs are genuinely missing from the project. A few issues to fix before merging.

Blocking

1. Broken archived-guide links (README.md lines 20-21): The commit SHAs b3d30a15c and a5312aeb6 do not exist in this repository. Both files were last present in commit 0c8fc56623cd2cf404a6bda43a3769e1d0e1aafb. Inline suggestions have been posted.

2. Wrong Node Renderer env var (docker-deployment.md lines 376-377): REACT_ON_RAILS_PRO_NODE_RENDERER_URL does not appear anywhere in the codebase. The Rails Pro config API uses config.renderer_url, typically sourced from ENV["REACT_RENDERER_URL"] (see docs/oss/building-features/node-renderer/basics.md line 95). Using the wrong env var means the sidecar connection silently falls back to localhost:3800 with no obvious error.

3. Incorrect cpflow commands (docker-deployment.md line 350): cpflow deploy-image deploys an already-built image; it does not build one. The build step is cpflow build-image. Inline suggestion posted.

Non-blocking

4. Missing security caveat for host: 0.0.0.0 (docker-deployment.md line 400): The js-configuration.md warns that binding to all interfaces is a security risk. This guide should repeat that caveat since the example YAML is easy to copy verbatim.

5. --frozen-lockfile vs --immutable (docker-deployment.md line 52): --frozen-lockfile is Yarn Classic only; Yarn Berry uses --immutable. Since the Dockerfile enables corepack right above this line, Berry is a realistic scenario. Inline suggestion posted.

6. README missing two existing troubleshooting files: troubleshooting-when-using-shakapacker.md and troubleshooting-when-using-webpacker.md exist in the same directory but are not linked from the new README index. Worth either linking them or explicitly noting as archived so they are not orphaned.

Good documentation addition overall — the multi-stage Dockerfile, Kamal/K8s/Control Plane examples, and Node Renderer sidecar patterns are all useful. A few issues worth addressing:

Critical

• The Node Renderer sidecar example uses your-registry/myapp:latest (the Ruby runtime image), but that image has no node binary and no node_modules. The text correctly states "the runtime image needs Node.js" but doesn't show how to provide it. The sidecar container as written would crash at startup. This section needs either a separate Node-capable image or a variant Dockerfile that keeps Node.js in the runtime stage.

Notable

• yarn install --frozen-lockfile is Yarn 1.x / 3.x syntax. If users follow the guide and corepack enable activates Yarn 4 (the current default), the flag is silently ignored on some versions or rejected on others. Yarn 4 uses --immutable. Since the guide enables corepack, it should account for this.
• corepack prepare pnpm@latest --activate is non-deterministic — using latest means different builds can pull different pnpm versions. Pin a specific version (e.g. [email protected]).

Minor

• The K8s resource limits (memory: 512Mi) are probably too low for pods doing ExecJS/mini_racer SSR. A note suggesting users tune this (or a higher example value like 1Gi) would help avoid OOM kills in production.
• The node-gyp apt package is the Debian wrapper, not the npm package. Once Node.js is installed from nodesource, npm-installed node-gyp (pulled in by native addons) is what actually runs. The apt node-gyp package may conflict or shadow the npm version — worth checking if it's needed here.

Review: Docker Deployment Guide

Overall this is a solid, well-organized addition with good security practices (non-root user, secrets via secretKeyRef). A few issues worth addressing:

Issue 1 - curl-pipe-bash in the Dockerfile (security): The Node.js install step uses curl piped to bash, which executes remotely fetched code directly and is a well-known supply-chain risk. Consider explicit APT pinning or switching to a Node base image for the build stage. At minimum, add a note acknowledging the trade-off.

Issue 2 - livenessProbe.initialDelaySeconds 15 is too short for Rails: Puma with Rails + React on Rails commonly takes 30-60 s to start on a cold deploy. A liveness probe firing at 15 s will restart the pod before it is ready, creating a crash loop. Recommend at least 60 s, or suggest startupProbe (Kubernetes 1.18+).

Issue 3 - Memory limit of 512 Mi is borderline for SSR workloads: limits.memory 512Mi will cause OOM kills for many real-world apps doing server-side rendering. The guide should note this is a minimal starting point and suggest 1-2 Gi for SSR-enabled apps.

Issue 4 - ssr-generated/ path is React on Rails Pro-specific: The Key points section says server bundles land in ssr-generated/. This is specific to the Pro Node Renderer, not the default ExecJS/mini_racer path. OSS users will be confused. Should be qualified with (React on Rails Pro only) or replaced with the OSS-accurate output path.

Issue 5 - Missing .dockerignore guidance: The COPY . . step will silently include .git/, node_modules/, log/, tmp/, and local .env files without a .dockerignore. Worth a brief note since this affects build performance and potential secrets exposure.

Minor nits: The Kamal config/deploy.yml uses 192.168.0.1 as a placeholder server IP (a private RFC1918 address). 203.0.113.1 (TEST-NET-3, reserved for documentation) would be clearer. Archived-guide commit SHAs in README are partial (9 chars); full 40-char SHAs are more stable for long-term permalink links.

The issues above are all actionable and worth fixing before merge.

Review: Docker Deployment Guide

Overall this is a well-structured, thorough guide that fills a real gap in the docs. The multi-stage Dockerfile design is correct (Node only at build time, lean runtime image, non-root user, --immutable lockfile install), the Kubernetes manifest follows current best practices (secretKeyRef, readiness/liveness probes, init container migration warning), and removing the stale Capistrano/Elastic Beanstalk guides is the right call.

A few things worth addressing before merge:

Correctness / usability

• README.md intro: The first sentence about Shakapacker is a leftover from the old file and no longer fits the index format. (Inline comment added.)
• ExecJS SSR troubleshooting: The suggestion to install mini_racer or add node to the runtime PATH conflicts with the guide's own multi-stage design — the runtime image is deliberately Node-free and uses the Ruby slim base, which lacks build tools for mini_racer. Worth being explicit about the tradeoff. (Inline comment added.)
• node-renderer.js command: The origin/purpose of this file is opaque to readers new to the Pro Node Renderer; a short cross-reference would help. (Inline comment added.)

Reproducibility

• Image version pinning: Defaulting to RUBY_VERSION=3.3 and NODE_VERSION=20 means the base image can silently change between CI runs. Pinning to patch versions (e.g. 3.3.7, 20.19.0) is standard practice for production Dockerfiles. (Inline comment with suggestion added.)

Minor nits (no blocking issues)

• docker exec <container> in the troubleshooting section uses angle-bracket placeholders that can render oddly depending on the Markdown renderer — backtick-quoting the placeholder (<container-id>) would be safer.
• The .dockerignore example is intentionally minimal, but .bundle/ and .env* are worth calling out explicitly since they're common sources of secrets accidentally leaking into image layers.
• Control Plane workload template is missing a scale block — the defaults are fine for a getting-started guide, but readers trying to run zero-downtime deployments will need it. Even a comment noting this would help.

Review: Docker Deployment Guide

Overall this is a well-structured, comprehensive doc addition. The multi-stage Dockerfile, deployment patterns (Kamal/K8s/Control Plane), and troubleshooting sections are solid. A few accuracy and security issues worth addressing:

1. NodeSource curl-pipe-bash installer (security)

The build stage installs Node by piping a remote script directly into bash. This is a supply-chain risk. For production Dockerfiles, consider using the official node Docker base image in a separate stage, or verify the script checksum. At minimum, add a note acknowledging this trade-off.

2. Kamal arch: amd64 hardcodes x86_64

The Kamal config example includes builder.arch: amd64. This silently breaks for developers on Apple Silicon who run kamal deploy locally. The doc should note that amd64 targets Linux servers specifically and point to multi-arch builds if needed.

3. Asset path public/webpack/production/ is bundler-specific

The Troubleshooting section references public/webpack/production/ as the client bundle output path. This is correct for Shakapacker/Webpacker but differs for Rspack projects (varies by output_path config). Suggest phrasing it as the configured public_output_path (defaults to public/webpack/production/) so readers know to adjust.

4. ssr-generated/ description could be clearer

The guide says server bundles land in ssr-generated/. That is the default for Shakapacker private_output_path but is configurable. A parenthetical like "(the default private_output_path; adjust to match your bundler config)" would help.

Minor: The pnpm section pins pnpm@9 in corepack prepare pnpm@9 --activate. The inline comment says to pin to your major version, but readers may copy it verbatim. A suggestion to match the version in packageManager in package.json would help.

Review: Docker Deployment Guide

Good addition overall. Well-structured, covers the key deployment targets (Kamal, Kubernetes, Control Plane), and the React on Rails-specific callouts (SSR bundle path, Node Renderer sidecar, SECRET_KEY_BASE_DUMMY) are accurate against the codebase.

I left five inline comments with specific fixable issues.

1. Missing mkdir -p before chown (line 80) — log/, tmp/, storage/ are gitignored and typically absent from the image after the multi-stage copy. The chown command will fail. Rails 7.1's own default Dockerfile uses mkdir -p first.

2. COPY . . silently overwrites node_modules (line 55) — without a .dockerignore excluding node_modules, the host's native modules overwrite the container-built ones, causing hard-to-diagnose runtime crashes. This is covered in Key Points, but a comment inline in the Dockerfile would catch it before someone skips ahead.

3. Wrong node-renderer.js path (line 413) — the generator places the file at client/node-renderer.js (per pro_setup.rb); the command as written will error unless the container working directory happens to be client/.

4. pnpm@9 hardcoded (line 113) — silently ignores the packageManager version in package.json; projects on pnpm v8 or v10 get the wrong version installed.

5. :latest tag in Kubernetes manifest (line 222) — using :latest in production prevents reliable rollbacks and makes it impossible to audit exactly what is deployed. Recommend a versioned tag placeholder.

Minor (not blocking): The archived git links in README.md use 9-char abbreviated commit hashes — full 40-char SHAs are more future-proof. The Kamal example sets memory: 512m on the web container, which is tight for a Rails + SSR app; a note about typical runtime memory needs would help users avoid OOM kills in production.