Workspaces¶

A workspace is an ephemeral pod that runs inside the b'nerd platform for the duration of a session. It gives you a pre-configured development environment: a shell, kubectl pointed at your project's cluster, the bnerd CLI authenticated as you, and optionally a cloned git repository — all scoped to your own permissions and torn down automatically when the TTL expires.

Concepts¶

What a workspace is¶

When you launch a workspace the platform:

1. Mints a set of scoped, time-limited credentials on your behalf: a kubeconfig for the project's target cluster, a bnerd API token (scoped to your access level), and — if you have a git PAT set up and clone is enabled — a clone credential.
2. Provisions a pod in the runtime cluster.
3. Delivers the credentials into the pod's environment so they never touch disk and are never accessible to anyone but the pod itself.

The pod runs until its TTL elapses or you revoke it. When it goes, every credential is invalidated in the same operation.

Runtime cluster vs. target cluster¶

Workspaces use two separate cluster roles:

The two clusters can be the same physical cluster or different ones. The target cluster is what you operate on; the runtime cluster is where your workspace environment lives.

TTL and expiry¶

Every workspace has a TTL (time-to-live), set at launch (default: 1h). When the TTL elapses the pod is removed and all credentials — kubeconfig, API token, git clone credential — are invalidated. You cannot extend a TTL after launch; revoke and relaunch if you need more time.

Access presets¶

When you launch a workspace you choose an access preset that determines which credentials are minted and how much API access the in-pod bnerd token carries. The platform always clamps the granted access to what you actually hold as a project member — a preset can never escalate your permissions.

You can also configure scopes manually (via the CLI --scope flag or the dashboard's advanced access panel) to override the preset defaults.

Credentials and least privilege¶

Credentials minted into a workspace are:

• Scoped to your own permissions. You cannot get more access inside a workspace than you have as a project member.
• TTL-bound. They expire when the workspace expires — never outlive the session.
• Revocable. Revoking the workspace immediately invalidates all credentials, even before the TTL.
• Audited. Each launch, credential mint, terminal open, editor open, and revoke is recorded in the organization audit log.

Kubernetes access scope¶

The kubeconfig minted into your workspace can be scoped at three levels. The level you request is clamped to the maximum your project grant permits.

Use the --cluster-access CLI flag or the advanced access panel in the dashboard to choose a level other than the default.

Network — egress¶

Workspace pods are egress default-deny: outbound connections from the pod are blocked unless you explicitly allow them at launch.

To open outbound access, provide one or more CIDRs at launch time:

• Use 0.0.0.0/0 for unrestricted internet access.
• Use specific CIDRs (e.g. 10.0.0.0/8) to allow access only to internal networks.

Egress rules are set once at launch and cannot be changed while the workspace is active. If you need different egress, revoke and relaunch.

Concurrent workspace cap¶

Each organization has a maximum number of concurrently active workspaces. Launching a new workspace when the cap is reached returns an error; revoke an existing workspace first.

Git clone prerequisite¶

Cloning private repositories into a workspace uses your personal git PAT, not a shared token. This means clone access equals your own access to the repository — no escalation.

Before you can launch a workspace with a git repository:

1. Go to Account (top-right menu) → Git tokens (/account/git-tokens).
2. Click Add git token and enter:
3. Provider — gitlab (or github, gitea).
4. Host — the base URL of your git host, e.g. git.bnerd.net.
5. Token — a PAT with at least read_repository scope.
6. Name — a label for your own reference.
7. Click Save. The platform validates the token against the host before saving.

You need one PAT per git host. The same PAT is reused across all workspaces that clone from that host.

If you try to launch a workspace with --repo and no matching PAT is configured, the launch is rejected with a clear error pointing to this setting.

Browser IDE¶

Every active workspace can be opened in a full browser-based IDE (OpenVSCode Server) without leaving the platform:

• In the dashboard, click Open editor on an active workspace — a new browser tab opens at the IDE, proxied through the platform (no public ingress to the pod).
• The IDE runs with the same credentials as the terminal session — same workspace, same least-privilege context.
• The browser tab is opened at the platform's own origin so authentication uses a short-lived, first-party scoped cookie; no cross-site cookie configuration required.

Limits and defaults¶

Limits are enforced by the org's ceiling configuration, set by a platform admin. A fresh organization gets the platform defaults shown below. To raise a ceiling, contact hello@bnerd.com.