Workspaces and teams
A workspace is where your work lives: your providers, connected accounts, logs, and approval settings. Log storage and human approval are both controlled per workspace, so each workspace can be set up differently.
- Every account has a personal workspace, and it’s yours alone.
- A team is a shared workspace. Create one to work on the same providers with colleagues, with its own log and approval settings.
- Teams are available on plans that include team seats. Seat counts are listed on swytchcode.com/pricing.
Which workspace a project uses
A project names its workspace in .swytchcode/tooling.json, like package.json names a package:
{ "workspace": "payments-api"}- The first time a project needs a workspace (for example on
swy get), it’s named after the project folder. If you already have a workspace with that name, the project uses it; otherwise a new one is created. - Commit
tooling.jsonand everyone with a copy of the project - on any machine - uses the same workspace. Moving or renaming the folder doesn’t change it. - Names are unique in your account, so the same name is always the same workspace. A name that doesn’t exist is an error; nothing is created by accident.
To see or change the workspace:
swy workspace # show this project's workspace and list your othersswy workspace use <name> # use another of your workspacesswy workspace use <name> --create # create a new workspace and use itAfter use, commit tooling.json so everyone working on the project switches with you. Connected accounts, logs and approval settings belong to each workspace, so switching doesn’t move them: a new workspace starts empty.
Swytchcode also keeps the workspace’s ID in .swytchcode/workspace.json as a local cache. It’s added to .gitignore; you never need to edit or commit it.
Team workspaces can’t be chosen from the CLI yet; swy workspace lists your own workspaces.
Inviting people
Invite colleagues by email and choose a role for them. They join once they accept the invitation.
| Role | What they can do |
|---|---|
| Owner (whoever created the team) | Everything, including deleting the team |
| Admin | Manage the team and its members, create providers, and change the workspace’s approval settings |
| Viewer | View the team’s work and members |
| Billing | View the team and its members |
Seats and invitations
- Each team member takes one seat. If your plan’s seats are full, new invitations can’t be accepted until you free one up or upgrade.
- If your plan changes to one without team seats, existing invitations can no longer be accepted.
- Private providers in a team workspace are hidden from people outside the team.
Logs
Turn on log storage for a workspace to keep a searchable history of the commands run in it, and browse it from your dashboard. Logs are set up per workspace: turn them on for the workspaces that need them and leave them off for the rest.
- Log storage is off by default. Turn it on in each workspace’s settings.
- In a team workspace, everyone in the team shares the same logs. It’s a per-workspace setting, not a per-person one.
- Each workspace’s logs are kept separate from every other workspace. Only people with access to that workspace can see them.
- Turning it off stops new logs from being saved. Your existing logs are kept, so turning it back on doesn’t lose anything.
- How long logs are kept depends on the plan of the workspace’s owner: 7 days on Free, 30 days on Pro, 90 days on Business, and as agreed on Enterprise. When the plan changes, the new retention applies to the workspace automatically. After a downgrade, logs older than the new limit are removed. Current plans are on swytchcode.com/pricing.
Workspace logs are not the same as the local CLI audit trail. swy audit always records history on your machine, whether or not workspace log storage is on. You can optionally sync that local history to the cloud.