Onboard your first member
Adding someone takes about a minute. Doing it in the wrong order produces a day of confused messages.
This lesson walks the sequence once. Follow it with a real person if you have one to add, or read it through and use it as the checklist next time.
1. Get it working yourself before inviting anyone
Before inviting anyone, do this in the workspace you are about to share:
- Confirm the dashboard reports it deployed, not still provisioning
- Open a session
- Launch a small cluster, run one trivial distributed task, shut it down
- Save a file and confirm it appears in the file browser
Five minutes. It is the difference between "here is your workspace" and five people independently discovering the same missing dependency.
Inviting people to a workspace that is still deploying. They get access to something that does not work yet, and report it as broken. It is broken, temporarily, in a way no error message explains.
2. Pick the narrowest role that lets them work
Start restrictive. Widening access later is a two-minute conversation; recovering a workspace someone deleted by accident is not.
Roughly how capability separates:
| Capability | Roughly who |
|---|---|
| View workspaces, dashboards, activity | Everyone |
| Open sessions, launch clusters, run work | Practitioners |
| Create and delete workspaces, invite members, assign roles | Admins |
| Change plan and billing | Owners |
Current definitions are in the administration documentation, which stays authoritative as they change.
The property worth remembering: a role governs what someone can change, not merely what they can see. Someone who can view a workspace may not be able to delete it, change its plan, or invite others.
This is not distrust. Permissions someone does not need are permissions that can only be exercised by mistake.
3. Send these five things with the invitation
The invitation itself carries no context. Without these, you will answer each one individually:
- Which workspace, and what it is for.
- Where to save work so it persists, and that other paths do not survive a session.
- Where large data lives. Object storage paths, not workspace storage.
- What is already installed, so nobody reinstalls pandas.
- The cluster convention. Expected sizes, and that clusters must be shut down after use.
Number 5 earns its place. A new member has no way to know that a forgotten cluster is the largest avoidable cost in the organization, and they will not find out by accident.
Pointing them at getting started with Eugo covers the mechanics so you do not have to.
4. Agree an output convention before anyone needs it
Members do not share a session, since each person opens their own, but they do share workspace storage.
So two people can overwrite each other's outputs, and will. Decide now:
results/<person>/<run-date>/ or results/<run-id>/
Either works. Having neither means the first collision is a debugging session about missing files.
When someone leaves
Removing a member revokes their access. It does not delete their files from workspace storage.
Worth knowing in both directions: work is not lost when someone leaves, and it is not cleaned up either. Somebody should decide which of it to keep.
Review periodically
Access accumulates. People join projects, move teams, and keep permissions nobody revisits. The activity log shows which permissions have actually been exercised, which is a better basis for pruning than guessing.
What you now know
- The order: verify, then invite. Not the reverse.
- That roles govern change rather than visibility, and why narrow is kinder than generous.
- The five things an invitation does not say for you.
- That shared storage plus separate sessions means you need an output convention.
Next: plans, usage, and billing. What the plan actually governs, and where compute spend concentrates.