Servers

Servers are the physical or virtual machines that DaoFlow deploys to. DaoFlow connects to servers over SSH and manages Docker containers remotely.

Server Registration

Via Dashboard

1. Navigate to Servers in the sidebar
2. Click Add Server
3. Enter: name, host IP, SSH port, and SSH key path
4. DaoFlow collects the server's public SSH host keys and shows their algorithms and SHA-256 fingerprints
5. An owner or admin reviews and approves one exact key in the server's Identity tab
6. DaoFlow then performs strict SSH readiness checks and detects Docker/Compose versions

Via CLI

daoflow server add \
  --name edge-vps-1 \
  --host 203.0.113.42 \
  --region us-west-2 \
  --ssh-user deploy \
  --ssh-key ~/.ssh/daoflow_ed25519 \
  --yes

Raw SSH private keys entered during server registration are moved into the managed SSH key inventory and the server stores only the inventory reference. Operators can also pre-create a managed key and reuse it across servers:

daoflow access-assets ssh-key create --name prod-deploy --private-key-file ~/.ssh/daoflow_ed25519 --yes
daoflow server add --name edge-vps-1 --host 203.0.113.42 --ssh-key-id key_123 --yes
daoflow access-assets ssh-key attach --key-id key_123 --server-id srv_123 --yes
daoflow access-assets ssh-key detach --server-id srv_123 --yes

Registration never trusts a newly discovered host key automatically. Remote SSH and SCP work stay blocked until an owner or admin approves the exact algorithm, public key, and SHA-256 fingerprint for the server's team.

For docker-swarm-manager targets, DaoFlow also persists a Swarm topology snapshot in server metadata. DaoFlow uses that persisted topology to keep target kind and cluster context visible in CLI and dashboard inspection flows, and compose-backed deploy or rollback execution now runs through docker stack semantics on those managers.

Connectivity

DaoFlow uses SSH to connect to managed servers. Requirements:

• SSH access with key-based authentication
• Docker Engine 20.10+ installed
• Docker Compose v2+ installed
• User in the docker group (or sudo access)

SSH Key Setup

# Generate a key pair for DaoFlow
ssh-keygen -t ed25519 -f ~/.ssh/daoflow_key -N ""

# Copy the public key to your server
ssh-copy-id -i ~/.ssh/daoflow_key.pub user@your-server

SSH Host Identity Approval

DaoFlow treats the server's SSH host key separately from the private key it uses to authenticate. During registration, it uses a bounded public-key scan to collect untrusted host-key material. The scan does not grant trust and does not send the configured private key.

An owner or admin must open the server's Identity tab and approve one displayed algorithm, public key, and SHA-256 fingerprint. DaoFlow stores the approved key only within that team and writes it into its own isolated known_hosts store. Every SSH and SCP command then uses that store with StrictHostKeyChecking=yes and host-key updates disabled.

DaoFlow accepts modern Ed25519, ECDSA, and RSA host keys. It does not accept obsolete DSA host keys for enrollment or approval.

If a later scan finds that the approved key is absent, or SSH reports a mismatch, DaoFlow fails closed before it sends credentials or commands. Replacing a host key is a separate rotation action: the approval screen shows both the current and new fingerprints, and DaoFlow records the old/new pair in the audit trail. Private host keys are never stored.

Health Checks

DaoFlow monitors server readiness with recurring checks:

Check	What It Verifies
SSH Connectivity	Can connect over SSH
Docker Available	Docker daemon is running
Compose Available	Docker Compose is installed

Readiness checks run at a configurable interval using SERVER_READINESS_POLL_INTERVAL_MS (default: 60000) only after a remote server has an approved host identity.

Server metrics are collected separately under each server's monitoring policy. DaoFlow stores recent CPU, memory, root-disk, Docker-disk, and network samples, evaluates warning and hard thresholds, and sends rate-limited transition and recovery notifications. Monitoring is read-only: it never cleans, restarts, cancels, or patches a server automatically.

daoflow server-metrics --server srv_abc123 --monitoring --since 24h --json

Checking Server Health

# Quick status
daoflow status --json

# Full diagnostics
daoflow doctor --json

{
  "ok": true,
  "data": {
    "servers": {
      "summary": {
        "totalServers": 1,
        "readyServers": 1,
        "attentionServers": 0,
        "blockedServers": 0,
        "pollIntervalMs": 60000,
        "averageLatencyMs": 42
      },
      "checks": [
        {
          "serverName": "production-vps",
          "serverHost": "203.0.113.10",
          "targetKind": "docker-engine",
          "swarmTopology": null,
          "sshReachable": true,
          "dockerVersion": "24.0.7",
          "composeVersion": "2.23.0",
          "checkedAt": "2026-03-20T22:29:30.000Z"
        }
      ]
    }
  }
}

When a target is a Swarm manager, swarmTopology exposes the persisted cluster snapshot:

• cluster identity (clusterId, clusterName)
• default namespace for future stack grouping
• node membership with manager/worker roles, manager status, availability, and reachability
• safe summary counts for managers, workers, active nodes, and reachable nodes

Swarm management support:

• topology refresh reads docker node ls --format json from the manager and persists the observed snapshot
• node availability plans and updates use docker node update --availability
• service scale plans and updates use docker service scale
• compose-backed deploys and rollbacks use docker stack
• readiness must be probeable through published ports
• internal-network readiness probes remain unsupported for Swarm execution

Server Operations Hub

Each server has an operations page at /servers/:id. The hub records every resource check, cleanup preview, cleanup run, patch plan, and host terminal session as a durable server operation with append-only logs.

Resource Inspection

The resource check collects host CPU load, memory use, root disk use, Docker reachability, and Docker disk usage. It creates a resource_check operation and stores the latest snapshot for the server detail page.

daoflow server ops resources --server srv_prod --json

Cleanup

Cleanup is preview-first. Operators must create a recent cleanup_preview before DaoFlow accepts a cleanup_run. The run path only executes safe Docker prune commands by default:

• stopped containers
• dangling images
• build cache

Unused Docker volumes are excluded unless --include-volumes is supplied.

daoflow server ops cleanup --server srv_prod --dry-run --json
daoflow server ops cleanup --server srv_prod --yes

Patch Planning

Patch planning is non-mutating. DaoFlow detects the host package manager where possible and records a patch_plan operation with available package updates. Applying patches remains outside this flow.

daoflow server ops patch --server srv_prod --json

Swarm Management

Swarm operations are recorded through the same durable operations hub. Refresh topology records the observed manager and worker state. Node availability and service scale commands support --dry-run for a recorded plan and require --yes for live changes.

daoflow server ops swarm refresh-topology --server srv_prod --json
daoflow server ops swarm node availability --server srv_prod --node worker-a --availability drain --dry-run --json
daoflow server ops swarm node availability --server srv_prod --node worker-a --availability drain --yes
daoflow server ops swarm service scale --server srv_prod --service stack_api --replicas 3 --dry-run --json
daoflow server ops swarm service scale --server srv_prod --service stack_api --replicas 3 --yes

Host Terminal

Host terminal access is separate from service container terminals. The web UI opens host shells via /ws/host-terminal, records server.terminal.open and server.terminal.close, and requires the exceptional terminal:open scope.

Managed Tunnels

Managed tunnels track external route providers separately from service domains. Operators can register a tunnel, sync observed hostnames to services, rotate stored provider credentials, and delete stale tunnel records from the dashboard or CLI.

daoflow tunnels list --json
daoflow tunnels create --name edge --domain app.example.com --yes
daoflow tunnels sync --tunnel-id tun_123 --route app.example.com=web:3000 --yes

Service-domain observation still works without managed tunnels. The tunnel inventory gives operators a safer place to record what the external provider is currently exposing.

Access Assets

The Settings operations tab includes reusable access assets:

• managed SSH keys with encrypted private key material, safe fingerprints, default SSH user metadata, rotation timestamps, and attach/delete actions
• custom certificate assets with encrypted certificate, private key, and CA chain material plus safe subject, issuer, expiration, domain, and fingerprint metadata; CA certificates can be bound to one team's self-hosted Git provider without changing global TLS trust

Read surfaces never return private keys, certificate bodies, or encrypted blobs. Write paths create audit entries for create, rotate, attach, and delete actions. Managed SSH key rotation does not expose the old key and future server connections resolve the latest encrypted key material through the asset reference.

Server Permissions

Access to server operations requires specific scopes:

Action	Required Scope
List servers	server:read
View server health	server:read
View operation logs	server:read
View managed tunnels	server:read
View access assets	server:read
Register server	server:write
Approve or rotate SSH host identity	server:write (owner or admin)
Update server config	server:write
Cleanup and patching	server:write
Manage Swarm	server:write
Manage tunnels	server:write
Manage access assets	server:write
Open host terminal	terminal:open
Remove server	server:write