Skip to main content

Workspaces

Behind a flag — the server side (lium-platform#208, #123, #124, #137) and the CLI (lium#183, since lium 0.0.43) are merged; workspaces stay off until a deployment turns WORKSPACES_ENABLED on

Until then every account has exactly its own pods, keys and balance, and the /workspaces endpoints answer 403 Workspaces are not enabled yet.

A workspace is the unit a team shares: its pods, API keys, volumes, templates and backup configurations, and the balance that pays for them. Every account has a personal workspace from the day it is created (<name>'s workspace); a team is another workspace you create and invite people into. Nothing changes for an account that never creates one — the personal workspace is the default everywhere.

Roles and the billing owner​

owneradminmember
Use the workspace's pods, volumes, templates and backup configurations✓✓✓
Create, list and revoke the workspace's API keys✓✓—
Rename the workspace, add and remove members, change roles✓✓ (cannot grant or take owner)—
Delete the workspace✓——

The billing owner is not a role: it is the account whose balance pays for everything in the workspace, and it can be an owner, an admin or a member. Two rules keep a workspace solvent and reachable:

  • an owner never leaves or is removed as an owner: the role is handed to someone else first (an owner is demoted, then removed), and the last owner cannot be demoted at all, so a workspace always keeps at least one;
  • the billing owner cannot leave or be removed until billing is transferred. Only the billing owner can start a transfer; an owner or admin named takes over at once, a member has to accept first — until then either side can cancel.

A workspace can be deleted only by an owner and only once it has no running pods and no volumes. A workspace you do not belong to does not exist for you: the /workspaces/{id} routes answer 404.

In the dashboard​

lium-platform#137.

The workspace switcher sits in the sidebar above the balance: the current workspace with your role (personal for the default one), the account's other workspaces, Workspace settings, and New workspace. Switching reloads pods, keys, volumes, templates and billing under the chosen workspace. If you are removed from a workspace, or it is deleted, while it is selected, the dashboard falls back to your personal workspace by itself.

Workspace settings (/workspace): rename; the member list with role selects (owners set any role, admins never touch owners); Remove / Leave; invite by e-mail with a role; pending invitations with Revoke; billing — who pays, a Transfer select for the billing owner, Accept / Cancel for a pending transfer; Delete (owners, not on the personal workspace). Every refusal the server makes is shown as the server words it, for example An owner cannot leave the workspace; hand the owner role to another member first.

Invitations​

Owners and admins add people; admins cannot grant owner. The API's POST /workspaces/{id}/members (lium-platform#208) adds an address that already has a Lium account as a member at once.

The rest of this section is lium-platform#124. The dashboard's Invite by e-mail and lium workspaces invite always send an invitation, whether or not the address has an account: an e-mail with a link (/workspace-invitations/<token>) that is valid for 7 days; the link shows the workspace name, the role and who invited you before you accept. Accepting requires being signed in as the invited address — the link alone does not admit whoever holds it. Owners and admins can revoke a pending invitation, which kills the link. If the mail could not be sent the invitation still exists (shown with a warning); revoke it and invite again.

API keys and workspaces​

An API key belongs to one workspace, chosen when the key is created (a key from before workspaces acts in its owner's personal workspace). Everything a key does — lium ps, Lium.up(), POST /executors/{id}/rent — happens in that workspace, and the bill goes to that workspace's billing owner. A key never selects another workspace: to act in a team from the CLI or SDK, create a key in that team (owners and admins) and use it.

A team key dies with its creator's membership, and it reaches only the team's pods, volumes, templates and backup configurations, never the billing owner's SSH keys, payments or account log — the exact routes, headers and error messages are on the Workspaces API page.

A dashboard session acts in the workspace picked in the switcher; the browser sends it as the X-Lium-Workspace-Id header. Without the header the personal workspace is used.

From the API, CLI and SDK​

  • API: the endpoints, who may call each, team-key rules and key scopes are on Workspaces API (lium-platform#208). A client detects that workspaces are on by the workspace object on GET /users/me (id, name, role, billing_owner_user_id, is_personal), and pods carry workspace_id — both lium-platform#123.
  • CLI (since lium 0.0.43): lium workspaces lists the workspaces you can see, lium workspaces use <name> makes one the default, lium --workspace <name> <command> runs one command in another, and lium keys create <name> --workspace <team> --save mints and stores the key a team needs — see lium workspaces.

Rollout​

Workspaces switch on per environment once lium-platform#208 is merged, deployed and WORKSPACES_ENABLED is set; the dashboard needs #137 and invitations #124 on top. Until your account shows the switcher, everything you own sits in your personal workspace and behaves exactly as before; nothing has to be migrated.