Restricted-network and offline installations
Stage release artifacts, images, trust, and update paths without public runtime access.
An offline installation operates its control plane and owned fleet without runtime access to public package or image services. Required artifacts and trust material must be staged through an approved import process.
Build an artifact inventory
Obtain the pinned release from Deployment portal → Infra → Self-hosted releases. Stage its artifacts from an administrative terminal on the approved import host. After startup, inspect imported releases at Installation settings → Artifacts.
For each pinned release, retain the control-plane images, agent packages, deployment bundle, administrative utility, and checksummed release manifest. Include supported guest images and any guest-agent packages used by initialization or backup hooks.
An exported droplet image can still expect public package mirrors, NTP, DNS, or licensing endpoints. Inspect those dependencies before approving the image for an isolated network. A successful import is not proof that its first boot can complete offline.
Import and verify
Transfer artifacts through the organization's approved media or staging system. Verify signatures against separately trusted release keys and compare checksums after transfer. Publish the artifacts to the internal registry or repository referenced by the deployment configuration.
Do not disable signature verification because the installation cannot reach a public key endpoint. Stage the trust bundle and its documented validity instead. Keep a process for replacing expired signing and TLS material.
Local infrastructure dependencies
Provide internal DNS, time synchronization, certificate issuance or trust, identity-provider access, database services, and backup destinations. Record the recovery order when several of those services depend on the same hardware fleet.
Use internal OS repositories for patching. A patch inventory scan against an unreachable public mirror can fail without establishing that a host has no available security updates.
Features requiring external paths
The hosted Connector requires its configured outbound HTTPS path. It remains disabled in a fully isolated installation. Local droplets, owned storage, mesh networking, and local automation do not require hosted capacity.
External email, public webhooks, public DNS delegation checks, and remote backup destinations require explicit connectivity or an internal replacement. Configure notifications through a path that remains reachable during an infrastructure incident.
Upgrade rehearsal
Rehearse an upgrade using only staged artifacts. Test image pulls, migrations, agent updates, guest boot, key access, and restore from the internal backup archive. Capture missing dependencies before the production window.
Retain the previous supported release and its recovery artifacts until the upgrade is validated. Direct downgrade can still be unsupported after schema changes; follow control-plane upgrades and backup restoration.
Operational evidence
Export diagnostics through a reviewed support-bundle process. Keep tokens, private keys, guest data, and unrelated audit records outside the bundle. Record the installed release manifest so an offline support investigation can identify the exact artifacts in use.