Skip to main content

Support Access and the Air-Gap Support Bundle

This page explains how Control Zero support reaches a self-managed or air-gapped installation and what your platform team controls.

TL;DR: there is no inbound support channel. Control Zero cannot open a connection into your network and holds no account on your instance; a Control Zero employee can sign in only if your own admin invites them as a member, and then has exactly that member's access, like any other member. Through the support process itself, the only things support ever receives are artifacts you generate and review — the support bundle (redacted as described below, and yours to review before it is sent), the install log, and the license install_id exchange — and, after installation, the only vendor-produced files that enter your environment are a signed license keyed to your install_id and any upgrade package you choose to carry in.

Part one: how support reaches your data​

Support cannot reach in​

Control Zero has no phone-home and no vendor channel into a self-managed deployment: the stack's own HTTPS endpoint serves your users, and nothing in it listens for Control Zero. Nothing in the stack contacts Control Zero: the only outbound requests are the ones you configure, such as the gateway forwarding calls to your model providers, and license validation is offline. Control Zero is not on-site in an air-gapped network.

There is no support-login, support-impersonation, or remote-session endpoint that grants a vendor account access to a customer org. Support access is limited to the customer-driven exchanges below.

What support actually receives​

Through the support process, support receives only what an operator on your side explicitly produces and sends (a member seat you grant a Control Zero employee is separate, and carries that member's access):

  1. The redacted support bundle — generated locally by you.
  2. The install log — /tmp/cz-install-*.log, included only when the problem happened during installation.
  3. The license exchange — you run czctl setup on the host, which prints an install_id; you send that install_id to Control Zero by any channel, and Control Zero returns a signed license file that you import with czctl license import. After installation, the vendor-produced artifacts that enter the environment are the license file and any upgrade package you carry in; the license is a signed grant keyed to your install_id, not a data channel.
  • Review the bundle before it leaves your network; its redaction has limits. In the air-gap package's tools/support-bundle.sh, the .env file is redacted fail-safe: every assignment's value is replaced with <REDACTED> unless its key is on a short allowlist of known-non-secret settings. Comment lines are copied unchanged, so a commented-out secret stays in the bundle. Logs and container inspect output are scrubbed best-effort against patterns for Control Zero API keys, license tokens, bearer tokens, password/secret/key/token assignments and credentialed URLs, keeping only a short prefix so support can tell values apart. A secret in a format those patterns do not recognise can remain. docker-compose.yml is included as it is on disk, so keep secrets in .env rather than writing them into the compose file. czctl support-bundle applies a narrower pattern set and does not include the .env file. Review the bundle before it leaves your network.

Every one of those three exchanges is initiated and gated by you:

  • You run the command. Support cannot trigger bundle collection; the operator runs czctl support-bundle on the host.
  • You review the output before it leaves. Open the bundle and confirm nothing sensitive remains: env-redacted.txt, docker-compose.yml and the logs from the air-gap package's script, or the logs from czctl support-bundle. If in doubt, do not email it.
  • You choose the channel. The bundle is carried out of the air-gapped network and sent to your Control Zero contact; the install_id may travel "by any channel".

What is recorded​

There is no vendor support session to audit: Control Zero has no route into your instance. A Control Zero employee your admin invites as a member holds an ordinary member seat, which you granted and can revoke. What is recorded is on your side:

  • The deployment keeps its own license state: the install_id, the last-accepted license's sequence, id and issue time, and a clock high-water mark live in the host state file, with a mirror in the deployment's database. czctl backup includes both. Once the state file and data volumes are deleted, this state can be recovered only by restoring one of your own backups.
  • Bundle generation is a local, operator-run export. The act of generating a support bundle is not written to the product's audit log. Record the handover in your own change-management process.

What is technically impossible for support to do​

  • Connect into your environment on its own — there is no vendor channel and no phone-home. A Control Zero employee reaches your instance only through a member seat your admin grants, over the same endpoint as any member.
  • Put a license into your deployment — Control Zero issues licenses, but one takes effect only when you import it with czctl license import. A self-managed deployment accepts only licenses that verify against Control Zero public keys compiled into the product (legacy shared-secret licenses are refused unless you explicitly re-enable them), and no key that can sign such a license is on your box.
  • Recover your deployment's identity after you wipe it — the install_id and license state go with the state file and data volumes. Only a backup you hold can bring them back, and a re-install without one starts clean.

Self-managed and air-gapped customers receive the support-bundle procedure in the lifecycle runbook that ships inside their deployment package.