Most tools that promise to manage your existing workloads ask for one thing first: redeploy everything through us. That is the wrong price. A re-rollout against production carries a real downtime window, a real rollback path, and a real chance the new apply diverges from what was already running.
ZopDay takes the opposite stance. In ZopNight v1.17.0, it imports the Helm apps already running on your clusters into its project, environment, and service model, with the cluster kept strictly read-only during import. Zero redeploy. We call this read-only adoption: you get a management layer over live workloads without touching the workloads themselves.
Adoption tools ask you to redeploy, and that is the wrong price to pay
The standard adoption playbook is rip-and-replace. You hand the tool your charts, it re-applies them through its own pipeline, and only then does it claim to manage the app. That step is where teams stall.
A re-rollout mutates running state. If the new apply differs from the live release, even by a values default or an injected sidecar, the pod restarts and behavior shifts. The blast radius is the whole service. So the team that most needs a control plane, the one running critical apps in production, is the team least willing to risk one.
The result is a standoff. The workloads that would benefit most from a single management model are the ones nobody dares migrate. Adoption becomes a project, not a click.
That standoff has a cost beyond delay. Teams keep running the same workloads under two mental models at once: the live Helm releases on the cluster, and the management tool they never finished onboarding. Drift between those views grows, because the redeploy gate keeps the second model permanently out of date.
ZopDay reads your Helm releases instead of rewriting them
Read-only adoption inverts the order of operations. ZopDay does not apply anything to bring a workload under management. It reads.
Helm already stores everything needed. Each release records its name, namespace, chart, version, and the values it was rendered with, kept as release metadata in the cluster. ZopDay reads that metadata and reconstructs the hierarchy: which releases belong to a service, which services form an environment, which environments roll up to a project.
Mapping is a read plus a transform, never a write. No helm upgrade, no kubectl apply, no rollback. The cluster sees list and get calls, nothing else. The running pods never learn that an import happened.
Because nothing is applied, there is no rollout to fail. That property is what makes the import safe to run against the same clusters you would never re-deploy on a whim. The same read-only discipline shows up in read-only MCP servers for infrastructure: read access first, mutation only behind an explicit gate.
Read-only is the trust anchor, not a feature footnote
The read-only guarantee is not a nice-to-have. It is the reason the feature is usable at all. When a tool cannot write to your cluster, the worst case during import is that it reads the wrong thing and you discard the result. The worst case during a redeploy is an outage.
That difference changes who can say yes. A platform team can run read-only adoption against production without a change-management ticket, because there is no change. The trust anchor is mechanical, not a promise in a doc.
| Dimension | Rip-and-replace migration | Read-only adoption |
|---|---|---|
| Cluster action | re-applies charts through the tool | list and get only, no writes |
| Workload impact | pods restart, behavior can shift | running pods untouched |
| Worst case | failed rollout, downtime window | wrong read, discarded |
| Approval needed | change-management ticket | none, nothing changes |
| Time to managed | a migration project | an import pass |
This is the same instinct behind a blast radius check: the safest action against running infrastructure is the one that cannot break it.
It works as a control plane over running apps, and breaks past that boundary
Read-only adoption works when your goal is a management model over workloads that already run correctly. You want to see them as projects, environments, and services, and act on them later through ZopDay. The import gives you that view without a re-rollout.
It breaks when you expect the import to do more than read. It will not reconcile drift, because reconciling means writing. It will not repair a release that is already broken, because repair means applying. And the release note scopes the path to Helm, so raw manifests, Kustomize, and operator-managed resources may sit outside it until that coverage is stated.
So treat the import as a starting line, not a finish. It puts your running apps under a single model the way solid infrastructure-as-code practices put your declared state under one. From there you choose what to change. Read-only adoption earns the trust to manage your workloads precisely because, on the way in, it changes nothing.
