A server is one SSH or RDP target. It belongs to exactly one customer, carries an environment tag, and is what policies, access requests, certificates and sessions all point at.

Adding a server to the inventory does not make it connectable on its own. A server that uses certificate authentication still has to be bootstrapped so its sshd trusts your CA. A server that uses a stored identity needs no bootstrap, but it needs an identity from the Keystore.

Required permissions

Permission	Lets you
servers.view	See the inventory and fleet health.
servers.create	Add servers.
servers.update	Edit name, address, port, labels, customer, OS and SSH user, one at a time or in bulk.
servers.change_environment	Move a server between demo, dev, staging and prod.
servers.manage_credentials	Switch a server to a stored identity, pick that identity, or set its RDP password.
servers.update_connection_ip	Update the address of a server marked as having a changeable IP.
servers.onboard	Create install and uninstall links, run remote provisioning, run a health check.
servers.reset_host_key	Clear a server's pinned SSH host key.
servers.delete	Permanently delete a server.

Environment and credential changes are checked per field. Someone with only servers.update can save the edit form as long as they have not changed the environment or the authentication settings.

Customer scope

A user whose access scope is limited to selected customers only sees servers under those customers. A server outside their scope behaves exactly as if it does not exist. See Groups.

Add a server

1. Open Servers and select Add Server.
2. Under Basic info, choose the Customer and enter the Hostname. Name is an optional friendly label, such as Acme Prod Web.
3. Under Connection, enter the IP Address, Port and Protocol (SSH, RDP or Both), and the SSH User Shellius should use by default.
4. Under Classification, choose the Environment and add any Labels. Type a label and press Enter to add it.
5. Under Authentication, choose how Shellius logs in (see below).
6. Save.

Field	Notes
Hostname	Required, up to 255 characters.
IP Address	Required unless IP may change (not static) is on. The form accepts IPv4.
Port	1–65535. Defaults to 22.
Protocol	ssh, rdp or both. Defaults to ssh.
Environment	demo, dev, staging or prod. Defaults to dev.
SSH User	Defaults to root.
Operating system	OS Type (Linux, Windows, Other) and a free-text OS Version.
RDP Credentials	RDP Username and password, for RDP servers. The password is encrypted at rest and is never returned to the browser.

Production is a behaviour, not a label

Tagging a server prod puts every request for it through approval, unless the requester's role may skip it. Moving a server out of prod removes that requirement, which is why changing the environment has its own permission. See Access requests.

If the address is private, the form notes it. Browser sessions are opened by the Shellius backend, so what matters is whether the backend can reach that address — see Network reachability.

Choose how Shellius authenticates

Mode	What it means	Needs
Shellius CA certificate	The default. Each session uses a short-lived certificate signed by your organisation's CA.	The host must be bootstrapped.
Stored identity	Shellius logs in with a Keystore identity — a password, a key, or both.	No bootstrap. An organisation identity from the Keystore, and servers.manage_credentials.

Only organisation identities can be bound to a server. A personal vault identity can never be attached to one.

TIP

Use a stored identity for hosts you cannot change — appliances, a vendor's machine, anything where you may not touch sshd. Use certificates everywhere else. See Keystore.

Once a server uses a stored identity, changing its hostname, address or port also requires servers.manage_credentials. Re-pointing the server would otherwise hand the stored secret to a different machine.

Servers without a static IP

Turn on IP may change (not static) for a cloud VM whose public address changes on restart. For such a server the address is optional when you create it, and people with servers.update_connection_ip can correct it at connect time without being able to edit anything else about the server. Each change is audited as server.connection_ip.

Bootstrap, provision and uninstall

From a server's page, the Host menu holds Bootstrap host and Uninstall agent. Both need servers.onboard.

Bootstrapping can be done two ways:

• Run a command yourself. Shellius gives you a one-time install command to run on the host. This is covered in Bootstrap your first host.
• Let Shellius do it over SSH. You supply credentials — a saved identity, or a username with a private key or password, plus a sudo password if one is needed — and Shellius connects, runs the installer, and streams the output back to you. Typed credentials are used once, in memory, and are not stored.

To install across many hosts, select them on Servers and choose Install collectors. You pick Posture collector only, which does not touch sshd, or Full agent, which sets up CA trust and check-principals. Shellius shows a plan first, listing the hosts it will skip and why — Windows and RDP-only hosts, inactive servers, and hosts it has no credentials for. A run covers at most 200 servers, between 1 and 8 at a time (3 by default), and one host failing does not stop the rest. Closing the dialog stops the run.

Health checks

Shellius checks every server every five minutes by opening a TCP connection to its address and port, with a ten-second timeout. A connection that opens is healthy; a timeout or a refusal is unhealthy, with the reason shown as the health message. It is a reachability check from the backend, not a login test.

To check one server now, use Run health check in its row menu. This needs servers.onboard.

Reset a pinned host key

The first time the backend connects to a server over SSH it pins the host key. If the key later differs, the connection is refused rather than trusted.

When a host has legitimately been rebuilt, open the server, then Keystore → Reset host key. The next connection pins whatever key it sees.

DANGER

A changed host key is also what an interception looks like. Confirm the rebuild with whoever owns the machine before you reset it. The reset is audited as server.host_key_reset.

Edit many servers at once

Select servers with the checkboxes, pick a field under Change field..., choose the value, and apply. You can change the environment, protocol, OS type, SSH user, active state and customer this way. Changing the environment in bulk still requires servers.change_environment. Servers outside your customer scope are skipped silently, and the result counts only the rows that changed.

Delete a server

Deleting needs servers.delete, which only the Super admin role holds by default. Before you confirm, the dialog shows what goes with the server: active sessions, total sessions, pending and approved access requests, and issued certificates.

Live sessions are terminated first. The server's sessions and access requests are then deleted with it; certificates issued for it are kept, detached from the server.

TIP

To take a server out of use without losing its history, edit it and turn Active off instead.

Next steps

Bootstrap a hostMake a server trust your CA so certificates work.Access policiesDecide who may reach which servers, and as whom.KeystoreStored identities for hosts you cannot bootstrap.PostureSee what each server exposes to the network.