Overview
Open WebUI exposed a real Ota lifecycle boundary.
This was not mainly a parsing or contract-shape repo. The contract was already strong enough to model:
- source-checkout verification
- packaged native runtime through
uv run open-webui serve - frontend development runtime
- default Docker Compose runtime
What the repo exposed was operational truth after proof:
- a successful native proof still left a host workload alive
- the first cleanup fix then widened too far and treated a Compose-owned runtime as the same class of host workload
That made Open WebUI a valuable pressure repo.
It forced Ota to get more precise about cleanup ownership instead of treating all successful runtime proof as one generic teardown problem.
The current pressure contract pins released Ota v1.6.24. Its latest green matrix run proves
the release surface at the exact contract and workflow revision linked below.
What Open WebUI exposed in Ota
This repo exposed four meaningful weaknesses.
1. proof success was weaker than it looked
The first issue was not that runtime proof failed.
It was that runtime proof succeeded and still left the native workload alive afterward.
In this repo, the packaged native workflow launches:
serve:native:
launch:
kind: command
exe: uv
args:
- run
- open-webui
- serve
- --host
- 0.0.0.0
- --port
- "8080"
Ota proved that workflow, but the launched process tree was still alive after proof completed.
In GitHub Actions, that surfaced through setup-uv post-job cleanup, which blocked while the uv cache was still in use.
That was an Ota gap.
If proof succeeds but leaves behind repo-owned runtime state that later breaks CI cleanup, the proof surface is still incomplete.
2. native service cleanup widened past its real ownership boundary
The first core fix made Ota clean selected native service workloads after successful proof.
That was directionally correct, but Open WebUI immediately exposed the next boundary.
The Docker workflow uses a native task shape to launch Compose:
compose:up:
launch:
kind: command
exe: docker
args:
- compose
- up
That is a native command surface, but it is not the same kind of ownership as a host-managed runtime like uv run open-webui serve.
The first cleanup widening treated it as if Ota should reclaim the resulting listener directly like a host workload. That was too broad.
This repo made the distinction unavoidable:
- host-owned native process workload
- adapter-owned Compose runtime
Those are not the same cleanup family.
3. contract-owned CI bootstrap truth still matters
The workflow was already using ota-run/setup with contract mode, which is the right direction.
The contract bootstrap truth also had to stay aligned so the setup surface consumed the same install story the repo intended to publish.
That was not the original runtime bug, but it was still real governance drift.
A pressure repo should not say one thing in ota.yaml and effectively rely on another in CI.
4. mixed-runtime repos punish vague lifecycle ownership
Open WebUI combines several legitimate paths:
- Python ownership through
uv - Node ownership for frontend/build work
- a packaged native runtime
- a frontend-only runtime
- a Docker Compose runtime
That combination matters because it punishes sloppy lifecycle assumptions quickly.
If Ota collapses all of that into “run a process and then stop something later,” the product boundary is still too weak.
What had to be fixed in Ota core
Open WebUI led to three real Ota fixes.
proof success-path cleanup for host-owned native workloads
Ota's proof teardown was tightened so it no longer stops only the outer ota up process.
It now also cleans selected native host service workloads that Ota actually owns for the chosen workflow.
That closes the gap where proof succeeded but left the packaged native runtime process tree alive after completion.
cleanup narrowing for Compose-owned runtime lanes
The first cleanup fix exposed a second Ota boundary, and that also had to be corrected.
Ota now skips that host-workload cleanup path for Compose-owned native service tasks such as docker compose up.
That matters because Compose runtime cleanup belongs to adapter-owned repo cleanup surfaces, not to host-process workload reclamation.
Without that distinction, Ota was overreaching past the lifecycle it actually owned.
proof cleanup now respects workflow-owned active execution scope
The last failure was subtler.
Docker proof itself was healthy, but teardown still failed because cleanup hit Ota's active execution registry and treated the proved compose:up service task as an unrelated blocker.
That was also an Ota gap.
The selected workflow had launched that runtime, proved it, and was now trying to clean up its own owned execution surface.
Ota now scopes workflow cleanup to the active execution ownership actually selected by the proof lane.
That keeps ordinary ota clean strict while allowing proof teardown to reclaim the workflow-owned execution it just created.
What changed in the contract
The final contract is stronger because it uses cleaner contract-owned truth in the same places where the product now got stronger.
The packaged native workflow stays explicit:
native:
intent: local_development
prepare:
task: setup:env
setup:
task: setup
run:
task: serve:native
readiness:
surfaces:
- native-web
exposes:
- surface: native-web
The Docker workflow stays separate instead of pretending it is the same runtime family:
docker:
intent: packaged_runtime
run:
task: compose:up
readiness:
surfaces:
- docker-web
exposes:
- surface: docker-web
That separation matters because the repo is not publishing one runtime claim.
It is publishing at least two different runtime claims with different lifecycle owners.
The contract bootstrap truth was also aligned so CI, humans, and agents all read the same Ota install intent from the repo contract.
The branch carries a 1.6.24 contract floor and structured bootstrap source, so CI, humans,
and agents use the same released Ota surface.
What the matrix now proves
The matrix does more than parse the contract, but each OS lane has an explicit scope.
All three lanes run ota validate, capture ota doctor, show task and workflow usage, inspect
execution topology, and dry-run the verify task and native workflow. They also dry-run the
finite backend-format and frontend-test tasks.
Ubuntu is the proof lane. It additionally runs the full frontend verification aggregate, the
finite backend-format and frontend-test tasks, then proves both the packaged native runtime and
the Docker Compose runtime. It also dry-runs the Docker workflow before executing its proof lane.
macOS and Windows are deliberately audit-only: they do not claim task execution, native runtime
proof, Compose proof, or Docker-workflow coverage. That is an explicit matrix boundary, not an
implicit gap hidden behind a green OS label.
The contract also models the frontend development runtime and the Playwright-enabled Compose
overlay. Neither is runtime-proved by this matrix. GPU and API-exposure overlays remain outside the
declared pressure scope. Those are modeled paths, not evidence that every Open WebUI runtime family
has been proved.
The green v1.6.24 matrix run
proved the tightened lifecycle boundaries on Ubuntu:
- the native proof succeeded and cleaned up its host-owned runtime
- the Docker Compose proof succeeded and tore down without tripping over its own active execution record
- the contract-owned bootstrap, real verification tasks, and runtime-proof lanes agreed
Why this repo mattered
Open WebUI mattered because it is exactly the kind of repo that exposes whether a readiness system really understands lifecycle ownership.
It is not enough to support:
- Python
- Node
- a native service task
- a Compose runtime task
The product also has to know which cleanup responsibility belongs to which path.
This repo forced Ota to answer that cleanly:
- proof success should not leave host-owned native workloads behind
- Compose-owned runtimes should not be reclaimed as if they were the same class of host process
That is not cosmetic polish.
That is operational trust.
If Ota says a runtime path was proved, it should also leave the repo and CI environment in a truthful post-proof state.
Remaining boundary
The pressure pass also exposed a separate dependency-hydration limitation. Open WebUI's committed
uv.lock was stale, and a normal project uv sync can rewrite it before an unrelated verification
task inspects the working tree. The contract avoids that mutation for the upstream Ruff formatting
gate by using an isolated uvx tool bootstrap.
That is a truthful contract choice, not a complete Ota solution. Ota still needs a typed uv
frozen-lockfile posture for dependency hydration so a contract can require uv to refuse stale lock
state before execution rather than relying on task-specific avoidance. This remains an Ota product
gap; it was not hidden to make the matrix green.
Links
- Upstream repository: Open WebUI
- Pressure branch contract: open-webui
ota.yaml - Matrix workflow: test-ota-contract-matrix.yml
- Green release-proof matrix: #29758665089
Originally posted here: https://ota.run/blog/pressure-testing-ota-on-open-webui-2p8w
