different-ai/openwork commit 3573297, merged June 24 in PR #1819, added an OpenWork EE Helm chart, GHCR publishing workflow, runtime-config endpoint, readiness endpoint, admin allowlist seeding, and deployment docs.
For platform and buyer readers, the category consequence is practical: OpenWork is asking to be judged less like a local app experiment and more like deployable agent infrastructure with health checks, runtime configuration, migration hooks, and proof artifacts.
Facts
- The Helm chart documents
den-api,den-web, optional inference service, ConfigMap and Secret templating, ingress, migration hooks, health probes, and dependency-aware readiness probes. - The web app now exposes
/api/runtime-configwith no-store caching and/api/readychecks that fail when required API/auth configuration or upstream readiness is missing. - A same-day server commit f607914 moved per-workspace OpenWork config into a runtime SQLite DB and added "Validate Every Experience" rules around end-user proof.
Evidence
The strongest receipt is not a product slogan. It is the deployment surface itself: chart files, image publishing, readiness routes, runtime config, environment validation, migration bootstrap, and a repo rule that says outside-world behavior needs user-driven proof.
Context
This is a Project Maturity Check, not a broad agent-runtime pattern. The movement is that OpenWork's enterprise surface is becoming inspectable at deploy time, where operators ask whether configuration, health, migration, and recovery behavior can survive outside a developer laptop.
Limits
The evidence does not prove production adoption, customer use, or that the chart is stable. Watch whether later releases keep the Helm path, runtime DB migration, readiness checks, and fraimz proof loop green under real self-hosted upgrades.