Skip to content

[Epic] Support native Podman with buildless managed onboarding #7744

Description

@ericksoa

Outcome

NemoClaw supports Docker and native Podman as pluggable compute runtimes without rebuilding a stock agent from a Dockerfile during onboarding.

The supported path applies to every shipped agent:

  • OpenClaw
  • Hermes
  • LangChain Deep Agents Code (DCode)

All three agents launch from complete, immutable managed-image digests on linux/amd64 and linux/arm64. Podman support includes sandbox GPU access and host-local Ollama, NIM, and vLLM through inference.local, including GPU-backed local inference. Those requirements are part of the support gate, not follow-up scope.

Runtime-specific behavior stays below driver-neutral lifecycle and bootstrap contracts. The abstractions must also admit a socket-free MXC-style provider without adding Podman switches to central onboarding, rebuild, snapshot, or recovery orchestration.

NemoClaw uses OpenShell's existing contracts as-is. No OpenShell code change, issue, or pull request is a prerequisite for this epic, and this work does not authorize mutations in NVIDIA/OpenShell.

Product decisions and invariants

  • Docker remains supported.
  • Stock managed onboarding becomes buildless; explicit user-supplied --from Dockerfiles remain a separate opt-in path.
  • Earlier implementation slices remain inert or internally complete. They must not advertise partial buildless or Podman support.
  • Buildless support activates only after OpenClaw, Hermes, and DCode pass together.
  • Podman support activates only after all agents, both architectures, GPU access, Ollama, NIM, vLLM, lifecycle recovery, installer validation, and protected E2E pass.
  • GPU, local inference, multi-architecture support, recovery, and any supported agent may not be cut from scope without a separate maintainer decision.
  • Central orchestration selects capabilities and opaque providers. It must not branch on Podman.
  • Each runtime registers exactly once as one immutable RuntimeProviderBundle. The provider identity, capability record, preflight and doctor, gateway, workload, lifecycle, mutation authority, managed bootstrap, snapshot, recovery, cleanup, and container-engine components must be complete and identity-consistent. Registration fails closed otherwise.
  • Container-engine selection is an explicit operation-scoped dependency. Shared host-container and host-local-inference flows cannot read or mutate a process-global active engine or execute Podman through Docker-named helpers.
  • Podman remains absent from the production selectable registry until 4.6. Earlier PR 4 slices construct it directly for tests and internal qualification only.
  • A source-shape guard forbids Podman imports, Podman identity comparisons, and Podman-specific switches in central orchestration.
  • A mutable name is never sufficient authority for destructive cleanup. Where the owning surface can delete only by name, NemoClaw quiesces and retains the exact runtime and returns typed immutable cleanup evidence. It must not issue an unsafe name-only delete, even after a best-effort re-resolution.

Driver-neutral architecture

Managed-image selection

The selection layer resolves an exact all-agent publication cohort and platform-specific digest. It validates repository, release/cohort identity, source revision, platform, immutable digest, and agent identity. Unknown runtimes and incomplete or mixed cohorts fail closed.

The selection contract is extensible: tests must register a fake MXC-style runtime profile without editing a central runtime switch. Adding the selection seam does not activate production buildless onboarding.

Startup profile and image runtime

Managed images own a versioned, secret-free startup profile and image-runtime contract. Agent-specific configuration is data, not a runtime-adapter fork. Credentials continue to use existing secret and policy delivery paths and are excluded from images, startup profiles, labels, logs, and completion receipts.

Driver-neutral lifecycle

Onboarding, destroy, rebuild, snapshot, clone, restore, and recovery depend on one injected provider bundle with opaque handles and normalized capability records, not separately mutable registries. Providers may use a socket, CLI, API, session, or runtime-native mechanism internally; those details cannot leak into central orchestration.

Transactional bootstrap

The supported bootstrap sequence is:

  1. Select an exact managed image for agent and platform.
  2. Create the sandbox with a bounded, non-agent hold.
  3. Discover exactly one workload from durable sandbox and bootstrap identity.
  4. Take stable normalized inspections and make the observed immutable image/spec identity authoritative.
  5. Stage the validated root-owned startup envelope into a stopped replacement.
  6. Start through the image-owned bootstrap trampoline, which applies allowlisted state atomically and directly executes the exact captured supervisor argv.
  7. Verify an image-authored completion receipt bound to runtime, image, spec, profile, shared-state transaction, and bootstrap identity.
  8. Commit registry/shared state only after readiness and required GPU/local-inference proof.
  9. On failure, roll back idempotently through the owning provider without unsafe name deletion.

The untrusted agent workload may not run before bootstrap release. The agent remains nonroot after the original supervisor is restored.

The adapter contract separates non-destructive preparation from destructive activation. Preparation creates and inspects a stopped replacement under a transaction-temporary identity, stages the identity-bound envelope, and returns the complete exact original and replacement IDs plus opaque rollback authority. Only after the coordinator durably records those IDs, the bootstrap identity, plan fingerprint, provider and sandbox identities, phase, rollback target, and commit and cleanup receipts may activation quiesce or rename the original. The preserved donor sequence that stops or renames the original before creating and identifying the replacement is explicitly rejected. Recovery must be able to resume or roll back from every recorded phase without relying on process-local maps.

Incremental PR stack

The former monolithic PR 3 and PR 4 review units are source material only. The implementation is extracted into the budgeted chain below.

Review budget:

  • one subsystem and one review thesis per PR;
  • normally 25–40 files and 2–5k changed lines;
  • split again when a unit materially exceeds that budget;
  • tests and relevant documentation travel with the behavior they validate; and
  • each completed slice is pushed as a correctly based NemoClaw PR only after its local exact-head gates pass; placeholder or monolithic review units are not opened.

Foundation status

PR 1 — #7747: driver-neutral compute selection groundwork (merged)

  • Separate compute-driver selection from gateway launch.
  • Persist the resolved driver identity.
  • Keep current behavior unchanged.
  • Merged as cbaeac80b34f5918c44d810cfa2fe2149ea518bf on 2026-07-30.
  • The live release label is v0.0.99; no later stack slice receives a release label before its exact head is green and the live bucket is reverified.

PR 2 — #7756: complete immutable managed images (merged)

  • Publish complete OpenClaw, Hermes, and DCode images.
  • Publish native linux/amd64 and linux/arm64 manifests.
  • Validate exact per-platform image contracts.
  • Promote an all-agent cohort only after every immutable candidate passes.
  • Do not activate buildless onboarding.
  • Exact-head CI, advisor, and protected E2E passed for
    061e44f571db855f3fcbbd2d78990c8fe4e4df7b.
  • Admin-merged by explicit maintainer instruction as
    f75c03d1faf501b8dcd35c260e0867f09a06d317 on 2026-07-30.
  • Merge-time release automation assigned the live v0.0.99 label because the
    PR landed on main before that tag was cut.

PR 3 series — buildless managed onboarding

The preserved #7772 implementation head is extraction source. #7772 is only PR 3.1; every later unit is reconstructed as a clean sequential review boundary, locally validated, and then pushed with its exact predecessor as the base.

Dependency chain:

3.1 → 3.2 → 3.3 → 3.4a → 3.4b → 3.5 → 3.5a → 3.5b → 3.5c → 3.6 → 3.7 → 3.8 → 3.9 → 3.10a → 3.10b → 3.11 → 3.12a → 3.12b → 3.13 → 3.14a → 3.14b → 3.14c → 3.15

3.1 — managed-image catalog, resolution, and inert buildless selection

  • Exact all-agent catalog and registry resolution.
  • Exact digest/platform/release/cohort validation.
  • Driver-neutral buildless selection contract and custom---from escape hatch.
  • Fake Podman/MXC-style runtime registration test.
  • No production caller, activation, Dockerfile change, workflow change, or public support claim.

Concrete extraction boundary: #7772 contains 18 files (+3,365/-30) for the managed-image contract, catalog, scoped registry transport, workload runtime/source/preparation contracts, the leaf proxy helper, package metadata, and their source and packed-package tests. Registry transport distinguishes unavailability from integrity failure, preserves uppercase/lowercase proxy exclusions, and declares its locked undici import as a production dependency. The package contract packs the CLI, installs it with --omit=dev, asserts the installed production tree contains undici@8.5.0, and constructs the transport. No production onboarding caller imports the new entry points.

The implementation review tree is the clean nine-commit semantic replay at 8d44c748e633b20f11ccfb15d2373a499fb1b5f7 on main 1ce71fa0fe93650b191c396355c817085e515a41. Repository rules prohibited force-pushing the existing PR branch, so final reviewed head 5cc8660794d6a773dfc2c0ba3d75161236fed37c retained the signed protected fast-forward history and merged main 231395a333ed9e415e9c662257e172d01b725b0e. Its final PR diff was byte-identical to the clean semantic replay: 18 files, +3,365/-30. The former monolithic and intermediate heads remain reachable only because of that protected-branch rule and are also preserved in durable local backup refs.

Exact pair 2aebae1f221e62dcf662e6b761399cc71138c28a / 1ce71fa0fe93650b191c396355c817085e515a41 completed ordinary CI, both advisor lanes, and protected E2E successfully. After main moved, pair 5d40953bba29dfa5815511dff075265d492e912a / 148efea9766d0dbfedc4cb90258e0a267af03b67 also completed ordinary CI (30578642503), both advisor lanes (30578640273), protected child 30579573317, controller 30579603366, and coordination check 90993131555 successfully. Both protected cycles passed cloud inference, cloud onboarding, OpenClaw and Hermes security posture, onboard repair, and onboard resume.

The final exact pair 5cc8660794d6a773dfc2c0ba3d75161236fed37c / 231395a333ed9e415e9c662257e172d01b725b0e then passed ordinary CI (30581653222), both advisor lanes (30581651198), protected child 30583833767, controller 30581713214, and coordination check 91005816236. Protected qualification again passed cloud inference, cloud onboarding, OpenClaw and Hermes security posture, onboard repair, and onboard resume. With the maintainer's standing approval preserved across the base refresh, #7772 was admin squash-merged as a8c7ab01ef8442e6edc3b071c758d680ecd29549 on 2026-07-30. GitHub's merge-time release automation added v0.0.99; the previously verified v0.0.100 target label also remains on the merged PR.

GitHub automatically closed the stacked #7944 when #7772's merged source branch was deleted. Repository rules prohibited replacing #7944's protected head with the clean current-main history. Its original head remains preserved as a closed source record.

The clean replacement series has landed through PR3.6. The active sequential review chain now reaches PR3.10B:

merged #7961 7eb0369e → merged #7969 1e570008 → merged #7973 99d5b669 (including #7976, #7988, and #7990) → #8001 4960f4db → #8031 1a91ef28 → #8032 fabad325 → #8034 94cb1645 → #8035 c176a4f1 → #8036 8bc9ea13 → #8037 ff836adc

Live status snapshot — 2026-07-31 19:57 PDT:

Standing approval remains in force across restacks; do not add needs: review solely because a base changes. Protected E2E runs immediately whenever the exact head/base pair becomes technically eligible.

3.2 — #7946: startup-profile schema

  • Versioned, bounded, secret-free startup-profile and transport schemas.
  • Schema validation and canonical serialization tests.
  • Complete all-agent capability and Dockerfile-affordance inventory.
  • No image-runtime construction or production wiring.

Reviewed head ea5bd8a8e617563133b1f8fc2843d6b7ba407511 merged current main 0030ba4d3e50a0402a440776f83bace033044937. Its six-file review diff was +3,205/-0; 102 focused profile/transport tests, five watch-trigger integration tests, both builds, validate:pr, diff checks, signature/DCO inspection, and an independent security/dormancy audit passed. The exact diff had no production import or activation. Ordinary CI, both advisors, CodeQL, macOS/WSL, self-hosted amd64/arm64, and protected E2E passed; #7946 was admin squash-merged as 37f6a8a650ff500f7054bae8d36b00e7b42edd41 with v0.0.100.

3.3 — #7959: image-runtime construction

  • Hold, image-runtime, onboard-profile, and profile-builder construction.
  • Agent/platform-specific construction tests for OpenClaw, Hermes, and DCode.
  • No application or shared-state mutation.

Final reviewed head 2a048aeecb4bd491daadc3c109f9b845031a6e04 was a tree-preserving restack commit over merged PR3.2 37f6a8a650ff500f7054bae8d36b00e7b42edd41. Its eight-file diff was +2,714/-1; 156 focused/current-base tests (54 slice-only), both builds, validate:pr, diff and no-docs checks, independent P1/P2 audit, ordinary CI, both advisors, and protected E2E passed. It was admin squash-merged by explicit maintainer instruction as verified commit 91fc63ede7775e2825be8ad6b3c5e5b8706f0119.

3.4a — #7960: all-agent application mapping and coordination

  • Map validated profiles into fail-closed application and environment plans.
  • Coordinate OpenClaw, Hermes, and DCode configuration without filesystem mutation.
  • Preserve engine neutrality and keep production activation absent.

The former combined PR3.4 exceeded the soft review budget and was split. #7960 merged as 64d68281064b760232694a3150f13d060a28936f after its exact head 7d1668bbe6b1758539531db185903fb0256b150a passed the complete ordinary-CI, advisor, CodeRabbit, and protected-E2E gate. Its eight-file diff was +3,587/-0; 45 CLI-project slice tests, ten executable fixture CLI-path tests, and 24 transaction tests under five shuffled seeds passed alongside CLI typecheck/build and validate:pr. Both CodeRabbit threads were resolved, the advisor reported zero blockers, and the one dormant-framework warning was explicitly dispositioned against this epic activation invariant. The merged PR carries v0.0.100.

3.4b — #7961: managed-image application and runtime-input cleanup

  • Apply validated all-agent plans inside managed images.
  • Forward or remove every runtime input according to its typed agent disposition.
  • Sanitize child environments and preserve deterministic committed replay.

Final reviewed head 13932b9b2486cd42b6fc47645e2f3936e5308d1d retained the fourteen-file +2,308/-66 review patch with stable patch ID b1697ff3d4ae9ec686a9a027991817427ab76434. It completed 35 passing ordinary, advisor, CodeRabbit, platform, and protected-E2E checks, carried v0.0.100, and was admin squash-merged to main as 7eb0369e7a0bc91f6ae99fc1eaad3cd274a34c8a on 2026-07-31. The three deferred CodeRabbit findings were fixed by #7976 and are now present on main through #7973.

3.5 — #7969: shared-state transactions and Docker adapters

  • Root-apply and Docker shared-state transactions.
  • Atomic application, ownership, mode, commit, rollback, and exact replay tests.
  • Preserve only the six allowlisted OpenClaw scheduler controls through clean root execution.
  • Recovery behavior remains deferred to 3.12.

Final head 83f29daf129adf51bbffa43106633ee748b7eefc retained the ten-file +3,251/-37 review patch with stable patch ID 9a4ead01527f33245de5ed62412dca1395e33a13. It completed 40 passing checks, carried v0.0.100, and was merged to main as 1e5700085b3f5bd768ca8d1c065689ceb07c6434 on 2026-07-31. Its deferred hardening findings were resolved by #7973, which subsequently landed on main; the primitives remain dormant with no production cutover caller.

3.5a — #7973: CodeRabbit managed-contract hardening

The final head 047c5dcf316093204ccbde0a1af25d6d2b11b1a5 contains the merged PR3.5b, PR3.5c, and PR3.6 heads, completed 37 passing checks with no unresolved review threads, and carried v0.0.100. #7973 was approved and squash-merged to main as 99d5b6690d144d6398b49586dcc610b0043d4867 on 2026-07-31, thereby landing the complete series through PR3.6.

3.5b — #7976: prior-stack CodeRabbit debt cleanup

Dedicated reviewed head 771f48c47c0aaa1d51511d172fffc691e6c9ac76 retained the seven-file +462/-80 slice with stable patch ID 546bf224e8b4a6f95e91fadac43ae933c5ae9119, completed 38 passing checks, had no unresolved review threads, and carried v0.0.100. It was merged into the #7973 feature branch as 6b5842bc8f52b854c201880b5e158172ddeba38e; that merge is contained by final #7973 head 047c5dcf316093204ccbde0a1af25d6d2b11b1a5 and is present on main through #7973 squash 99d5b6690d144d6398b49586dcc610b0043d4867.

3.5c — #7988: runtime-parameterized protected E2E foundation

  • Separate a runtime-neutral scenario contract from a typed execution profile containing provider, platform, architecture, root mode, acceleration, capabilities, and runner requirements.
  • Evolve the existing typed target registry and matrix compiler; do not create a second E2E framework or copy every scenario into Docker and Podman variants.
  • Bind only capability-compatible scenario/profile pairs and fail matrix generation when a required support obligation has no executable case.
  • Group isolated cases into bounded runtime/host shards while retaining unique sandbox, cleanup, result, and artifact identities.
  • Add normalized cross-runtime parity assertions while keeping provider-specific transaction and receipt assertions in provider fixtures.
  • Preserve current Docker behavior and prove the model is dormant with respect to production runtime selection.

Dedicated reviewed head 4788d287b8672be1b44999e78e094b2221303bd1 retained the 17-file +2,555/-2 slice with stable patch ID d4330cb898113aea3b782a640ef44b33d6f64827, resolved all six CodeRabbit threads, completed its 37-check gate, and carried v0.0.100 before merge. It was merged into the #7973 feature branch as 24290d14fc47750fa0b66e100de11a33d92fc5d5 and is present on main through #7973 squash 99d5b6690d144d6398b49586dcc610b0043d4867. GitHub retains four failed checks and one cancellation from later superseded post-merge/base-movement reruns on #7988; the shipping receipt is the containing final #7973 head, which passed all 37 checks before landing.

3.6 — #7990: driver-neutral lifecycle and migrated mutation parity

  • Register one complete immutable provider bundle and normalized capability DTOs; do not introduce independently populated registries.
  • Route registration, start, provider-owned post-start verification, stop, inference mutation authority, live destroy preparation/deletion, and owned-workload cleanup through that bundle.
  • Prove OpenClaw, Hermes, and DCode parity with a socket-free MXC-style provider and no Podman/MXC switch in central migrated consumers.
  • Keep production selection limited to Docker and Kubernetes.
  • Keep direct connect, status, logs, durable recovery, and reconciliation explicitly assigned to later recovery slices before future-provider activation.
  • No forward dependency on the transactional bootstrap adapter and no user-visible runtime activation.

Dedicated reviewed head 75730cf09bf1a1aa901cc3b275052250f8e7d85d retained the 45-file +4,073/-508 slice with stable patch ID eef1fddf8138d6e8a3ef4efb443aa2adc9f74fe3, completed 45 passing checks, had no unresolved review threads, and carried v0.0.100. It was merged into the #7973 feature branch as b758dc7b71fe4fced9899d5d0ffeb9fd8b550555; final #7973 head 047c5dcf316093204ccbde0a1af25d6d2b11b1a5 contains that merge, so the driver-neutral lifecycle slice is present on main through #7973 squash 99d5b6690d144d6398b49586dcc610b0043d4867.

3.7 — #8001: atomic managed-workload rebuild parity

  • Managed workload rebuild profile and rebuild phase decomposition.
  • Preserve the old authoritative workload until replacement readiness.
  • Tests for buildless rebuild planning and rollback.

#8001 is fully green at signed, Verified head 4960f4dbe16188e61385b7abe6ec0038a9f20c04 on current main 227e8b92b600c77684fe45befd7909ae4ad39141. Its 23-file +4,272/-0 review diff retains all seven CodeRabbit fixes and has zero unresolved threads. Ordinary CI passed on attempt 2 after an unchanged-head retry of one unrelated five-second MCP test timeout; both advisors, JS/Python CodeQL, and protected E2E child 30679687285 are green. The live v0.0.101 label is applied. Standing approval remains in force, but no merge occurs without explicit maintainer instruction.

3.8 — snapshot, backup, and restore parity

  • Snapshot dependencies and lifecycle state.
  • Provider preflight and managed-profile restore behavior.
  • Fail closed when runtime/acceleration state cannot be represented.

Open PR3.8 #8031 is exactly based on #8001 at 1a91ef28713b92d056a73f4afe6f7e89f5ffd0d5 (41 files, +5,394/-82). Its local focused and exact-range gates are green; remote CI, advisors, explicitly triggered CodeRabbit, self-hosted/multiarch checks, and protected E2E are qualifying the current head.

3.9 — clone, Hermes, and messaging parity

  • Provider-aware clone flow.
  • Hermes gateway/tool-broker credential and runtime rebinding.
  • Messaging hydration, persistence, and clone rebind.

The clean sequential PR3.9 chain is open as #8032 fabad32581afd4573192de1daa7904614ba29ace (inert clone handoff contract), #8034 94cb1645116a28fcd7b652a99402690683bd2e80 (dormant provider transaction/dependency surface), and #8035 c176a4f109be406dd96d391190e0b04716550a41 (dormant Hermes broker boundary). Each is based on its exact predecessor; CodeRabbit is explicitly triggered because automatic review skips non-default stacked bases.

3.10a — transactional bootstrap protocol and image-owned execution

  • Bootstrap envelope, exact sandbox identity, normalized inspection, runtime/spec DTOs, and completion receipts.
  • Image-owned trampoline and exact captured-supervisor execution.
  • Driver-neutral coordinator protocol with fake-provider tests.
  • No Docker adapter, create integration, or production activation.

Open PR3.10A #8036 is exactly based on #8035 at 8bc9ea13c379e15ca892382272cc01ceeb564b6c (10 files, +2,772/-0). Its 35 focused tests and exact local gates are green; the contract remains dormant and provider-neutral.

3.10b — Docker bootstrap adapter and exact cleanup

  • Docker prepare-stopped-replacement, cutover, await, commit, rollback, and typed incomplete-create cleanup.
  • Persist complete original and replacement runtime identities before the first destructive action.
  • Exact ownership, shared-state integration, commit, rollback, and cleanup-required behavior.
  • No unsafe mutable-name delete.

Open PR3.10B #8037 is exactly based on #8036 at ff836adc7db965275fceb79e097568a3d05c9f3d (18 files, +5,241/-25). Its 78 focused tests, CLI build/typecheck, and exact local hooks are green; the Docker adapter remains unregistered and production support remains inert.

3.11 — provider/create integration

  • Provider registry integration for create and GPU create flows.
  • Startup-command, launch-plan, and transport integration.
  • Docker GPU/local-inference proof remains required.

3.12a — durable transaction records and restart-safe persistence

  • Versioned transaction records contain bootstrap identity, plan fingerprint, provider and sandbox identities, complete original and replacement IDs, phase, rollback target, and commit and cleanup receipts.
  • Persist mutation authority before the first destructive action.
  • Durable shared-state commit and receipt storage replace process-local Maps and Sets.
  • Enumerate and reconstruct unfinished transactions after process restart.

3.12b — phase reconciliation and cross-surface recovery

  • Resume or roll back from every recorded phase.
  • Incomplete-create recovery, synchronous polling, and exact receipt reconstruction.
  • Race handling, idempotent cleanup, and name-reuse failure injection.
  • Hermes, destroy, snapshot, and shared-state restart recovery.

3.13 — image-owned all-agent artifacts and direct publication qualification

  • Add the shared trampoline/startup assets to all three managed images.
  • Validate layouts, entrypoints, config generation, exact image evidence, and sanitized failure diagnostics.
  • Qualify direct immutable publication without yet wiring stock onboarding.

3.14a — managed-image publication workflow hardening

  • Close every still-valid ci(images): publish validated managed OCI images #7756 CodeRabbit publication recommendation as one CI/publication subsystem.
  • Extract the repeated all-agent cohort contract generation into one reviewed helper and replace text scraping with structured buildx imagetools inspect --format data.
  • Make publication tests assert semantic commands and parsed workflow structure instead of complete ordered argv or source-text markers.
  • Remove the redundant display-agent branch and bound/chunk full-history path expansion.
  • Preserve atomic all-agent, linux/amd64, and linux/arm64 publication semantics. No runtime activation.

3.14b — protected all-agent build and multi-architecture qualification

  • Protected buildless E2E for OpenClaw, Hermes, and DCode together.
  • Qualify direct immutable all-agent cohort publication and exact image-owned entrypoint/layout contracts.
  • Produce native linux/amd64 and linux/arm64 image evidence.
  • Approve and run protected E2E immediately whenever the exact head/base pair is technically eligible.
  • No production activation.

3.14c — protected GPU, local-inference, and recovery qualification

  • GPU-backed qualification for the complete all-agent buildless path.
  • Host-local Ollama, NIM, and vLLM through inference.local where required by the supported matrix.
  • Restart, rebuild, snapshot/restore, clone, rollback, crash recovery, and exact cleanup evidence.
  • Name-reuse and incomplete-create failure injection.
  • Inject managed root-apply, supervisor, and commit failures, then compare reported onboarding status with independently probed gateway and sandbox state after recovery.
  • Approve and run protected E2E immediately whenever the exact head/base pair is technically eligible.
  • No production activation.

3.15 — production activation and support documentation

  • Wire production onboarding to the validated buildless path.
  • Remove automatic stock-Dockerfile fallback while preserving explicit --from.
  • Activate only after 3.13 and 3.14a–3.14c exact-head evidence is green.
  • Publish the essential architecture, quickstart, runtime-control, platform-support, troubleshooting, and security documentation.
  • Split a documentation sweep into 3.16 if the review budget requires it; no public support claim precedes 3.15.

PR 4 series — pluggable native Podman

The preserved #7872 remote and local heads are source references. #7872 remains draft/source material until the PR 3 series reaches activation, then becomes only PR 4.1. The previously uncaptured original-worktree state (28 modified and 10 untracked paths) is preserved exactly by signed local checkpoint 4c8a877996778a0c9aa83d77dca16360f4c5841f at refs/backup/pr4-dirty-wip-exact-20260730; the checkpoint used a temporary index and did not alter that worktree's branch, index, or files.

Dependency chain:

4.1 → 4.2 → 4.3 → 4.4 → 4.5 → 4.6

The architecture review on #7872 is incorporated as design input. Its reviewed head is preserved source material, not the implementation boundary for the rebuilt series. The old monolith's CPU/amd64-first behavior may inform inert internal construction only; it cannot narrow the complete activation gate.

Preserved source extraction map:

Slice Preserved source material
4.1 45bd5313 provider/plan, gateway, requirements, recovery, authority, doctor, lifecycle, and workload registries; 334c5322 managed-bootstrap provider code; reconstruct the pluggability contract test
4.2 45bd5313 Podman preflight, socket authority, recreate/spec, and lifecycle; use 405179c7 process-global engine selection only as negative design evidence
4.3 dcf6365a watcher, root-apply, and shared-state primitives; 2cee4ed1 create integration; 334c5322 managed-bootstrap adapter and trampoline integration
4.4 2cee4ed1 runtime/snapshot authority; c996fb56 persisted engine identity; replace 334c5322 closure-local provider state with durable records
4.5 405179c7 GPU attachment and host-local Ollama, NIM, and vLLM source material
4.6 45bd5313, 2cee4ed1, and 405179c7 installer, documentation, matrix, and E2E source material, rebuilt for the complete support matrix

4.1 — pluggable runtime registry and capability contract

  • Register one complete RuntimeProviderBundle covering plan, capabilities, preflight and doctor, gateway, workload, lifecycle, mutation authority, bootstrap, snapshot, recovery, cleanup, and container engine.
  • Reject missing surfaces, duplicate identities, and identity mismatches at registration.
  • Opaque provider identity with no central Podman switch.
  • Contract test proving a genuinely socket-free in-memory MXC-style provider can register and execute create, discover, inspect, replace, await, commit, rollback, and incomplete-create cleanup.
  • No production Podman activation.

4.2 — Podman command adapter, preflight, and CPU lifecycle

  • Introduce an explicitly injected, operation-scoped ContainerEngine; remove the process-global active-engine override and prevent Docker-named helpers from translating into Podman commands.
  • Native Podman command adapter and exact command/result normalization.
  • Installer/preflight detection and supported rootful/rootless CPU lifecycle.
  • Exact image identity, create, inspect, start, stop, and provider-owned cleanup.

4.3 — Podman managed startup and bootstrap for all agents

  • OpenClaw, Hermes, and DCode together.
  • Consume the shared coordinator and image-owned trampoline; do not use privileged post-start podman exec --user 0:0.
  • Stage the protected envelope into a stopped replacement and start only through the image-owned trampoline.
  • Preserve bootstrap identity through root apply.
  • Verify exact runtime/image/spec identity and an image-authored completion receipt.
  • No name-only reconnect or fabricated completion state.

4.4 — persisted engine identity and lifecycle recovery

  • Persist runtime engine/provider identity.
  • Persist mutation authority before the first destructive action and test process restart at every transaction phase.
  • Snapshot, rebuild, restore, and restart recovery.
  • Durable journal reconstruction and receipt retirement.
  • Exact-ID-only destructive mutation; unsafe name cleanup remains quiesced and retained.
  • Preserve or fail closed on opaque GPU/CDI state rather than silently converting a clone to CPU.

4.5 — GPU and host-local inference

  • Podman CDI/NVIDIA GPU attachment.
  • Host-local Ollama, NIM, and vLLM through inference.local.
  • Extend the same capability record used by preflight and lifecycle; do not add a parallel GPU or inference registry.
  • GPU-backed local inference and GPU snapshot/restore behavior.
  • Real agent inference turns for all three agents.

4.6 — native Podman activation, protected E2E, installer, and docs

  • Docker unavailable in the native Podman lane.
  • OpenClaw, Hermes, and DCode on supported amd64 and arm64 hosts.
  • CPU, GPU, local inference, restart, rebuild, snapshot/restore, rollback, and cleanup evidence.
  • Installer/preflight validation and evidence-backed support documentation.
  • Add the first production Podman registration. One capability record drives preflight, runtime guards, documentation, and protected E2E selection.
  • Remove unsupported-runtime rejection and advertise Podman only after the complete exact-head matrix is green.

Test and evidence gates

Product-flow E2E boundary

The stack distinguishes dormant domain construction from changes that can alter a real user journey:

  • A slice is domain-only only when exact source-boundary tests prove that no production command, handler, lifecycle path, registry, or selectable provider imports or calls the new behavior. PR3.1 through PR3.5c remain in this category only while that dormancy proof holds.
  • PR3.5c establishes the reusable parameterized E2E substrate before lifecycle integration begins.
  • Beginning with PR3.6, a slice is presumed product-flow-affecting whenever it changes an existing Docker path or introduces a production caller, provider selection, external mutation, persisted identity, bootstrap application, lifecycle operation, recovery decision, or user-visible result. The PR may claim the narrower domain-only gate only when its exact diff proves those boundaries remain untouched.
  • An activation slice makes a new path selectable or supportable. PR3.15 is the buildless activation boundary and PR4.6 is the native Podman activation boundary.

A product-flow-affecting exact head may not merge or ship on unit, contract, or model tests alone. It must pass protected E2E compiled from:

  1. a runtime-neutral scenario: agent, user journey, required capabilities, and normalized assertions; and
  2. a typed execution profile: provider, platform, architecture, root mode, acceleration, declared capabilities, and runner.

Generic scenario code receives the execution profile through fixtures and must not branch on Docker or Podman. Runtime-specific command execution, readiness, inspection, and cleanup stay in provider fixtures. The matrix compiler:

  • binds only compatible scenario/profile pairs;
  • treats missing required coverage as a compilation failure rather than a skip;
  • records the exact runtime identity, engine version, architecture, managed-image digests, capability record, PR head, and base in evidence;
  • groups compatible cases into bounded deterministic host/runtime shards instead of producing a full Cartesian set of parallel jobs; and
  • preserves per-case isolation, cleanup, artifacts, and stable IDs inside a shared shard.

The minimum protected gate for a product-flow-affecting slice is:

  • one current-production baseline profile for every supported runtime, including a Docker regression path;
  • every shipped agent when the changed flow is shared by OpenClaw, Hermes, and DCode;
  • every execution profile whose capability implementation changed, such as GPU, snapshot/restore, rootless operation, or host-local inference;
  • normalized FSM transition, terminal-state, desired-state, and user-visible-result parity across providers for the same scenario; and
  • provider-specific transaction, immutable-identity, rollback, cleanup, and receipt assertions below that common FSM contract.

Before Podman activation, an executable candidate Podman path must join the protected matrix for the PR4 slice that introduces or changes it even though it remains absent from the production selectable registry. After PR4.6, every shared product-flow change must pass both Docker and Podman baseline profiles before it can ship. Provider-specific behavior such as Podman CDI/rootless/SELinux or Docker daemon integration remains a targeted provider scenario and is not multiplied across unrelated runtimes.

Domain-only slices still run all existing repository gates plus focused contract, adversarial, serialization, and dormancy tests; they do not require a fabricated live runtime path. Activation exact heads additionally run the complete declared support matrix below. Nightly or rotating pairwise coverage may broaden non-blocking combinations, but it cannot substitute for the exact-head activation matrix.

Every slice

  • exact-base and exact-head local validation;
  • typecheck and affected unit/integration tests;
  • source-shape and test-size guardrails;
  • relevant documentation validation;
  • no production activation import for an inert slice; and
  • diff audit against the slice's stated subsystem and review budget.

Buildless activation

  • all three agents;
  • linux/amd64 and linux/arm64;
  • immutable candidate image digests from the exact stack;
  • real onboarding with no stock Dockerfile build;
  • nonroot agent identity;
  • restart, rebuild, snapshot/restore, clone, backup, recovery, and rollback;
  • exact bootstrap receipt and shared-state commit;
  • GPU/local-inference proof where required; and
  • existing Docker, macOS, WSL, gateway-isolation, messaging, and security regressions remain green.

Podman activation

  • native Podman with Docker unavailable;
  • all three agents;
  • supported amd64 and arm64 environments;
  • rootful/rootless and user-namespace behavior where supported;
  • networking, volumes, SELinux labeling, and exact cleanup;
  • NVIDIA CDI GPU attachment;
  • host-local Ollama, NIM, and vLLM;
  • real GPU-backed inference turns;
  • persisted identity, restart, rebuild, snapshot/restore, crash recovery, rollback, and name-reuse failure injection; and
  • installer/preflight and documentation evidence.

Protected E2E evidence must bind the exact PR head and current base. Stale stacked-base evidence is not sufficient. Protected E2E is approved and dispatched immediately when technically eligible; no additional authorization wait is required.

Review, labels, and release cadence

Scope boundaries

In scope:

  • buildless managed onboarding for all shipped agents;
  • complete immutable images and atomic all-agent publication;
  • driver-neutral lifecycle and transactional bootstrap;
  • Docker and native Podman providers;
  • amd64 and arm64;
  • snapshot, clone, rebuild, backup, restore, durable recovery, and exact cleanup;
  • Podman GPU access and host-local Ollama, NIM, and vLLM;
  • a socket-free MXC-style contract fixture; and
  • evidence-backed installer and documentation changes.

Out of scope:

  • arbitrary privileged commands or secret injection through startup profiles;
  • OpenClaw-only or Docker-compatibility-only Podman support;
  • production MXC enablement;
  • Kubernetes behavior changes beyond regression preservation;
  • any mutation in NVIDIA/OpenShell without separate explicit approval; and
  • claiming support for an untested runtime, host, architecture, GPU, or inference combination.

Definition of done

The epic closes only when the incremental stack has landed in order; Docker and native Podman launch OpenClaw, Hermes, and DCode through the same driver-neutral contracts; stock managed onboarding performs no Dockerfile build; Podman passes the complete multi-architecture GPU and Ollama/NIM/vLLM matrix; lifecycle and crash recovery are durable; unsafe name-only deletion is impossible; protected exact-head E2E is green; and installer/support documentation matches the shipped evidence.

Metadata

Metadata

Assignees

Labels

area: architectureArchitecture, design debt, major refactors, or maintainabilityarea: e2eEnd-to-end tests, nightly failures, or validation infrastructurearea: onboardingOnboarding FSM, provider setup, sandbox launch, or first-run flowarea: packagingPackages, images, registries, installers, or distributionarea: sandboxOpenShell sandbox lifecycle, runtime, config, or recoveryenhancementNew capability or improvement requestintegration: dcodeLangChain Deep Code integration behaviorintegration: hermesHermes integration behaviorintegration: openclawOpenClaw integration behaviorplatform: containerAffects Docker, containerd, Podman, or images

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions