Dockerfile best practice: add --no-install-recommends to apt-get install commands in agent-server Dockerfile

[neubig]

Context

The Dockerfile at openhands-agent-server/openhands/agent_server/docker/Dockerfile has two apt-get install commands that do not use the --no-install-recommends flag:

1. Docker Engine install (line ~380): apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
2. GitHub CLI install (line ~419): apt-get install -y gh

Best practice

It is a Docker best practice to use --no-install-recommends with apt-get install to avoid pulling in unnecessary recommended packages. This keeps the image lean and reduces unnecessary bloat.

Suggested change

Add --no-install-recommends to both apt-get install commands:

# Docker Engine
apt-get install -y --no-install-recommends docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# GitHub CLI
apt-get install -y --no-install-recommends gh

Acceptance criteria

• Both apt-get install commands in the agent-server Dockerfile use --no-install-recommends
• Docker image still builds and functions correctly

---

OpenHands AI triage

The following comments and acceptance criteria were added by the OpenHands AI agent.

Triage

This is a narrow Dockerfile hygiene fix. The agent-server Dockerfile at openhands-agent-server/openhands/agent_server/docker/Dockerfile has two apt-get install invocations that omit --no-install-recommends (Docker Engine: apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin; GitHub CLI: apt-get install -y gh), while the other two apt-get install invocations in the same file already pass the flag. Adding it drops apt's recommended-but-unneeded dependencies and shrinks the image without changing the requested packages.

Scope: add --no-install-recommends to exactly those two commands in that Dockerfile. Non-goals: no change to package names, versions, repositories, or pinning; no other Dockerfile restructuring; no edits to examples/02_remote_agent_server/06_custom_tool/Dockerfile; no changes for non-apt package managers (microdnf/dnf/yum); no behavior change beyond which packages apt installs.

Verification note: this is a packaging change, so a mocked or unit test cannot validate it. Evidence must come from a real image build plus smoke-running the installed docker and gh executables in the built image (or from the existing agent-server image-build CI job). Two open PRs already implement this (#5070, #5192); whichever is merged should satisfy these criteria.

Desired Behavior

The agent-server Docker image installs the Docker Engine packages and the GitHub CLI without apt's recommended dependencies, while still providing working docker / docker compose and gh executables, consistent with the other apt-get install invocations in the same Dockerfile.

Acceptance Criteria

• The Docker Engine install in openhands-agent-server/openhands/agent_server/docker/Dockerfile reads apt-get install -y --no-install-recommends docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin, with the package list unchanged.
• The GitHub CLI install in the same Dockerfile reads apt-get install -y --no-install-recommends gh.
• Every apt-get install invocation remaining in that Dockerfile passes --no-install-recommends, and the diff is limited to adding the flag to those two commands (no other Dockerfile line changes).
• The agent-server Docker image builds successfully from the modified Dockerfile, locally or via the existing agent-server image-build CI job, with no new build failure.
• In the built image, docker --version, docker compose version, and gh --version all succeed, confirming the recommended-package removal did not drop a runtime requirement.

[github-actions]

⚠️ Not yet ready-for-dev

This issue does not yet meet the readiness criteria, so the
ready-for-dev label has not been applied (or has been removed).
The criteria are type-specific:

Bug reports (bug label, see .github/ISSUE_TEMPLATE/bug_template.yml):

• The ### Actual Behavior section must describe reproducible SDK steps
  and include a command such as python, pytest, uv, or pip.
• An ### Acceptance Criteria section with at least one checklist item (- [ ] …).

Enhancements (enhancement label, see .github/ISSUE_TEMPLATE/feature_request.yml):

• A ### Desired Behavior section.
• An ### Acceptance Criteria section with at least one checklist item.

What is missing:

• The issue has neither the bug nor enhancement label, so its readiness criteria cannot be evaluated. Add the appropriate label.

Edit the issue to address the gaps and the ready-for-dev label will be
applied automatically.

Note: Section headings require exact ### matches from the templates.
If a missing type label is reported, no action is needed from external
contributors — maintainers will add the label during triage.

This is an automated check — no AI was used to generate this comment.

[Graphitek8]

Hi @LucasLeao18, I was also working on #5049 and noticed your PR. I independently implemented the same change and verified the agent-server Docker image builds successfully before and after the change, including smoke-testing the docker and gh executables in the resulting image.

I noticed the PR description check is currently failing because of the HUMAN: section. I’ve opened my implementation as a draft as well, since the PR has been inactive for a few days.

If you’re planning to continue with your PR, I’m happy to leave yours as the implementation for #5049.

Cheers!

[neubig]

Please re-triage this issue against the current repository and make the acceptance criteria specific enough for the linked PR to be reviewed. If the issue is ready, apply the normal readiness process; if a design decision is still missing, ask the smallest necessary follow-up.