Skip to content

Workspaces

A workspace is one GitHub organization or user account, the people who work in it, and the subscription that covers them. Everything else in Pealboard belongs to a workspace: portals, requests, customers, saved views, notification settings and API keys.

A workspace can never see another workspace’s data. That boundary is enforced in the database, not in the application, and it holds regardless of anyone’s role.

One GitHub connection One installation of the Pealboard GitHub App.
Repositories Whichever the installation grants and the plan allows.
Members People who sign into Pealboard, each with a role.
Portals Spaces where customers submit requests.
Views Saved filters, sorts, groupings and layouts.
API keys Credentials for scripts, integrations and the MCP server.
A subscription Free, Team or Business.
  • Roles decide what a member may do. See Roles.
  • Billing and Delete workspace are the owner’s alone.
  • Everything else an admin can do.

A workspace is billed for its owner, admin and member roles. Viewers are free. Portal customers are never billed, on any plan, at any volume. Engineers who work in GitHub and never sign into Pealboard are never counted, because Pealboard has no idea they exist and does not need to. The quantity is recounted after every membership change and Stripe prorates the difference. See Billing.

The default repository is where a new issue goes when the person creating it names none, and where a portal’s request type sends one when neither the request type nor its portal names one. It is set once, in Settings → Workspace → Default repository, admin role or above — the same setting onboarding’s Where new issues go offers when repositories are first connected.

Pealboard does not create repositories. If none of the ones you connected fit, Create an issues repository on GitHub opens GitHub’s own new-repository page, with the name filled in; the GitHub App does not hold the permission to create one itself. After you create it on GitHub, add it to the Pealboard App’s own repository list — Settings → GitHub → Change repositories on GitHub — and it appears here on the next sync.

A workspace with no default is a valid state: New issue asks for a repository every time instead of pre-filling one. Turning sync off for the repository that is the default clears it, on the workspace and on every portal that inherited it, because a default that quietly stopped being mirrored would create issues Pealboard never showed again.

Settings → Workspace, Workspace name, then Save. It needs the admin role or above, and it changes the name every member and every portal link shows.

The address does not move. It is unique across every workspace and links already point at it, so there is no field for it and no route that changes one.

Settings → Workspace → Delete workspace, and only the owner may. Type the workspace address to confirm.

It deletes the workspace and everything in it: members, portals and their requests, companies and customers, views, saved filters, notifications, API keys and the audit log, and Pealboard’s cache of the issues, comments, projects and labels. It happens in one transaction, so a failure part-way through leaves the workspace as it was.

Nothing in GitHub changes. The GitHub App is unbound and never uninstalled — the installation belongs to the GitHub account, and removing it is done from that account’s own settings. The issues, the comments and the projects are the repository’s and stay exactly as they are, including the attribution Pealboard wrote into them.

It is refused while a Stripe subscription is active or past due, so nobody deletes a workspace and keeps being charged for it. Cancel it in the Stripe customer portal behind Manage billing first. A trial is cancelled here, because it costs nothing and there is nothing to cancel in Stripe.