When a server stops reporting, its last resource reading cannot tell you whether it is still reachable. I built Dockyard with heartbeat monitoring that detects lost communication and restores a node's healthy status when reports resume. CPU, memory, disk and container activity remain separate pieces of information.

Dockyard is a private infrastructure prototype. I built its node agents, Rust backend, PostgreSQL storage, Docker integration and SvelteKit interface to explore the implementation behind a container hosting platform.

Agents register nodes and report their resource usage and container activity. Those reports feed the server inventory and resource views. Heartbeats add the communication state: whether Dockyard is still hearing from the machine.

This gives the interface two useful questions to answer. What did the node report? Is it still reporting? A machine returning after a gap also needs its status updated, so recovery is part of the monitoring behavior.

I used Rust, Axum and Tokio for the backend, with PostgreSQL storing application records, releases, deployment state and audit history.

Application identity, release information and deployment progress each have a stored record. The audit history records operator actions alongside that state. Someone inspecting an application can therefore follow its deployment activity and recent changes through the interface.

The Docker integration performs concrete lifecycle operations: pulling an image, starting a container, stopping it and removing it. In this version, those operations execute on the control-plane host. That execution boundary matters when interpreting the server inventory: monitoring a remote node does not make it a remote deployment target.

I built the frontend with SvelteKit, TypeScript and Tailwind CSS. It includes server inventory, resource views, application details, deployment progress and recent operator activity. Deployment pages refresh as operations progress.

Version 0.13.1 implements node monitoring and heartbeat recovery, persistent application and deployment records, host-local Docker operations and the interface for inspecting them. The source is private.

Image builds are simulated. Remote workload execution, automated scaling and traffic switching remain unfinished. Those boundaries define the prototype's current scope.

This is the kind of backend and admin-interface work I take on: connecting machine reports, stored records and actions that a user can inspect. For a similar internal tool, message me on Contra with the systems and operations it needs to support.