@@PRODUCT@@

Access to a server

A server administrator gets one or more machines from you. From now on you also decide how much they may do on each: watch only, use the server, configure it, or everything.

Written for: Administrator

A server administrator gets one or more machines from you. From now on you also decide how much they may do on each: watch only, use the server, configure it, or everything.

That is a choice per server per person. The same colleague can hold Use on stck1 and Full access on stck2 — the level hangs on the assignment, not on the login.

Nothing that works today changes. Every assignment that already existed is set to Full access, and Full access is exactly what a server administrator could always do. New assignments default to Use.

The four levels

LevelWho it is for
Read-onlyFirst-line support, a monitoring integration, a supplier watching an incident. Sees everything, changes nothing.
UseThe server customer, and the everyday server administrator. Customers, websites, mail, DNS, databases, files, backups, restarting a service, releasing a banned IP, migrating a customer in. Changes nothing about how the machine is built — and, since August 2026, does not read that either: the firewall rules, the SSH keys, the drop-ins, the version list and the integration credentials are out of reach.
ManageThe colleague who actually builds the servers. Everything in Use, plus the PHP policy, drop-ins, roles, the web server, firewall and LFD, the SSH port, IP addresses, nameservers, tools, channel and auto-update, integrations.
Full accessEverything a server administrator can do, including a terminal, SSH keys, reboot and power off, joining a node and IP migrations.

The levels are a ladder with one deliberate step sideways. Each level can do everything the level below it can, plus what is listed — except that Read-only may look at how a machine is built and Use may not.

That is on purpose, and it follows from who the two are for. Read-only is somebody inside your own organisation: first-line support, a monitoring integration, a supplier you asked to watch an incident. Use is the person who rents the machine from you. They run everything on it, and they have no business reading the list of SSH keys that open a root shell on it.

So moving somebody from Read-only to Use gives them the whole customer surface and takes away the ability to read the machine's own configuration back. Every other move up the ladder still only adds.

The terminal is in Full access alone, and that is deliberate. Whoever holds a root shell can reconfigure and reboot the machine anyway — outside the panel and without an audit row. If the terminal sat one level lower, every boundary above it would be decoration.

What nobody with a server assignment can reach, at any level: the platform settings, the DNS provider credentials and the mail gateway connections. Those stay administrator-only.

Changing somebody's level

From the server:

  1. Go to Servers and open the machine.
  2. Click the Access tab.
  3. Click the person's row.
  4. Pick a level. Under the choice you see what that person can and cannot do afterwards.
  5. Click Save level.

From the person: People → open the person → This person's servers → click a row. It is the same screen; you have only arrived from the other side.

A row marked Via: Group arrives through the node group and applies to every server in it. You change that one on the person, not from a single machine — the alternative is changing something for a whole group as a side effect of standing on one of them.

Every change writes an audit entry with the old and the new level, the server and who did it.

From the command line

On the panel host:

# What does Anna hold, and where?
corecp-panel scope list --user anna@example.com --config /etc/corecp-panel/panel.yaml

WHAT   NAME               TEMPLATE  GRANTED BY          GRANTED AT
node   stck1.corecp.dev   use       admin@corecp.dev    2026-08-16T19:44:02Z
node   stck2.corecp.dev   full      admin@corecp.dev    2026-08-16T19:44:20Z

# Who holds this machine?
corecp-panel scope list --node stck1.corecp.dev --config /etc/corecp-panel/panel.yaml

EMAIL              TEMPLATE  VIA           GRANTED BY        GRANTED AT
anna@example.com   use       this machine  admin@corecp.dev  2026-08-16T19:44:02Z

# Give somebody a server (defaults to use)
corecp-panel scope grant --user anna@example.com --node stck1.corecp.dev \
  --config /etc/corecp-panel/panel.yaml

# Change the level
corecp-panel scope template --user anna@example.com --node stck1.corecp.dev \
  --template manage --config /etc/corecp-panel/panel.yaml

# And take it away again
corecp-panel scope revoke --user anna@example.com --node stck1.corecp.dev \
  --config /etc/corecp-panel/panel.yaml

The levels themselves, with the permissions behind them:

corecp-panel scope templates

That command reads no database and needs no configuration, so it still answers on a machine whose panel will not start.

What a colleague sees when something is refused

A refusal names the server and the level that is in force:

your access to stck1.corecp.dev is "Use", which does not include node.configure

That is deliberately a different message from "your level is too low" or "your role does not allow this". Those three are fixed by three different people, and the message should send the question to the right desk.

See also

  • Managing a server
  • Giving somebody access — the same idea for a customer account rather than for a server.