shakacode · justin808 · May 3, 2026 · May 4, 2026 · May 4, 2026 · May 4, 2026
diff --git a/docs/oss/building-features/node-renderer/container-deployment.md b/docs/oss/building-features/node-renderer/container-deployment.md
@@ -129,6 +129,91 @@ end
 
 > **Recommendation:** Start with a single container. Move to sidecar containers if you need per-process memory/CPU visibility (e.g., to diagnose OOM restarts). Separate workloads are rarely justified unless you have a specific need for independent scaling at high replica counts.
 
+## Control Plane Deployment Shapes
+
+For Control Plane deployments, choose the probe target based on where the node renderer runs. Control Plane configures
+probes per container. Renderer probe targets below mean `tcpSocket` or h2c-aware `exec` probes, not HTTP/1.1 `httpGet`
+probes directly against the renderer.
+
+[Control Plane Flow](https://github.com/shakacode/control-plane-flow)'s default `rails` template models Rails as a
+single-container standard workload. If you follow that template and run the renderer inside the Rails container,
+configure the Rails workload's probes rather than looking for a separate node-renderer container. If you split the
+renderer into its own container or workload, add renderer-specific probes there.
+
+### Same Rails Container Or Process Supervisor
-### Same Rails Container Or Process Supervisor
+### Same Container (Rails and Renderer Co-Located)
-### Same Rails Container Or Process Supervisor
+### Same Container (Rails and Renderer Co-Located)
+
+Set the Rails `renderer_url` to `http://localhost:3800`. The renderer can keep the default `localhost` host binding.
+Probe the `rails` container's Rails health endpoint, such as `/up` on port `3000` in Rails 7.1+ or a custom endpoint in
+earlier Rails versions.
+
+When Rails and the renderer share one container, use one combined Rails health endpoint if you need to check both
+processes. For example, make the Rails readiness endpoint perform a short TCP connection check to `localhost:3800` and
+return `503` if the renderer is unreachable.
+
+Because this guide covers React on Rails Pro's Node Renderer, the Rails endpoint below reads the same
+`ReactOnRailsPro.configuration.renderer_url` value used for SSR requests rather than requiring a second port environment
+variable.
+
+`config/routes.rb`:
+
+```ruby
+# Override Rails 7.1+'s built-in /up route to add the renderer TCP check.
-# Override Rails 7.1+'s built-in /up route to add the renderer TCP check.
+# Override Rails 7.1+'s built-in /up route to add the renderer TCP check.
+# If you already have a custom /up or are on Rails < 7.1, use a distinct
+# path such as /healthz to avoid silently replacing existing health logic.
+get "up", to: "health#show"
-# Override Rails 7.1+'s built-in /up route to add the renderer TCP check.
+# Override Rails 7.1+'s built-in /up route to add the renderer TCP check.
+# If you already have a custom /up or are on Rails < 7.1, use a distinct
+# path such as /healthz to avoid silently replacing existing health logic.
+get "up", to: "health#show"
+get "up", to: "health#show"
+```
+
+`app/controllers/health_controller.rb`:
+
-
+# Inherits from ActionController::Base (not ApplicationController) to bypass
+# authentication and other application middleware — health endpoints must be
+# reachable before and independent of the app's auth layer.
+class HealthController < ActionController::Base
-
+# Inherits from ActionController::Base (not ApplicationController) to bypass
+# authentication and other application middleware — health endpoints must be
+# reachable before and independent of the app's auth layer.
+class HealthController < ActionController::Base
+```ruby
+# Ruby stdlib; loaded explicitly for the URI/Socket readiness check.
+require "socket"
+require "uri"
+
+# Inherits from ActionController::Base (not ApplicationController) to avoid
+# app-level authentication callbacks on unauthenticated probe requests.
+class HealthController < ActionController::Base
+  def show
+    # Opens and immediately closes; raises if the renderer port is unreachable.
+    # A successful TCP connection means the h2c listener is bound, not that
+    # cluster workers are ready. Pair with the startup probe to shield liveness.
+    # In this same-container topology, Rails and the renderer share a network namespace.
+    # Probe localhost even if other deployment shapes use a service host.
+    # connect_timeout is supported by the Ruby versions in this guide's prerequisites.
+    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
-    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    renderer_port = URI.parse(ENV.fetch('RENDERER_URL', 'http://localhost:3800')).port
-    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    raise URI::InvalidURIError, "renderer_url must include an explicit port (got: #{ReactOnRailsPro.configuration.renderer_url})" if renderer_port == URI::DEFAULT_PARSER.send(:default_port, "http")
-    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    renderer_port = URI.parse(ENV.fetch('RENDERER_URL', 'http://localhost:3800')).port
-    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    raise URI::InvalidURIError, "renderer_url must include an explicit port (got: #{ReactOnRailsPro.configuration.renderer_url})" if renderer_port == URI::DEFAULT_PARSER.send(:default_port, "http")
+    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {}
-    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {}
+    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {} # Same container: localhost is always correct here.
-    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {}
+    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {} # open + immediately close
-    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {}
+    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {} # Same container: localhost is always correct here.
-    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {}
+    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {} # open + immediately close
+    head :ok
+  rescue SocketError, SystemCallError, URI::Error, TypeError
-  rescue SocketError, SystemCallError, URI::Error, TypeError
+  rescue SocketError, SystemCallError, URI::Error, TypeError, ArgumentError
-  rescue SocketError, SystemCallError, URI::Error, TypeError
+  rescue SocketError, SystemCallError, URI::Error, TypeError, ArgumentError
+    head :service_unavailable
+  end
+end
-end
+    # Opens and immediately closes; raises if the renderer port is unreachable.
+    # Note: a successful TCP connection means the h2c listener is bound, not that
+    # cluster workers are ready. Pair with the startup probe to shield liveness.
+    # connect_timeout is supported by the Ruby versions in this guide's prerequisites.
+    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {}
-end
+    # Opens and immediately closes; raises if the renderer port is unreachable.
+    # Note: a successful TCP connection means the h2c listener is bound, not that
+    # cluster workers are ready. Pair with the startup probe to shield liveness.
+    # connect_timeout is supported by the Ruby versions in this guide's prerequisites.
+    renderer_port = URI.parse(ReactOnRailsPro.configuration.renderer_url).port
+    Socket.tcp("localhost", renderer_port, connect_timeout: 1) {}
+```
+
+### Separate Container In The Same Workload
+
+Keep the Rails `renderer_url` as `http://localhost:3800`. Use `0.0.0.0` for the renderer `host` when you rely on
+`tcpSocket` probes; `localhost` is fine for `exec`-only probes.
+
+Add h2c-aware `exec` probes against `localhost:3800` or `tcpSocket` probes on the renderer port. For `tcpSocket`, bind the
+renderer to `0.0.0.0` because Kubernetes and platform TCP probes originate from outside the container and connect to the
+pod or workload IP, not container-local loopback. `exec` probes run a command inside the container, so `localhost` works
+there.
+
+> **Probe YAML:** For Control Plane readiness and liveness fields, reuse the individual `exec` or `tcpSocket` probe blocks
+> from [Kubernetes Sidecar Manifest](#kubernetes-sidecar-manifest). Attach them to the node-renderer container in this
+> workload instead of to a separate Kubernetes pod spec.
+
+### Separate Node-Renderer Workload
+
+Set the Rails `renderer_url` to `http://<WORKLOAD_NAME>.<GVC_NAME>.cpln.local:3800`, use `0.0.0.0` for the renderer
+`host`, and add `tcpSocket` or h2c-aware `exec` probes to the node-renderer workload container. Expose the renderer port
+internally, not publicly, unless required.
+
+Use the same Control Plane probe fields as the same-workload case, but attach them to the separate node-renderer workload
+container.
+
+Replace `<WORKLOAD_NAME>` with the renderer workload name and `<GVC_NAME>` with your Control Plane Global Virtual Cloud
+name. Use your actual renderer port if it is not `3800`; see Control Plane's
+[service-to-service endpoint format](https://docs.controlplane.com/guides/service-to-service).
+
 ## Dockerfile Example
 
 > **Why the renderer entry point lives in a dedicated `renderer/` directory:** Production Docker builds commonly strip JavaScript sources after the client bundles are built, since the Rails app no longer needs them at runtime. Keeping the renderer entry point in its own top-level directory (separate from `client/`) makes it trivial to exclude from that cleanup — the Node Renderer process still needs its entry file and dependencies at runtime.
@@ -208,14 +293,18 @@ services:
       RENDERER_HOST: '0.0.0.0'
       NODE_OPTIONS: '--max-old-space-size=512'
     healthcheck:
-    healthcheck:
+      # Set --max-time roughly 1 s below the orchestrator's probe timeout so curl exits
+      # cleanly with a non-zero code rather than being killed mid-request (2 s here with timeout: 3s).
-    healthcheck:
+      # Set --max-time roughly 1 s below the orchestrator's probe timeout so curl exits
+      # cleanly with a non-zero code rather than being killed mid-request (2 s here with timeout: 3s).
-      test: ['CMD', 'curl', '-sf', '--http2-prior-knowledge', 'http://localhost:3800/info']
+      # --max-time 2 leaves a 1 s buffer below the 3 s orchestrator timeout so curl exits
+      # cleanly with a non-zero code rather than being killed mid-request.
+      test: ['CMD', 'curl', '-sf', '--max-time', '2', '--http2-prior-knowledge', 'http://localhost:3800/info']
       interval: 5s
       timeout: 3s
       retries: 5
       start_period: 10s
 ```
 
 > **Note:** In Docker Compose, the containers do not share a network namespace (unlike Kubernetes sidecars), so the renderer must bind to `0.0.0.0` and Rails must connect via the service name (`renderer`).
+> The Compose example uses `--max-time 2` with `timeout: 3s` for fast local feedback; the Kubernetes examples use
+> `--max-time 3` with `timeoutSeconds: 5` to allow more scheduler and node-load jitter.
 
 ## Host Binding for Container Environments
 
@@ -388,7 +477,20 @@ During container startup, you may see `ERR_STREAM_PREMATURE_CLOSE` errors from F
 
 **Mitigation:**
 
-1. **Health check endpoint** — The Node Renderer exposes a built-in `/info` endpoint that returns the node version and renderer version. Because the renderer uses cleartext HTTP/2, Kubernetes `httpGet` probes (HTTP/1.1) are incompatible with this listener. Use a TCP probe, an `exec` probe (for example with `curl --http2-prior-knowledge`, which requires curl with HTTP/2 support in your container image), or a dedicated HTTP/1.1 sidecar/port for probes. For a custom `/health` route with more granular checks, use the `configureFastify()` option (see [JS Configuration: Custom Fastify Configuration](./js-configuration.md#custom-fastify-configuration)). Configure your container orchestrator to wait for it before routing traffic.
+> [!NOTE]
+> **Probe command notes:** `exec` probes require curl with HTTP/2 support in your image. Verify with
+> `curl --version | grep -i http2`; if unavailable, use `tcpSocket` as a fallback. Set curl `--max-time` shorter than the
+> orchestrator timeout so curl returns a clean non-zero exit code before Kubernetes terminates the probe process. These
+> examples use `--max-time 3` with `timeoutSeconds: 5`, leaving a 2-second buffer. Readiness and liveness omit
+> `initialDelaySeconds` because Kubernetes 1.20+ (startup probe GA) defers
+> them until the startup probe succeeds. If you skip the startup probe or run an older cluster without startup probe
+> support, add an appropriate `initialDelaySeconds`.
-> support, add an appropriate `initialDelaySeconds`.
+> [!NOTE]
+> **Probe command notes:** `exec` probes require curl with HTTP/2 support in your image. Verify with
+> `curl --version | grep -i http2`; if unavailable, use `tcpSocket` as a fallback. Set curl `--max-time` shorter than the
+> orchestrator timeout so curl returns a clean non-zero exit code before Kubernetes terminates the probe process. These
+> examples use `--max-time 3` with `timeoutSeconds: 5`, leaving a 2-second buffer. Readiness and liveness omit
+> `initialDelaySeconds` because Kubernetes 1.20+ (startup probe GA) defers
+> them until the startup probe succeeds. If you skip the startup probe or run an older cluster without startup probe
+> support, add an appropriate `initialDelaySeconds`.
-> support, add an appropriate `initialDelaySeconds`.
+> [!NOTE]
+> **Probe command notes:** `exec` probes require curl with HTTP/2 support in your image. Verify with
+> `curl --version | grep -i http2`; if unavailable, use `tcpSocket` as a fallback. Set curl `--max-time` shorter than the
+> orchestrator timeout so curl returns a clean non-zero exit code before Kubernetes terminates the probe process. These
+> examples use `--max-time 3` with `timeoutSeconds: 5`, leaving a 2-second buffer. Readiness and liveness omit
+> `initialDelaySeconds` because Kubernetes 1.20+ (startup probe GA) defers
+> them until the startup probe succeeds. If you skip the startup probe or run an older cluster without startup probe
+> support, add an appropriate `initialDelaySeconds`.
+
+> **Security:** `/info` is unauthenticated even when `password` is configured. Keep the renderer on `localhost` or
+> private networking if exposing node and renderer version details is a concern; see
+> [Built-in Endpoints](./js-configuration.md#built-in-endpoints).
+
+1. **Health check endpoint** — The Node Renderer exposes a built-in `/info` endpoint that returns the node version and renderer version. Because the renderer uses cleartext HTTP/2, Kubernetes `httpGet` probes (HTTP/1.1) are incompatible with this listener. Use a TCP probe, an `exec` probe with an h2c-aware client such as `curl --http2-prior-knowledge`, or a dedicated HTTP/1.1 sidecar/port for probes. For a custom `/health` route with more granular checks, use the `configureFastify()` option (see [JS Configuration: Adding a Health Check Endpoint](./js-configuration.md#adding-a-health-check-endpoint)). Configure your container orchestrator to wait for it before routing traffic.
 2. **Startup probe** — Configure a startup probe with a generous `initialDelaySeconds`:
    ```yaml
    startupProbe:
@@ -397,30 +499,79 @@ During container startup, you may see `ERR_STREAM_PREMATURE_CLOSE` errors from F
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 6
+     timeoutSeconds: 1
    ```
 3. **Readiness probe** — Ensure traffic is only routed to the renderer when it's ready to accept requests. Prefer an `exec` probe with an h2c-aware client for application-level readiness. Use `tcpSocket` only as a minimal fallback that confirms the port is accepting connections:
+
    ```yaml
    readinessProbe:
      exec:
        command:
          - curl
          - -sf
+         - --max-time
+         - '3'
          - --http2-prior-knowledge
          - http://localhost:3800/info
      timeoutSeconds: 5
      periodSeconds: 5
      failureThreshold: 3
    ```
-   > **Note:** The `exec` probe requires curl with HTTP/2 support in your image. Verify with `curl --version | grep HTTP2`. If curl is unavailable, use `tcpSocket` as a fallback.
-4. **Liveness probe** — Ensure the renderer is restarted if it becomes unresponsive:
+
+   > **Notes:**
+   >
+   > - The YAML uses `/info` so it works before custom Fastify routes exist. Replace `/info` with `/health` after
+   >   registering that route via `configureFastify` if readiness should wait for renderer-specific warm-up checks.
+   > - Before upgrading an existing readiness probe, keep curl's `--max-time` lower than `timeoutSeconds`. If switching
+   >   from `tcpSocket` to `exec`, verify curl HTTP/2 support in the image first.
+   > - See the probe command notes above for curl HTTP/2 support, `--max-time`, loaded-node buffers, and
+   >   `initialDelaySeconds` guidance.
+
+   > **Readiness fallback option:** If curl lacks HTTP/2 support in your image, replace that `readinessProbe` with this
+   > `tcpSocket` block. This checks port reachability, not application-level readiness:
+   >
+   > ```yaml
+   > readinessProbe:
+   >   tcpSocket:
+   >     port: 3800
+   >   # TCP handshakes should complete quickly; exec/H2 uses timeoutSeconds: 5.
+   >   timeoutSeconds: 1
+   >   periodSeconds: 5
+   >   failureThreshold: 3
+   > ```
+
+4. **Liveness probe** — Ensure the renderer is restarted if it becomes unresponsive. The probe below changes the
+   liveness check from `tcpSocket` to `exec`; if you are upgrading an existing deployment, verify curl HTTP/2 support
+   first:
+
+   > **Before upgrading:** Run `curl --version | grep -i http2` inside your container image. If HTTP/2 support is absent,
+   > use the `tcpSocket` fallback shown below instead of this `exec` block.
+
    ```yaml
    livenessProbe:
-     tcpSocket:
-       port: 3800
+     # Omit initialDelaySeconds only if the startupProbe above is configured.
+     # Requires curl with HTTP/2 support (verify: curl --version | grep -i http2).
+     # If unavailable, replace this exec probe with a tcpSocket probe on port 3800.
+     exec:
+       command:
+         - curl
+         - -sf
+         - --max-time
+         - '3'
+         - --http2-prior-knowledge
+         - http://localhost:3800/info
+     timeoutSeconds: 5
      periodSeconds: 10
      failureThreshold: 3
    ```
 
+   > **Notes:**
+   >
+   > - Use `/info` by default. Only substitute `/health` for liveness if that route avoids external dependency checks and
+   >   readiness gates.
+   > - See the probe command notes above for curl HTTP/2 support, `--max-time`, loaded-node buffers, and
+   >   `initialDelaySeconds` guidance.
+
 ### OOM Tracking
 
 Distinguish between Rails and Node Renderer OOM kills by checking container-level exit codes:
@@ -451,6 +602,26 @@ In production, `logLevel: 'warn'` is sufficient unless actively debugging.
 
 A complete pod spec for the sidecar pattern:
 
+> [!WARNING]
+> The `exec` liveness probe in this copy-paste manifest requires curl with HTTP/2 support. Run
+> `curl --version | grep -i http2` in your container image before replacing an existing `tcpSocket` probe. If curl lacks
+> HTTP/2 support, keep `tcpSocket` or add HTTP/2-capable curl support. If you cannot verify curl before rollout, use the
+> `tcpSocket` fallback block below and upgrade to `exec` later.
+
+> **Liveness fallback option:** The manifest below uses `exec` (preferred). If curl lacks HTTP/2 support in your image,
+> replace the manifest's `livenessProbe` with this `tcpSocket` block before applying it:
+>
+> ```yaml
+> livenessProbe:
+>   # Omit initialDelaySeconds only if the startupProbe above is configured.
+>   tcpSocket:
+>     port: 3800
+>   # TCP handshakes should complete quickly; exec/H2 uses timeoutSeconds: 5.
+>   timeoutSeconds: 1
+>   periodSeconds: 10
+>   failureThreshold: 3
+> ```
+
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -513,23 +684,42 @@ spec:
             initialDelaySeconds: 10
             periodSeconds: 5
             failureThreshold: 6
+            timeoutSeconds: 1
           readinessProbe:
+            # Omit initialDelaySeconds only if the startupProbe above is configured.
-            # Omit initialDelaySeconds only if the startupProbe above is configured.
+            # Add initialDelaySeconds here if no startupProbe is configured.
+            # Kubernetes 1.20+ defers readiness/liveness until the startup probe succeeds.
-            # Omit initialDelaySeconds only if the startupProbe above is configured.
+            # Add initialDelaySeconds here if no startupProbe is configured.
+            # Kubernetes 1.20+ defers readiness/liveness until the startup probe succeeds.
             exec:
               command:
                 - curl
                 - -sf
+                - --max-time
+                - '3'
                 - --http2-prior-knowledge
                 - http://localhost:3800/info
             timeoutSeconds: 5
             periodSeconds: 5
             failureThreshold: 3
-            failureThreshold: 3
+            failureThreshold: 3
+            # Omit initialDelaySeconds only if the startupProbe above is configured.
-            failureThreshold: 3
+            failureThreshold: 3
+            # Omit initialDelaySeconds only if the startupProbe above is configured.
           livenessProbe:
-          livenessProbe:
+          # WARNING: exec probe requires curl with HTTP/2 support in this image.
+          # Verify: curl --version | grep -i http2
+          # If unavailable, replace exec/command below with: tcpSocket: { port: 3800 }
+          livenessProbe:
-          livenessProbe:
+          livenessProbe:
+            # CHANGED from tcpSocket to exec. If upgrading an existing deployment,
+            # verify curl --http2-prior-knowledge works in your image before switching.
-          livenessProbe:
+          # WARNING: exec probe requires curl with HTTP/2 support in this image.
+          # Verify: curl --version | grep -i http2
+          # If unavailable, replace exec/command below with: tcpSocket: { port: 3800 }
+          livenessProbe:
-          livenessProbe:
+          livenessProbe:
+            # CHANGED from tcpSocket to exec. If upgrading an existing deployment,
+            # verify curl --http2-prior-knowledge works in your image before switching.
-            tcpSocket:
-              port: 3800
+            # UPGRADE WARNING: verify curl HTTP/2 support before replacing an existing tcpSocket probe.
+            # Requires curl with HTTP/2 support (verify: curl --version | grep -i http2).
+            # If unavailable, replace this exec probe with a tcpSocket probe on port 3800.
+            # Omit initialDelaySeconds only if the startupProbe above is configured.
-            # Omit initialDelaySeconds only if the startupProbe above is configured.
+            # Add initialDelaySeconds here if no startupProbe is configured.
+            # Kubernetes 1.20+ defers readiness/liveness until the startup probe succeeds.
-            # Omit initialDelaySeconds only if the startupProbe above is configured.
+            # Add initialDelaySeconds here if no startupProbe is configured.
+            # Kubernetes 1.20+ defers readiness/liveness until the startup probe succeeds.
+            exec:
+              command:
+                - curl
+                - -sf
+                - --max-time
+                - '3'
+                - --http2-prior-knowledge
+                - http://localhost:3800/info
+            timeoutSeconds: 5
-            timeoutSeconds: 5
+            timeoutSeconds: 5
-            timeoutSeconds: 5
+            timeoutSeconds: 5
             periodSeconds: 10
             failureThreshold: 3
 ```
-          livenessProbe:
-            tcpSocket:
-              port: 3800
-            exec:
-              command:
-                - curl
-                - -sf
-                - --max-time
-                - '4'
-                - --http2-prior-knowledge
-                - http://localhost:3800/info
-            timeoutSeconds: 5
-            periodSeconds: 10
-            failureThreshold: 3
-```
+          livenessProbe:
+            # Requires curl with HTTP/2 support (verify: curl --version | grep -i http2).
+            # If unavailable, replace exec with: tcpSocket: { port: 3800 }
+            exec:
+              command:
+                - curl
+                - -sf
+                - --max-time
+                - '4'
+                - --http2-prior-knowledge
+                - http://localhost:3800/info
+            timeoutSeconds: 5
+            periodSeconds: 10
+            failureThreshold: 3
-          livenessProbe:
-            tcpSocket:
-              port: 3800
-            exec:
-              command:
-                - curl
-                - -sf
-                - --max-time
-                - '4'
-                - --http2-prior-knowledge
-                - http://localhost:3800/info
-            timeoutSeconds: 5
-            periodSeconds: 10
-            failureThreshold: 3
-```
+          livenessProbe:
+            # Requires curl with HTTP/2 support (verify: curl --version | grep -i http2).
+            # If unavailable, replace exec with: tcpSocket: { port: 3800 }
+            exec:
+              command:
+                - curl
+                - -sf
+                - --max-time
+                - '4'
+                - --http2-prior-knowledge
+                - http://localhost:3800/info
+            timeoutSeconds: 5
+            periodSeconds: 10
+            failureThreshold: 3
 
+> **Readiness endpoint:** The manifest uses `/info` for copy-paste safety because that endpoint is built in. Replace
+> `/info` with `/health` in the readiness probe after registering that route via `configureFastify` if readiness should
+> wait for renderer-specific warm-up checks.
+
 > **Note:** Both containers use the same Docker image, ensuring the React on Rails gem and Node Renderer package versions are always aligned.
 
 ## Troubleshooting