Everything you need to run Ferrum
Ferrum is one Go binary with an embedded web UI. There's no separate services to stand up, no message queue, no external cache: SQLite is enough for most installs, and Postgres is there when you want to run more than one instance against the same database. This guide covers building it, installing it on whatever you're running, configuring it, and using what it does once it's up.
Where to start
If you just want it running, skip straight to Installation; there's a one-line installer for Linux, a Windows service installer, prebuilt Docker images, and instructions for building from source yourself. Once it's running:
- Open the UI and create the initial admin account. The very first visitor to a fresh install gets offered this; nobody else ever will.
- Add a Proxmox connection from Connections: host, port, and either an API token or a username/password.
- Give it a minute to pull inventory, then the fleet dashboard, topology, and alerts start populating on their own.
A connection can be a full PVE cluster, a single standalone node, or a Proxmox Backup Server remote, and you can add as many as you have. Ferrum treats each one as an independent source and rolls them all up in the fleet views.
How the docs are organized
Installation: building from source, and installing a release build on Linux (systemd), Windows (service), macOS, or via Docker, plus how to upgrade and uninstall cleanly.
Configuration: everything in config.yaml and its FERRUM_* environment variable equivalents: the database driver, TLS and reverse-proxy behavior, the encryption secret, OIDC single sign-on, and the built-in local AI provider.
Features & workflows: what each area of the app does and how to configure it: the dashboard, inventory and consoles, storage and backups, HA/firewall/SDN, alerting and automation, and access control.
API, MCP & audit log: generating API keys, calling the REST API, wiring an MCP-capable agent up to Ferrum, and where every mutating action gets logged.