Explore single-binary release with built-in sandboxing #115

New issue

Closed

opened 2026-05-06 10:52:00 -07:00 by jwilger · 0 comments

jwilger commented

2026-05-06 10:52:00 -07:00

Owner

Background

Today deployment centers on a container image. That creates friction for operators who want to try or run auto_review without first setting up Docker/Podman or container hosting.

Exploration

Investigate releasing auto_review as a single auto-review binary that can be downloaded and run directly, while preserving the same sandboxing protections currently provided by the containerized runtime.

The binary should expose subcommands for the whole project, for example:

auto-review gateway ... to run the webhook gateway/chat poller service
auto-review <other-cli-command> ... for existing and future CLI/operator functions

Key questions

What sandboxing mechanisms can be enforced inside a standalone binary runtime, and how do they compare to the current Docker/Podman boundary?
Which protections must remain mandatory vs. optional/degraded on platforms without specific kernel features?
Can we provide a safe default "just run it" experience without silently weakening the threat model?
How should current crates/binaries be composed into one public executable and subcommand surface?
What release, packaging, and operations docs would be needed for the single-binary distribution?

Acceptance criteria for the exploration

Document a proposed single-binary architecture and CLI shape.
Compare sandbox guarantees against the current container deployment model.
Identify any threat-model changes and required red-team/contract tests.
Recommend whether to proceed with implementation, including major milestones and risks.

## Background Today deployment centers on a container image. That creates friction for operators who want to try or run auto_review without first setting up Docker/Podman or container hosting. ## Exploration Investigate releasing auto_review as a single `auto-review` binary that can be downloaded and run directly, while preserving the same sandboxing protections currently provided by the containerized runtime. The binary should expose subcommands for the whole project, for example: - `auto-review gateway ...` to run the webhook gateway/chat poller service - `auto-review <other-cli-command> ...` for existing and future CLI/operator functions ## Key questions - What sandboxing mechanisms can be enforced inside a standalone binary runtime, and how do they compare to the current Docker/Podman boundary? - Which protections must remain mandatory vs. optional/degraded on platforms without specific kernel features? - Can we provide a safe default "just run it" experience without silently weakening the threat model? - How should current crates/binaries be composed into one public executable and subcommand surface? - What release, packaging, and operations docs would be needed for the single-binary distribution? ## Acceptance criteria for the exploration - Document a proposed single-binary architecture and CLI shape. - Compare sandbox guarantees against the current container deployment model. - Identify any threat-model changes and required red-team/contract tests. - Recommend whether to proceed with implementation, including major milestones and risks.

jwilger referenced this issue

2026-05-06 11:57:45 -07:00

Implement unified auto-review CLI with grouped commands #116

jwilger referenced this issue

2026-05-06 11:57:45 -07:00

Implement embedded youki OCI gateway launcher #117

jwilger referenced this issue

2026-05-06 11:57:45 -07:00

Build embedded minimal OCI rootfs for auto-review gateway #118

jwilger referenced this issue

2026-05-06 11:57:45 -07:00

Run the Docker image through the unified auto-review binary #119