What a workspace is for
A workspace is the boundary around one product line or one team. It carries your connected repos, your tracker binding, your shared knowledge, your standing rules, and your dashboard. If you run two product lines that don't share a team or a roadmap, you'll want two workspaces. If you run one product with multiple repos, you want one workspace with several repos inside it. The line is whether the people and priorities are the same.
You'll create your first workspace when you sign up. The name is the one your team will see at the top of every screen, so make it something they'll recognize on Monday morning — usually the product name. You can rename it later from settings; nothing downstream breaks.
Who should own the workspace
One person owns the workspace. That's usually the founder or product owner who's most accountable for what the team ships. Owner is a role with the broadest permission: they invite people, set policies, change billing, and can remove anyone else. We recommend exactly one owner per workspace. Co-owners get into trouble in the same week somebody quits.
Beyond owner, two roles cover the rest of your team. An admin can change settings, manage integrations, and edit knowledge — most senior team members fit here. A member can use the workspace day-to-day: chat with Ship, work the Inbox, ship code through routines, browse knowledge. Members can't change settings or invite people. That's it. Three roles, clear edges, no committee.
Inviting your team
You invite by email from settings. Each invite carries the role you chose for that person. They click the link in their inbox, sign in with the same account they use for GitHub, and they're in. There's no separate password for Ship; we lean on the identity provider you already trust.
If your team uses Google Workspace or another SSO provider, you can wire it in from the same settings page once your workspace is on a paid plan. SSO bound to a domain means anyone with an email at your company can join automatically — useful for a team of twenty, dangerous for a team of two hundred. Set the bar deliberately.
What each person can see
This is the question that catches new owners off guard, so we'll be specific. A member of the workspace can see every repo connected to it, every project in the tracker, every entry in knowledge, and the audit log. They can chat with Ship and that chat is private to them — no other member, not even the owner, can read another person's threads. The audit log is where workspace-level actions land; it's not chat.
Knowledge is shared by design. The whole point of the catalog is that the team's accumulated context is reusable. If something is private to one person, it doesn't belong in knowledge — it belongs in their chat, where Ship remembers it across their own sessions.
Removing access
When someone leaves the team you revoke their access from the members page. Their chat history stays in the workspace as a record (you may need to read it during a handover) but they can't sign in anymore. If they had standing approvals or owned routines, those get reassigned on the way out — Ship won't let you remove the last owner of a workspace by accident.
A note on multiple workspaces
If your company runs Ship across two product lines, each line has its own workspace, its own tracker, its own repos, its own knowledge. A person can be a member of both. Switching workspace from the top dropdown changes everything on screen: different home, different Inbox, different rules. Nothing leaks between them. That's the contract.
The next page walks you through connecting your first repo.