Monitoring Plain VPS Docker Hosts With LogForge, Without Growing a Platform Team.

Plain VPS fleets are simple until they are not. One rented VM becomes three, a one-off Docker Compose service becomes a small production surface, and suddenly logs, restarts, disk checks, provider firewalls, and "which box is this container on?" become their own project.

You do not need to grow a platform team just to watch a few Docker hosts. Keep one LogForge Central somewhere stable and reachable. Then install one LogForge remote agent on each plain VPS Docker host, whether those servers live at Hetzner, DigitalOcean, Linode, Vultr, a regional provider, or a private rack.

The important part is the direction: each VPS phones home to Central. You avoid opening extra inbound LogForge ports on every rented server.

The Shape Of The Setup

The recommended setup has two pieces:

1. One LogForge Central. This is the dashboard, API, storage, auth, alerting, notifications, and agent enrollment service. Put it somewhere stable, backed up, and reachable from the VPS hosts.
2. One LogForge remote agent per VPS Docker host. The agent watches Docker, host metrics, container inventory, logs, and Docker events on that host, then sends telemetry back to Central.

The network shape should stay boring:

admin browser  --->  LogForge Central :8444/unicron
VPS host       --->  LogForge Central :9443
VPS host       --->  LogForge Central :9443
VPS host       --->  LogForge Central :9443

Agents connect outbound to Central on 9443. The LogForge dashboard and API live on 8444, and that port can stay limited to administrators, a VPN, a private mesh, or a bastion.

Your VPS hosts do not need inbound LogForge ports. They need outbound access to the Central agent mTLS endpoint.

Step 0: What You Need

On the Central machine:

• LogForge Central already installed with the public installer, Docker Compose, or another stable deployment method.
• Persistent storage for Central state and a backup plan for that storage.
• A reachable hostname, for example logforge.example.com.
• Inbound TCP 9443 from the VPS hosts that will run agents.
• Inbound TCP 8444 only from administrators, a VPN, a private mesh, or a bastion if you want remote dashboard access.

On each VPS host:

• Linux with Docker installed and running.
• SSH access.
• sudo access, or a user that can run Docker containers and mount the Docker socket.
• Outbound TCP access to Central on 9443.
• Access to the provider firewall, security group, or cloud firewall policy that controls the server.

For the examples below, replace this hostname with your real Central hostname:

logforge.example.com

Step 1: Inventory VPS Hosts And Choose Agent Names

Write down the Docker hosts you actually want LogForge to monitor. The unit is the host, not the app and not the container.

Choose stable, host-level agent names. Good names describe the physical or virtual host boundary:

web-nyc-01
api-prod-02
worker-fsn-01
staging-ams-01

Avoid names tied to a container release, Compose project, or app version. The agent should outlive normal application deploys because it monitors the VPS host itself.

Step 2: Confirm Docker And Central Reachability

SSH into each VPS and confirm Docker is available:

ssh deploy@203.0.113.31 'docker ps'

If your user is not in the Docker group yet, test with sudo and decide whether you want to keep using it:

ssh deploy@203.0.113.31 'sudo docker ps'

Then confirm the VPS can reach Central's agent mTLS port:

ssh deploy@203.0.113.31 'nc -vz logforge.example.com 9443'

If nc is not installed, use Bash's TCP check:

ssh deploy@203.0.113.31 "timeout 5 bash -c '</dev/tcp/logforge.example.com/9443' && echo 9443 reachable"

Repeat this for every VPS in your inventory. If 9443 fails, fix DNS, provider firewall rules, the Central host firewall, NAT, IPv6 routing, VPN policy, or tunnel configuration before you generate enrollment commands.

Step 3: Generate A Unique Enrollment Command Per VPS

In LogForge:

1. Open Settings.
2. Open Agents.
3. Click Enroll New Agent.
4. Use the stable host-level name you chose, for example web-nyc-01 or worker-fsn-01.
5. Set the Central URL to https://logforge.example.com:8444/unicron.
6. Generate the enrollment command.

The command should contain Central values like these:

CENTRAL_URL=https://logforge.example.com:8444/unicron
CENTRAL_MTLS_URL=https://logforge.example.com:9443
CENTRAL_WS_URL=wss://logforge.example.com:9443/unicron/api/agent/ws

Generate one fresh command for each VPS. Enrollment tokens are short-lived and each agent gets its own identity, trust volume, and name. Reusing one command across multiple servers makes inventory confusing and can cause identity collisions.

Step 4: SSH Into Each VPS And Run Its Command

Open an SSH session to the matching host:

ssh deploy@203.0.113.31

Paste the enrollment command generated specifically for that host. If your Docker access requires root privileges, run the generated Docker command with sudo or run it from a root shell.

Then confirm the agent container is running:

docker ps --filter "name=unicron-agent"
docker logs -f unicron-agent-web-nyc-01

Move to the next VPS, generate a new command in LogForge, and run that new command on that server. A clean fleet ends up with a one-to-one mapping:

Step 5: Verify Agents, Containers, And Logs

Back in LogForge, open the agents view and confirm each VPS appears online. Then check the Docker views for the signals you expected:

• Each VPS appears once, under the agent name you chose.
• Docker containers from that host appear in container inventory.
• Container logs are visible for the workloads you care about.
• Host metrics and Docker events continue updating after you restart or redeploy an app container.

If you use Docker Compose on the VPS, the agent should remain outside the application lifecycle. Recreating an app container should not recreate or rename the LogForge agent.

Provider Firewall Rules That Match The Shape

Keep provider firewall rules focused on Central reachability instead of opening every rented server.

On a simple Ubuntu Central host using UFW, that might look like:

sudo ufw allow from 203.0.113.31 to any port 9443 proto tcp
sudo ufw allow from 198.51.100.42 to any port 9443 proto tcp
sudo ufw allow from 192.0.2.0/24 to any port 9443 proto tcp
sudo ufw allow from 198.51.100.25 to any port 8444 proto tcp
sudo ufw status verbose

Replace those addresses with your real VPS egress IPs, provider private-network CIDRs, Tailscale subnet, WireGuard subnet, or admin ranges.

The generated agent command may publish local input ports such as 24224, 9880, 4317, and 4318 on the VPS host. Those are useful for local Fluent Bit and OTLP inputs. Do not add provider firewall inbound rules for those ports unless you intentionally want another machine to push telemetry into that agent.

Optional: Run Central On A VPS

The default recommendation is not "Central must be on a VPS." It is "Central must be stable." That can be an always-on workstation, a home server, a dedicated VM, a private cloud host, or a small VPS you treat carefully.

Running Central on a VPS is acceptable when that VPS is:

• Stable enough to stay online independently of app deploys.
• Backed up, especially the LogForge data directory or Docker volume.
• Not casually rebuilt, resized, snapshotted, or destroyed as part of normal application work.
• Protected with the same firewall split: 9443 from agent hosts, 8444 from admins or a private network.

If Central runs on one of the same rented servers as an app, keep the mental model separate. The app can churn. Central state should be deliberate. The other VPS hosts still get their own outbound remote agents.

Troubleshooting

An agent stays offline.

Check the agent container logs on that VPS:

docker logs -f unicron-agent-web-nyc-01

Then confirm that server can reach Central on the agent mTLS port:

nc -vz logforge.example.com 9443

If 9443 fails, fix the Central firewall, provider firewall, DNS, routing, NAT, IPv6, VPN, or tunnel path first.

The dashboard works, but enrollment fails on 9443.

The dashboard port and agent port are separate. 8444 reaching your browser does not prove 9443 reaches Central from the VPS. Test 9443 from the VPS itself and verify the generated command uses the expected mTLS URLs:

CENTRAL_MTLS_URL=https://logforge.example.com:9443
CENTRAL_WS_URL=wss://logforge.example.com:9443/unicron/api/agent/ws

Several VPS hosts show up as one agent.

Generate a unique enrollment command for each VPS and give each host a unique agent name. Do not reuse one command across several servers.

Containers or logs are missing.

Confirm the generated command includes the Docker socket, the Docker container log directory, and the host root mount:

/var/run/docker.sock
/var/lib/docker/containers
/

If the VPS uses a nonstandard Docker data root, adjust the generated /var/lib/docker/containers mount to match that host.

Docker says permission denied.

Run the generated command with sudo, or add your user to the Docker group and log in again:

sudo usermod -aG docker "$USER"

For the first install, using sudo docker ... is often the fastest way to separate Docker permissions from LogForge enrollment issues.