About Docktor

Why it exists

If you run a handful of Docker Compose apps on a VPS, you usually have two options when something is slow: SSH in and read docker stats and logs, or install and maintain a full monitoring stack. The first doesn’t keep history. The second is a lot of software for one or two servers.

Docktor sits between them. It uses the SSH setup you already have, reads Docker and Linux kernel data, groups containers into deployments, and explains the likely bottleneck in plain English. The goal is to go from “something is slow” to “check postgres I/O on this volume” in one screen.

Who it is for

A solo developer or small team running one to ten Compose apps on Linux servers, such as Hetzner, Linode, DigitalOcean, Vultr, AWS, or a machine under a desk. A typical stack is a reverse proxy, an API or web service, postgres, redis and a worker. You’re comfortable with SSH, and you don’t want to run an observability stack.

Principles

• Diagnosis first, graphs second. Every chart answers a question a diagnosis raised.
• Honest about uncertainty. Observed facts are stated plainly. Inferences are hedged and carry a confidence level. When the evidence isn’t there, Docktor says “insufficient evidence”.
• Trust through transparency. Read-only, auditable and local. You can see exactly what was sent to your server.
• Calm by default. The menu bar shows health, not numbers. Attention is earned by a real finding.
• Narrow and excellent over broad and enterprise.

How it handles your servers and data

• Docktor runs your system ssh. It never reads, copies or stores your SSH keys, and it never disables host key checking.
• Every remote command comes from a fixed catalog, and the exact script sent to each server is viewable in the app.
• Monitoring is read-only. Docktor doesn’t use sudo, restart containers or change configuration.
• The one exception to “nothing runs inside containers” is optional Celery inspection, which runs a fixed, bounded program with docker exec only for a deployment where you turned it on.
• There is no Docktor cloud backend and no analytics. Monitoring data and history stay on your Mac.

Reading Docker state needs access to the Docker socket, which is root-equivalent on the host. Docktor only issues read-only Docker commands, but you should know what that access means.

What it deliberately isn’t

Docktor is not external uptime monitoring and doesn’t page anyone. It monitors while your Mac is awake and the app is open, and shows sleep gaps as gaps. It also isn’t Kubernetes tooling, a log platform, an APM, a deployment pipeline or an AI chatbot. Core diagnosis is deterministic rules over evidence. See how it compares with tools that do those things.

Where it is going

Docktor is at version 0.1.0. Planned next steps include dependency attribution, service topology, and further adapters, with PostgreSQL next. These are plans, not promises.