Caddy publication validation failures

Caddy publication covers the Caddyfile's own content. Changing assets, secrets, users or namespace-writer ownership does not invalidate an unchanged published Caddyfile. A publication error stops deployment before activation; it does not by itself establish a running-service or TLS outage.

Recognize the issue

The validation issue points to /hosts/<index>/docker/service_containers/caddy_mask_proxy/config_ref with code caddy_mask_proxy.publication. The index is zero-based; identify the current host and its existing config_ref in authoritative assets.

Diagnostic	Meaning	Next action
Caddyfile content differs from its published hash	The Caddyfile body changed after publication.	Review the intended Caddy edit, then prepare and publish through the forms below.
No published release, incomplete publication, or invalid marker/JSON/properties	The Caddyfile has no readable publication marker.	Review the complete existing document, then prepare and publish it.
Namespace inputs changed during Caddy planning	A document changed while this deployment loaded its inputs.	Retry after the concurrent edit completes. Unchanged Caddy content needs no republication.
Caddy document changed since preparation	Someone edited the same Caddy document after it was prepared.	Prepare again and review the current document.
Caddy publication hash or source versions differ	This is the retired whole-namespace version check from an older Enclavr build.	Update the checkout and relaunch `./enclavr`. Current code accepts valid existing markers without republishing.

Access errors under caddy_mask_proxy.config are separate. Check the existing reference and accepted identity's read scope. A denied lookup does not prove that the document is absent.

What is checked

The first line, # enclavr-release-v1 ..., records the SHA-256 of the remaining Caddyfile bytes. An edit to those bytes, including whitespace, requires a new publication. Historical assets/secrets/users versions in older markers are ignored; new markers contain only the Caddyfile hash. Valid existing markers remain usable without a migration or an extra OpenBao version.

Deployment still validates current host settings, resolves current protected inputs, and refuses a snapshot that changes while it is being loaded. Caddy's configuration is validated before activation. Publication still checks the current namespace writer and protects the Caddy document itself against concurrent edits. None of these checks pins deployment to historical core document versions.

Discover the writer and finish pending edits

Run the CLI command ./enclavr namespace status. Use the declared namespace-writer host and its existing accepted connection. Writer ownership is separate from live OpenBao leadership. Finish the intended Caddyfile edit through Config → Edit config in ./enclavr before preparation.

Run the following forms on the writer as the account that owns its accepted connection. The selected Caddy host may be a different machine. Missing or denied custody must be resolved with its owner; do not create another document, role, credential, mount, seal or CA to bypass this error.

Prepare and publish in the TUI

Launch ./enclavr → Config → Prepare Caddy publication.
Select the exact affected Caddy host. Its current config_ref selects the existing document. Press r to review, then y to confirm preparation.
Open Config → Publish Caddy publication, select the same host, press r to review, then y to confirm publication.

Preparation saves a protected snapshot internally. It does not write OpenBao. The forms manage the snapshot; no request JSON, credential input or manual candidate-file editing is required. Plans show the target and effect while keeping protected Caddyfile content concealed. A document may serve several hosts, so review its complete intended change before publishing.

Publication updates only the existing selected Caddy document with compare-and-swap and verifies read-back. Other item metadata is preserved. An unchanged, already-published Caddyfile succeeds without another item version. An unrelated assets, secrets or users edit between preparation and publication does not require starting over.

After an uncertain write response, retry Publish Caddy publication for the same host. The retained draft allows an already-accepted identical publication to succeed without repeating the write. A real intervening Caddy edit requires fresh preparation. A changed writer, cluster, host reference or local draft is also rechecked before applying the reviewed operation.

The equivalent CLI commands open the same forms:

./enclavr namespace caddy prepare --namespace <namespace> --host <hostname>
./enclavr namespace caddy publish --namespace <namespace> --host <hostname>

Both flags are optional. The accepted connection supplies the namespace, and the form supplies the enabled host choices. Confirmation happens inside the form; --yes cannot bypass review.

Deploy and verify

Publication does not restart Caddy. On each serving host using the changed document, run the CLI command:

./enclavr host deploy --only caddy-mask-proxy.deploy --yes

Deployment selects the machine's exact current hostname. A successful host plan alone does not prove acceptance of the protected execution payload; deployment checks that payload before adapters and refreshes it immediately before the Caddy action.

Verify active routes, container health, TLS and intended upstream responses on every affected host. Preserve certificate identity and persistent volumes. Repeat the unchanged targeted deployment and confirm no unnecessary rebuild, recreation or restart. Publication success and live rollout acceptance are separate outcomes.

Continue with Update a Caddy mask, Plan, deploy, and verify, or OpenBao roles and custody.