Add container images section to deployment

[sandromello]

No description provided.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
hoopdev	🟢 Ready	View Preview	Aug 7, 2026, 6:17 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[netlify]

✅ Deploy Preview for decap-documentation ready!

Name	Link
🔨 Latest commit	9faf623
🔍 Latest deploy log	https://app.netlify.com/projects/decap-documentation/deploys/6a76246d60f64d000865511d
😎 Deploy Preview	https://deploy-preview-158--decap-documentation.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[qodo-code-review]

PR Summary by Qodo

Document published container images and add it to deployment navigation

📝 Documentation ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Add a new Deployment docs page explaining published container images and use-cases.
• Document how to build custom agent images from released binaries with verification steps.
• Register the new page in the deployment docs navigation.

Diagram

graph TD
  A["docs.json"] --> B["Deployment nav"] --> C["container-images.mdx"] --> D["Docs site build"] --> E["Operators/Readers"]
  subgraph Legend
    direction LR
    _cfg["Navigation config"] ~~~ _doc["MDX content"] ~~~ _usr["Readers"]
  end

Loading

High-Level Assessment

The PR’s approach (a dedicated MDX page linked from the deployment navigation) is the simplest and most discoverable way to document image selection and custom builds without changing product behavior.

Files changed (2) +402 / -0

Documentation (1) +401 / -0

container-images.mdxNew docs page describing published container images and custom builds +401/-0

New docs page describing published container images and custom builds

• Introduces a comprehensive “Container Images” page covering gateway vs agent images, slim vs dev variants, OCR/GPU image guidance, and a base tooling image. Adds step-by-step examples for building custom agent images from release tarballs (including checksum verification) and outlines minimum requirements and maintenance guidance for custom images.

setup/deployment/container-images.mdx

Other (1) +1 / -0

docs.jsonAdd Container Images page to deployment navigation +1/-0

Add Container Images page to deployment navigation

• Registers the new 'setup/deployment/container-images' page in the deployment section so it appears in the docs sidebar and navigation flow.

docs.json

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ENTRYPOINT guidance inconsistent ✓ Resolved 🔗 Cross-repo conflict ≡ Correctness

Description

The new page says “official images” have no ENTRYPOINT and recommends overriding Kubernetes
command (not args), but hoophq/hoopdev (an official/default agent image) sets `ENTRYPOINT
["tini", "--"]. This makes the override advice image-dependent (hoopagent vs hoopdev`) and can
lead to incorrect Kubernetes manifests across repos.

Code

setup/deployment/container-images.mdx[R375-378]

+    `hoop start agent`. The official images use
+    `CMD ["hoop", "start", "agent"]` with no `ENTRYPOINT`, so if you override
+    it in Kubernetes, override `command`, not `args` — `args` alone replaces
+    the command entirely.

Relevance

●●● Strong

Inaccurate Kubernetes override guidance is a correctness footgun; team commonly fixes such docs
issues.

PR-#94

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR claims the official images have no ENTRYPOINT. In hoophq/hoop, the slim hoopagent image
documents “no ENTRYPOINT” (matching the PR’s claim), but hoopdev is also an official agent image
and is built with an explicit ENTRYPOINT ["tini", "--"], contradicting the PR’s blanket statement
and making the Kubernetes override guidance inaccurate for at least one official image.

setup/deployment/container-images.mdx[374-378]
External repo: hoophq/hoop, Dockerfile.dev [19-22]
External repo: hoophq/hoop, Dockerfile.agent [50-56]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The doc currently states that official images use `CMD ["hoop","start","agent"]` with no `ENTRYPOINT`, and therefore Kubernetes users should override `command` rather than `args`. In hoophq/hoop, `hoophq/hoopdev` includes an `ENTRYPOINT` (`tini --`), while `hoophq/hoopagent` explicitly has no ENTRYPOINT—so the guidance should be specific to the image being used.

## Issue Context
This is cross-repo drift between documentation guidance and the hoophq/hoop Dockerfiles that define the runtime contract for published images.

## Fix Focus Areas
- setup/deployment/container-images.mdx[374-378]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Ambiguous OCR image tag 🐞 Bug ≡ Correctness

Description

The 'Choosing an image' table lists hoophq/hoop-agent-ocr without a version (and without the
documented -gpu suffix), even though the page recommends pinning versions and later documents OCR
tags as :<version> and :<version>-gpu.

Code

setup/deployment/container-images.mdx[R28-29]

+| `hoophq/hoopdev` | You have **custom** or **command-line** connections (the agent runs a script, `psql`, `kubectl`, …), or **Remote Desktop (RDP)** connections |
+| `hoophq/hoop-agent-ocr` | You need live redaction of RDP sessions (requires a GPU instance) |

Relevance

●●● Strong

Team usually accepts docs correctness/clarity fixes to prevent misleading deployment instructions.

PR-#94
PR-#155

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The table uses an untagged OCR image reference, while the same page recommends version pinning and
later documents OCR tags only in versioned forms (including a separate GPU tag).

setup/deployment/container-images.mdx[24-29]
setup/deployment/container-images.mdx[41-43]
setup/deployment/container-images.mdx[121-122]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
In the image-selection table, the OCR entry is presented as `hoophq/hoop-agent-ocr` (no tag), which implies `:latest` in Docker semantics and also doesn’t indicate the GPU-specific tag the text says is required. Later in the doc, OCR tags are documented as versioned (`:<version>` and `:<version>-gpu`) and the page recommends pinning explicit versions.

### Issue Context
This can lead users to:
- pull a moving `latest` tag (if it exists), contrary to the doc’s best practice,
- fail to pull if no `latest`/untagged tag exists,
- pull the CPU tag when they intended GPU live redaction.

### Fix Focus Areas
- setup/deployment/container-images.mdx[24-29]
- setup/deployment/container-images.mdx[41-43]
- setup/deployment/container-images.mdx[119-122]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Wrong multi-arch claim ✓ Resolved 🐞 Bug ≡ Correctness

Description

setup/deployment/container-images.mdx states all images are multi-architecture (amd64+arm64) but
later says the OCR GPU tag is amd64-only, which contradicts the page and can mislead ARM64
deployments.

Code

setup/deployment/container-images.mdx[R41-43]

+All images are multi-architecture manifests covering `linux/amd64` and
+`linux/arm64`. Pin an explicit version in production rather than using
+`latest`.

Relevance

●●● Strong

Contradictory arch claims are high-impact docs correctness; likely to be fixed when flagged.

PR-#94

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The page explicitly asserts all images are multi-arch, then later documents the GPU OCR tag as
amd64-only; these two statements cannot both be true.

setup/deployment/container-images.mdx[41-43]
setup/deployment/container-images.mdx[121-122]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The doc claims **all** published images are multi-architecture (`linux/amd64` + `linux/arm64`), but later documents an explicit exception: `hoophq/hoop-agent-ocr:<version>-gpu` is `amd64` only. This is internally contradictory and can cause ARM64 users to select an image they cannot run.

### Issue Context
The OCR GPU image is documented as CUDA + `amd64` only, so the earlier blanket statement should be narrowed (e.g., “Most images…” or “All images except the GPU OCR tag…”), or moved/qualified per-image.

### Fix Focus Areas
- setup/deployment/container-images.mdx[41-43]
- setup/deployment/container-images.mdx[119-122]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (1)

4. Compose topology mismatch ✓ Resolved 🔗 Cross-repo conflict ≡ Correctness

Description

The new page says Docker Compose is a “single-container” deployment where hoophq/hoop runs the
agent, but hoophq/hoop’s shipped deploy/docker-compose/docker-compose.yml runs gateway
(hoophq/hoop) and agent (hoophq/hoopdev) as separate services. This docs/asset drift can mislead
users into deploying something that doesn’t match upstream Hoop deployment artifacts.

Code

setup/deployment/container-images.mdx[R61-62]

+This image can also run an agent (`hoop start agent`), which is how the
+single-container Docker Compose deployment works.

Relevance

●●● Strong

Docs/asset drift in deployment topology is a practical correctness issue they tend to correct.

PR-#94

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR explicitly states that Docker Compose is “single-container” and that hoophq/hoop running
hoop start agent is how that deployment works. In hoophq/hoop’s docker-compose, the gateway
service uses hoophq/hoop with hoop start gateway, while a separate agent service uses
hoophq/hoopdev, contradicting the PR’s description of the Compose topology.

setup/deployment/container-images.mdx[52-62]
External repo: hoophq/hoop, deploy/docker-compose/docker-compose.yml [22-60]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new documentation claims the Docker Compose deployment is “single-container” and implies `hoophq/hoop` is used to run the agent in that Compose setup. In the pinned hoophq/hoop repo, the provided Compose file runs gateway and agent as separate services, using `hoophq/hoop` for the gateway and `hoophq/hoopdev` for the agent.

## Issue Context
This is a cross-repo drift between hoophq/documentation deployment guidance and the actual deployment assets maintained in hoophq/hoop.

## Fix Focus Areas
- setup/deployment/container-images.mdx[61-62]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

✅ Compliance rules (platform): 11 rules

✅ Cross-repo context

  Explored: repo: hoophq/hoop (sha: a4733303)

  Not relevant to this PR: hoophq/changelog

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}