Share a server with other users

The Users tab gives another Coritan account access to your server. The other person signs in to their own account, finds the server on their Container Apps page and can do only what you allow. You never share your password, and billing stays with you: other users cannot see your invoices, change the plan or cancel the server.

• The other person needs a Coritan account. You add them by its user ID, a number. No dashboard page shows it yet, so ask them to read id in the answer to GET /api/v1/auth/me, as Profile shows.
• You must own the server, or hold the Manage users permission on it.
• We do not email the other person or ask them to accept. Tell them yourself once you have added them.

1. In the dashboard, go to Container Apps and open the server, then the Users tab.
2. Select Add user….
3. In User ID, enter the other account's user ID, for example 10482.
4. Under Permissions, tick what they may do. Choose permissions explains each one.
5. Select Add user.

The user joins the list, and the server appears on their Container Apps page.

Each permission in the list covers one area of the server:

Some things need a permission that the list does not offer, and you can grant these only through the API:

• The Ports tab needs the allocation permissions.
• The Java settings need startup.read and startup.update.
• Removing a plugin, mod, pack or the resource pack needs software.delete.
• Changing the server's software needs settings.reinstall as well as Install software.
• Starting in safe mode needs Power as well as Install software.

Downloading, locking and deleting a snapshot work only from the account that holds it, so another user cannot do them even with the Snapshots permission.

1. On the Users tab, open the menu at the end of the user's row and select Edit permissions….
2. Tick or clear permissions.
3. Select Save permissions.

The change applies straight away. If the user has the console open, it closes, and the new permissions apply when they open it again.

Saving keeps any permission you granted through the API that the list does not show, such as allocation.read. A wildcard is the exception: saving replaces *, or a whole-area grant such as file.*, with the permissions of the boxes that are ticked.

1. On the Users tab, open the menu at the end of the user's row and select Remove user….
2. Select Remove user to confirm.

They lose access to the server at once, and any console they have open closes. Their account and their own servers are not affected.

• The server is on their Container Apps page, with every tab. An action they have no permission for fails with Insufficient permissions.
• On the Users tab they see the other users by name, without email addresses. They see their own email address, but not yours.
• They connect over SFTP with their own email address and password.

The dashboard confirms each change with User added., Permissions updated. or User removed.. The Access column lists each user's permissions, and the line under their name shows how many permission keys they hold and when you added them.

That user already owns this server

You entered your own user ID. Enter the other person's.

User 10482 is already a subuser on this server

That account already has access. Use Edit permissions… on its row instead. The same message appears when no account has that user ID, so check the number with the other person.

Insufficient permissions

The user tried something their permissions do not cover. The owner adds the permission with Edit permissions….

No permissions this panel knows of

The user holds only permissions that the list does not show, granted through the API. They keep them when you save.

The server is missing from the other person's Container Apps page

Check that they signed in to the account whose user ID you entered, then ask them to reload the page.

• Use the console and power controls
• Connect to a server with SFTP
• Schedule server tasks
• Manage server ports

GET /api/v1/client/servers/{uuid}/users lists the users on a server. Each entry has id (the entry's own number), user_id (the account's user ID), permissions, created_at, email and name. When a user who is not the owner asks, email is null on every entry but their own.

Add a user with POST /api/v1/client/servers/{uuid}/users. The body takes user_id and permissions, a list of permission keys:

curl -X POST https://api.coritan.com/api/v1/client/servers/$SERVER/users \
  -H "Authorization: Bearer $CORITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"user_id": 10482, "permissions": ["control.console", "control.start", "control.stop", "control.restart", "file.read", "file.read-content"]}'

The response (201) is the new entry:

{
  "id": 318,
  "server_id": 2207,
  "user_id": 10482,
  "permissions": ["control.console", "control.start", "control.stop", "control.restart", "file.read", "file.read-content"],
  "created_at": "2026-09-25T14:30:00",
  "email": "sam@example.com",
  "name": "Sam Taylor"
}

The other routes take the entry's id, not the user ID:

These are the permission keys, by area. * grants every key, and an area followed by .*, such as file.*, grants every key in that area. The list must hold at least one key.

A key is the area and the name joined by a full stop, for example file.read-content. We accept settings.rename, software.update and startup.docker-image, but nothing checks them yet. Each guide in this section names the keys its routes need.

Adding a user needs user.create, changing one needs user.update and removing one needs user.delete. Any user on the server can list the users. Errors answer 400 with the reasons in Troubleshooting, Unknown permission: file.rename for a key that does not exist and Select at least one permission for an empty list. A subuser_id that is not on the server answers 404 with Subuser not found.