Server networking, SSH, Docker, and Swarm

Server-level tools always require a selected Autodisc Server that belongs to the active account. A missing Server never falls back to Autodisc's shared control-plane host.

Access behavior and command examples were checked 2026-07-13. Commands are read-only diagnostics and must be run in the terminal of your own Server.

Networking

Autodisc may assign IPv6, private network addresses, and an optional public IPv4 to a Server. The dashboard can show the address, firewall, ports, routes, certificates, and request summary for that Server. It deliberately hides physical-host addresses, fleet credentials, internal placement, and neighboring tenants.

Public IPv4 is optional and billed while reserved, including while the Server is stopped. Releasing it changes the quote and may change the address on a later start. Do not publish a DNS record until the dashboard reports the Server and address as ready.

SSH access

Add public keys under Settings → SSH Keys, then assign them only to Servers owned by the active account. Managed fleet/bootstrap keys are reserved and do not appear in customer lists. Key create, update, delete, and assignment actions are role-gated and audited.

Use the browser terminal when it is enabled, or connect to the exact username, address, and fingerprint shown on the Server. Never paste a private key, provider token, or unredacted secret into support or the AI assistant.

If enrollment or host attestation is incomplete, host access remains unavailable. Do not work around that state with the legacy Remote Servers attachment form; managed Autodisc does not support bring-your-own-infrastructure.

Docker

The Docker page preserves container, image, network, volume, cleanup, log, inspect, and lifecycle workflows for the selected Server. Every call is scoped to that Server and account. Managed-service users can still operate their own workloads, but cannot inspect the shared Docker daemon or another account's containers.

To check Docker and Swarm state without changing it:

docker info --format '{{.Swarm.LocalNodeState}}'

Docker Swarm

Swarm is useful when two or more Autodisc Servers should run one replicated service, use overlay networking, or drain workloads away from a Server during maintenance. It is not required for a single Server or ordinary managed projects.

Initialize or join Swarm only through the selected Server/Swarm controls. Join tokens are sensitive and must not be copied into tickets or logs. Manager-only read checks are:

docker node ls
docker service ls

docker node ls and docker service ls require a Swarm manager. A worker or a Server whose Swarm is inactive will return an error; that does not grant access to the platform Swarm. Drain, promote, demote, remove, and scheduled lifecycle actions remain permission-checked, Server-scoped, and audited.

See Servers, pricing, and lifecycle for stopping, quota, and retained-resource charges.