Nodes
Bring a server under SpipCP's control — enroll it once over SSH, harden it, and keep it converged — then manage it from the node workspace.
A node is a server SpipCP manages — a VPS or a bare-metal box. You give it SSH access once; the panel installs a small agent, hardens the box, and from then on keeps it in a known-good state and watches it. Everything on SpipCP — instances, and the sites inside them — lives on a node, so this is where you start.
Adding a node
From Nodes → Add node, a wizard walks you through bringing a server online:
Give it SSH access. Name the node and enter its host, SSH port/user, and a private key or password. This is the only time SSH is used, and it's encrypted right away.
Choose what it is. Pick the topology class (VPS, single-IP dedicated, or multi-IP dedicated) and the OS image. The class decides what instances the node can later run.
Preflight. Read-only checks run over SSH and report a verdict — OS, networking, disk, and whether the box can host instances — before anything changes. A failing check tells you how to fix it.
Enroll & converge. The panel installs the agent, then hangs up SSH. The agent connects back over a secure channel and the node goes online, then reconciles to green — hardened and reporting facts, which you watch live in the terminal.
Publish an agent release first
Enrollment installs the agent binary onto the node, so a fresh panel needs one published release per CPU architecture first (Agents → Releases → Publish). Otherwise the wizard stops with "No agent release published." You only do this once.
Once a node is online, its workspace has these tabs.
Overview
The node's details and the live facts the agent collects — hostname, OS, architecture, CPU, memory, disk — plus a drift badge if the live server has wandered from its desired state.
Metrics
CPU, load average, memory, and disk trends for the node — with a 1h · 24h · 7d · 30d range picker, an online-history strip showing when the node has checked in, and capacity gauges comparing what's allocated to instances against the node's real resources.
See Analytics for how the history behind these charts is collected.
Instances
Every instance hosted on this node, with a jump into each one — and a Create instance button that opens the create dialog with this node already chosen.
Services
The state of the node's own services (the agent, Incus, Caddy, fail2ban) and the Reconcile and Dry-run controls. Reconcile brings the node back to its desired state and streams every step live; a dry run shows what would change without touching anything.
| Control | What it does |
|---|---|
| Reconcile | Bring the node back to its desired state (safe to re-run — a no-op if already green). |
| Dry run | Show what would change without applying it. |
→ Learn more: how reconcile and drift work.
Defaults
The node's cascade defaults — the git account, DNS provider, and SSL issuer its instances, and the sites inside them, inherit unless they override them. Set them once here and everything below picks them up.
Security
The node's security posture: its firewall (UFW) rules, the hardening state, and anything that's drifted from the baseline. The first reconcile applies a default-deny firewall, no-root-SSH, fail2ban, a sysctl baseline, and automatic security updates.
Reconcile log
Every reconcile run against the node, re-openable with the same live view — so you can replay exactly what changed and when.
Terminal (break-glass)
When you genuinely need hands-on access, the Terminal opens a real shell on the node. It's admin-only and every session is audited — an escape hatch, not how you normally drive a node (reconcile is that). Operators don't get it.
How it works
You never SSH a node to run things — the panel decides the desired state and the agent applies it. Reconcile works out the difference between desired and actual, then applies the steps in order. It's safe to re-run, and resumable: if a step fails it stops there and tells you how to fix it, and re-running continues from that point. Drift detection is a scheduled read-only check that flags hand-edits; the next reconcile puts them back. A fleet reconcile brings every node back in line at once. Agent releases are signed, and a node refuses to run an unverified binary.
Recommendations
How SpipCP suggests you choose providers — DNS, SSL, and git — and the reasoning behind it. The short version: prefer open, self-hostable, EU/sovereign options; keep US-based platforms as a fall-back, not a default.
Node topology classes
A node declares what it is when you add it — VPS, single-IP dedicated, or multi-IP dedicated. The class decides how instances are reached and what instance creation can offer.