Pluto (not to be confused with the dwarf planet Pluto) is the primary self-hosted production server in the infrastructure behind Dimitrium. It is the main machine for running the public services, container workloads and operational work; it is also the server through which this session is being handled.
Role
Pluto is the active, day-to-day node. It runs the Podman containers and databases behind the sites and services, keeps the primary operational journal, and initiates encrypted off-site backups to Venus. Pluto and Venus also check one another over Tailscale and SSH, so that a loss of either machine can be noticed independently.
Hardware and system
Pluto is an HP EliteDesk 800 G3 Desktop Mini (65 W) with an Intel Core i5-7500 running at 3.40 GHz. Its four physical cores, 8 GB of RAM and NVMe storage make it the considerably stronger of the two machines. It runs Debian GNU/Linux 13 (Trixie) on x86-64 hardware.
The internal NVMe drive provides roughly 238.5 GiB of usable capacity: a 229.6 GiB root filesystem, a 976 MiB EFI system partition and about 7.9 GiB of swap. The platform runs multiple healthy Podman workloads, including WordPress and MariaDB services.
Relationship with Venus
Pluto is built for production work; Venus is built to make that work recoverable. Important off-site copies are stored on Venus, while selected services can be prepared there as manually activated cold standby stacks. The two machines therefore form a small self-hosted pair: Pluto provides the primary capacity, and Venus provides the safety margin.
Monitoring and communication
Pluto and Venus communicate across a private Tailscale network and use SSH reachability checks to confirm that the other machine is still responding. No public management endpoint, address or credential needs to be published for that relationship. Pluto keeps the primary operational journal; Venus receives a read-only synchronized copy, which means the record of an incident remains available even if Pluto is the machine affected.
Alerts and responsibility
Each server also sends its own scheduled heartbeat to Healthchecks. That independent signal confirms that the local monitoring schedule itself is still running, not merely that a site happens to answer a web request. If the peer check fails three times in succession, the monitoring workflow sends an ntfy alert to Aleksa Dimitrijević, the person responsible for operating the pair. The alerts describe an availability problem without exposing infrastructure addresses, access details or secrets.