Teams (beta)

Teams are in beta. Where Team is on sale, it is bought from the pricing page; otherwise a team is set up by Debugt. Either way its owner then invites the rest from the team page, and every member signs in to Debugt in Settings → License.

Buying Team, and its seats

Team is paid for by the seat: $24 a seat a month, or $240 a seat a year, and at least 3 seats. On the pricing page, give the team a name, choose how many seats, and pay through Paddle with the email address you will sign in with. The team is made a moment later, with you as its owner, and an email says it is ready.

• Each member takes a seat, and so does each invite not yet taken. A member is on the Team plan — everything in Pro, with more shared links that last longer — on up to 3 machines while the team is paid for.
• The owner changes the seats on the team page, under the team’s name: the new number, then Change seats, which shows what it costs — charged, or credited, at once, for the rest of the period — before you confirm. Seats go down only as far as the members and open invites the team has.
• Card, invoices and cancelling are under Manage billing, beside the seats. A team that is cancelled stays paid for until the end of what was paid.
• When a team is not paid for — cancelled and past its end, refunded, or three days past a renewal that was not paid — its members go back to Free. What the team shared stays shared, and keeps syncing: renew it, and every member is on the Team plan again.

A team set up by Debugt in the beta has its seats set by Debugt: write to us to change them.

Inviting people

On the team page, type an email address — or paste a list of them, one a line or separated by commas, as copied from a spreadsheet or an email’s recipients — choose Member or Admin, and Invite. Up to 100 at once.

• Each person is emailed a link of their own. It works for that address only, for 7 days: they open it, sign in with a link sent to the same address, and they are in.
• There must be a seat for everyone new. If there is not, nobody is invited, and the page says how many seats are missing. Someone invited already is invited again in the seat they hold.
• Addresses that are not one, or belong to someone in the team already, are left out and listed.
• An invite whose email could not be sent says so, with its link to copy and send yourself. Every waiting invite’s link is also under Invites, with Copy link and Withdraw.

Roles

	Owner	Admin	Member
Shares, updates and stops sharing	yes	yes	no
Restores what was deleted from the team	yes	yes	no
Runs what the team shares, and syncs it	yes	yes	yes
Invites people	yes	yes	no
Changes the seats, and pays for them	yes	no	no

A member reads what the team shares and changes none of it. To change a canvas, a request or an override, they Duplicate it, or Clone it, and the copy is their own. On a shared environment profile they set the values of its personal variables, and nothing else.

Sharing a project

In Projects, select the project: the line under the list says how it stands with your team. Share with a team… links it to one of your team’s projects — the one with the same git repository and folder is offered first — or makes a new one. Your teammates link the same project on their machines. A linked project carries the team’s mark in the list.

Choosing a team project that does not look like yours — another repository, or another folder of it — asks first: linked anyway, what the team shares lands in this project, and a canvas made in the other one does not find its services here. Where the right folder is inside yours, add it with Add projects from folders in Projects, and link that one.

The line’s ⋯ menu has the way out: Stop syncing on this machine unlinks this machine and leaves the team as it is; Stop sharing with the team…, for the owner or an admin, deletes the team’s copy of everything shared in the project. Everyone keeps what they have.

Nothing is shared until you share it. What you make stays yours until you choose to share it:

What	Where you share it
Saved requests, or a folder of them	Their menu in Requests
A canvas	Its details (ⓘ in the header) → Share with team
An environment profile	Environments → the line under its name
An override	The library’s ⋯ menu on its row
The project’s redaction rules	Settings → Redact → Share yours with team

A canvas goes with what it needs to run: the environment profiles and library overrides its services use, and how each service is set up — its kind, handler, ready pattern and host. On a teammate’s machine that setup only fills in what they have not set themselves.

Personal variables

An environment profile’s variables can be marked personal — a password, a token. The team gets their names, never their values: each member sets their own, kept on their machine. A service whose profile has a personal variable with no value here waits until it is set.

Changes, and syncing

A shared item changed on your machine is marked as changed, and stays yours until you send it:

• Update team sends it. A canvas sends the changed profiles and overrides it uses with it.
• Revert takes the team’s version back.
• Where a teammate changed it first, Take theirs or Keep mine decides — nobody’s change is written over without being seen.
• Stop sharing deletes it from the team and keeps it on your machine as your own.

What teammates changed reaches your machine when you Sync — in the project’s line under Projects, or the Sync button that appears beside a canvas in the header once its team has changed it. Debugt looks for changes when a shared canvas is opened, when the window comes back to the front, and each minute while it is open; it only looks, and takes nothing until you sync.

Recently deleted, in the project line’s ⋯ menu, lists what was deleted from the team, by whom. The owner or an admin can restore it for thirty days.

Redaction rules

A project’s redaction rules can be its team’s: its headers, body fields and recorded variables. Every member’s machine then redacts the team’s and its own together — in traces, recordings, Request History and shared sends. A member adds their own beside the team’s, and can switch none of the team’s off. See Settings → Redact.

Overrides, before they are first shared

An override is often copied from a real answer — a sign-in’s token, a customer’s record. So the first time one is shared, Debugt shows it as your redaction rules leave it, and what they take out:

Redact list	What it takes out of an override	Matched
Headers — the defaults, yours and your team’s	A URL override’s response headers	By name
Body fields — yours and your team’s	Its body, or a function override’s value	A whole key: ssn, not ssnLast4
Recorded variables — the defaults, yours and your team’s	Its body, or a function override’s value	Anywhere in a key: password in passwordHash

A credential in the URL’s query is taken out too, as it is from a trace.

Share redacted keeps it so in your library, then shares it: the services that use it answer with «redacted» in place of those values. Share as it is shares every value. Sharing a canvas asks the same about each override it uses that goes with it for the first time.

Where it is kept, and how it is sealed

What you share is encrypted on your machine before it is sent, with your team’s key. Debugt’s servers keep it, and cannot read it.

• Kept by Debugt’s content service, in its own database (MongoDB): one record per shared item, and one per linked project. Shared sends are different: they are kept in Cloudflare R2 storage — see Sharing a send.
• Each item is sealed with AES-256-GCM, under the team’s key — 32 random bytes — with a new 12-byte nonce each time. GCM’s tag means a sealed item that was changed fails to open, rather than opening wrong.
• Each is bound to where it belongs. What it is — the team, the project, the item’s id and the key’s generation — is sealed in with it as associated data. Moved under another id, project or team, it does not open.
• The server sees only what syncing needs: each item’s id and its kind (a request, a canvas, a profile, an override, redaction rules), its version, who changed it and when, which generation of the key sealed it, and its size. Not its name, its URL, its body or its values.

Deleted items are kept, sealed, for thirty days to be restored, and then removed. Stopping sharing a whole project with the team removes everything shared in it.

The team’s key

The key never leaves your team’s machines unsealed.

• Each machine has a key of its own: an X25519 key pair made when you sign in. Its private half stays in VS Code’s secret storage on that machine.
• A new machine is let in by a teammate’s Debugt, automatically: it seals the team’s key to the new machine’s public key — a one-time X25519 key agreed with it, stretched with HKDF-SHA256 into an AES-256-GCM key. Only that machine can open its copy. Before it does, it checks that Debugt’s license server vouched for that public key, so a key slipped in by anyone else is not given the team’s.
• Debugt’s sync service keeps only those sealed copies, one per machine, and cannot open them.
• When someone leaves, their copies go at once, and the next member’s Debugt to run replaces the key. The new key carries the old one, sealed, so what was shared before still opens for those still in.
• The recovery key is offered to the owner in Settings → License: a code to print, DBGT-R-…, that the team’s key is sealed to as well. On a new machine with nobody left to let it in, the owner types it, and the team’s key is back.

Keep the recovery code somewhere safe. Without it, a team whose machines are all gone cannot open what it shared before.