Add a server
Connect a Linux, macOS or Windows server to Servor in one line by installing the lightweight agent — no manual SSH config, connected in seconds.
Adding a server to Servor takes one command. You copy a one-line install command, run it once on the machine, and the server shows up as connected — ready for the web terminal, commands, monitoring and the AI copilot.
Servor installs a lightweight agent on the server. The agent keeps the connection alive so you never have to manage SSH keys or ports for day-to-day work.
Unlock your vault first
Running commands, opening the terminal and using the copilot all require an unlocked vault. If you haven't set one up yet, do that first: Unlock your vault. Adding the server itself works either way, but you'll want it unlocked to actually use the server.
Add a server
Open the Add a server dialog
In the dashboard, go to Servers and click Add a server — or jump straight there: Add a server in Servor. Give the server a name you'll recognize (you can change it later in server settings).
Copy the install command
Servor generates a one-line install command unique to this server. Click to copy it. It looks roughly like this:
curl -fsSL https://get.servor.app/install.sh | sh -s -- --token <your-token>Keep the dialog open — it's watching for the agent to connect.
Run it on the server
Paste the command into a shell on the machine you want to add (over SSH, a cloud console, or directly on the box) and run it. The installer downloads the right agent build for the operating system and architecture, installs it as a service, and starts it.
Watch it connect
Within a few seconds the dialog flips to connected and the server appears in your list with a green status. That's it — the agent will keep itself up to date automatically from now on.
Which user to give: root, preferably
The Username field is the account the agent will run your commands as, and it is
best left on root.
The installer needs root either way — the command goes through sudo and the
service runs as root. But every command, every check and every terminal then drops
down to the account named here. With ubuntu, debian or any other account, the
built-in admin actions — firewall, package updates, adding SSH keys, powering off —
come back with a permission error.
That is not an oversight: Servor never adds sudo to a command. The browser
signs the exact text of what will run, and nothing downstream — not even Servor —
may add to it, which is what makes the signature verifiable by the agent. A non-root
account remains perfectly usable if you would rather type sudo … yourself in the
terminal.
Importing a whole fleet at once
Nobody managing forty machines enters them one at a time. From the server list, Import
an SSH config opens a screen where you paste your ~/.ssh/config: Servor pulls out the
machines it finds — alias, address, user, port — and lists them so you can untick the
ones to leave behind.
Imported servers arrive in agent mode with no credentials at all. That is deliberate: an SSH config file contains no keys, only paths to keys, and Servor has no use for either. Nothing sensitive is read or transmitted. You then install the agent on each machine through the usual flow.
Entries that name no machine — Host * and patterns like it, which configure rather
than name — are skipped.
Supported operating systems
The installer detects your platform and pulls the matching agent build. Servor ships 7 OS/architecture targets covering the common cases:
- Linux — x86-64 and ARM64 (VPS, cloud instances, Raspberry Pi, containers)
- macOS — Intel and Apple Silicon
- Windows — x86-64
If your platform isn't detected automatically, check that you're running the command
in a real shell with curl (or PowerShell on Windows) available.
You only run it once
The agent auto-updates in the background, so you don't need to re-run the install command for new versions. You'd only run it again to reinstall a broken agent — see Repair the agent.
What SSH is used for
Servor uses SSH only during this initial setup — to probe the connection, discover the machine and auto-install the agent. After that, everything (terminal, commands, metrics) runs through the agent, not SSH. That's why a server shows unreachable if the agent later goes down, even when SSH still works. When that happens, repair the agent rather than reaching for SSH.
A server behind a bastion
A machine Servor cannot dial directly — a private network, a fleet behind a jump
host — can still be added. Under Advanced options on the add screen, turn on
Go through a bastion and give its host, port, user and authentication. Servor
then installs the agent through it, exactly the way SSH's ProxyJump does.
The bastion has its own credentials, entered separately and encrypted apart from the target's. It never sees them: the session to the server is negotiated end to end over a channel the bastion only carries. A bastion whose key also opens every host behind it is precisely the arrangement a bastion exists to avoid.
This is bootstrap only. Once the agent runs, its tunnel is outbound: the terminal, commands and metrics no longer go through the bastion. You can add or remove one later from Edit server; leaving the authentication field empty there keeps the one already stored.
If the server doesn't connect
- Make sure the machine has outbound internet access (the agent connects out to Servor; you don't need to open inbound ports).
- Re-run the install command — it's safe to run again.
- Still stuck? See Connection issues for firewall and bootstrap troubleshooting.