feat: ship container runtime settings, diagnostics, and lifecycle UX

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

dries/ocman#383

dries commented

2026-07-18 00:17:46 +02:00

Owner

Parent

#375

What to build

Turn the qualified managed-container path into an operable optional feature. Users can configure it per host, understand prerequisites and security consequences, inspect runtime health, restart or clean up managed instances safely, and diagnose failures without using the container CLI. Native mode remains the default and rollback path.

Acceptance criteria

Settings expose native/container mode per owning host with documented defaults, engine/image selection, resource limits, and required path/data constraints.
Enabling container mode performs a preflight for runtime availability, image, mounts, UID/GID, port publishing, database access, credentials, and OpenCode API compatibility.
Project/session UI reports runtime type, health, image/OpenCode version, endpoint locality, uptime, restart count, and actionable failure reason without exposing secrets.
Users can restart a managed instance through owner-routed lifecycle operations without losing project files or selecting the wrong native/container instance.
Stopped, orphaned, stale-version, and removed-project containers are identified; cleanup is explicit and never deletes repositories, worktrees, or OpenCode data implicitly.
Image upgrade behavior is documented and protects active turns; incompatible database migrations are rejected before launch.
Disabling container mode has a clear native fallback and conflict policy.
Multi-remote capability and settings behavior make it clear which host owns and configures the runtime.
Logs, metrics, traces, and system diagnostics expose lifecycle latency/failures and redact secrets.
Configuration, security, troubleshooting, multi-remote, and architecture documentation are complete.
End-to-end tests cover enable/preflight, launch/use/recover/restart/cleanup, failed preconditions, native fallback, and remote-host ownership.
Container mode is marked experimental or supported according to #382 rather than enabled by assumption.

Blocked by

## Parent #375 ## What to build Turn the qualified managed-container path into an operable optional feature. Users can configure it per host, understand prerequisites and security consequences, inspect runtime health, restart or clean up managed instances safely, and diagnose failures without using the container CLI. Native mode remains the default and rollback path. ## Acceptance criteria - [ ] Settings expose native/container mode per owning host with documented defaults, engine/image selection, resource limits, and required path/data constraints. - [ ] Enabling container mode performs a preflight for runtime availability, image, mounts, UID/GID, port publishing, database access, credentials, and OpenCode API compatibility. - [ ] Project/session UI reports runtime type, health, image/OpenCode version, endpoint locality, uptime, restart count, and actionable failure reason without exposing secrets. - [ ] Users can restart a managed instance through owner-routed lifecycle operations without losing project files or selecting the wrong native/container instance. - [ ] Stopped, orphaned, stale-version, and removed-project containers are identified; cleanup is explicit and never deletes repositories, worktrees, or OpenCode data implicitly. - [ ] Image upgrade behavior is documented and protects active turns; incompatible database migrations are rejected before launch. - [ ] Disabling container mode has a clear native fallback and conflict policy. - [ ] Multi-remote capability and settings behavior make it clear which host owns and configures the runtime. - [ ] Logs, metrics, traces, and system diagnostics expose lifecycle latency/failures and redact secrets. - [ ] Configuration, security, troubleshooting, multi-remote, and architecture documentation are complete. - [ ] End-to-end tests cover enable/preflight, launch/use/recover/restart/cleanup, failed preconditions, native fallback, and remote-host ownership. - [ ] Container mode is marked experimental or supported according to #382 rather than enabled by assumption. ## Blocked by - #379 - #380 - #381 - #382

dries added the

labels

dries referenced this issue

2026-07-18 00:18:34 +02:00

epic: optionally run managed OpenCode instances in containers #375

Rows
Columns

feat: ship container runtime settings, diagnostics, and lifecycle UX #383

Parent

What to build

Acceptance criteria

Blocked by