Networking

Fleetdock has two distinct network paths: the agent → Manager control path and the Manager → database data path. Getting these right is the most common source of setup friction.

Agent to Manager (outbound)

The agent connects outbound to the Manager at FLEETDOCK_PUBLIC_URL. It enrolls, heartbeats, and polls for operations over that connection — the Manager never dials back to the agent to run operations.

• In production, FLEETDOCK_PUBLIC_URL should be an HTTPS URL on port 443 behind your reverse proxy.
• It must be reachable from every server you connect. Do not use localhost unless the agent runs on the same machine as the Manager.

Manager to database (direct)

For live database administration and external instances, the control plane connects directly to the database's host and port:

• External instances are reached at their configured host and port.
• Managed instances are reached at their server's address (reported automatically by the agent) on the instance's published port.

Ensure the database port is reachable from the host running the Manager (security group / firewall rule). Prefer private network paths over the public internet.

External applications via Fleetdock Gateway

For applications outside your private network, use the Fleetdock Gateway (HAProxy) instead of publishing database ports directly to the internet. The control plane assigns one public TCP port per database, enforces CIDR allowlists at HAProxy, and keeps the endpoint stable across migrations.

External app → gateway.example.com:15432 → HAProxy → server.address:instance.port → Database

Public access is disabled by default. Enable it per database from Connectivity on the database page. See External database access for setup, application credentials, and TLS behavior.

Ports

DNS and HTTPS

• Point a DNS record at the Manager host. The bundled Caddy obtains a certificate automatically; without a domain the installer uses an <ip>.sslip.io name, which also gets a real certificate.
• One hostname is enough. The dashboard and API share an origin because one process serves both, so there is no API subdomain, no CORS to configure, and nothing about your hostname compiled into the dashboard — changing your domain never requires a rebuild.
• The gateway reuses that same hostname; it speaks raw TCP on its own ports and needs no record of its own. The exception is a CDN-proxied record (Cloudflare's orange cloud), which passes 80/443 only — point a grey-clouded gw.example.com at the host and set FLEETDOCK_GATEWAY_PUBLIC_HOST.

See Manager installation for a Caddy example.

Firewalls and NAT

• Allow inbound 80 and 443; deny direct access to 8080 and 5432. Leaving 8080 reachable also lets a client spoof X-Forwarded-For and bypass login rate limiting.
• When external database access is enabled, also open the gateway port range.
• Because the agent connects outbound, agents behind NAT generally work without inbound rules — but the database ports the Manager needs for live admin/backups must be reachable from the Manager.

Private networks and public IP

You do not need a public IP on every database server. What matters is that:

1. Each server can reach FLEETDOCK_PUBLIC_URL.
2. The Manager can reach the database ports it administers.

A private network (VPC peering, WireGuard, or a LAN) satisfies both without exposing database ports to the internet.

Local development

For LAN/VM development — for example the Manager on your Mac and an agent in a Ubuntu VM — set FLEETDOCK_PUBLIC_URL to your host's LAN IP, not localhost:

FLEETDOCK_PUBLIC_URL=http://192.168.x.x

Multipass and other VMs

Use the host-reachable IP instead of localhost. Discover an address the VM can reach:

# On macOS — find your host's LAN IP (often on en0):
ipconfig getifaddr en0

# From inside the VM — confirm the host is reachable on the API port:
curl -fsS http://<host-ip>:8080/healthz

Then set FLEETDOCK_PUBLIC_URL=http://<host-ip>:8080 on the Manager and use the same URL in the install command. Values like <host-ip> are environment-specific — do not hardcode a fixed gateway address, as it varies between machines and networks.

Docker networking

Within the Compose stack, services reach each other by service name (backend, frontend, postgres) on the internal Docker network — that is why the Caddy example proxies to backend:8080 and frontend:3000. Published ports (8080, 3000) are for access from the host; keep them unpublished in production and route through the proxy.