First login

A freshly installed platform has an organization but no workspaces, and a workspace needs an environment to provision its namespace into. The console therefore walks the first organization admin through creating both before showing anything else.

Who sees the onboarding

When an org admin signs in and the organization has zero workspaces, the console renders a two-step setup flow in place of the normal shell. There is no way around it — nothing else in the console is useful until a workspace exists.

Members (non-admins) who sign in before setup is complete see the normal console with a "No workspace access" empty state instead: members cannot create workspaces, so the screen tells them to ask an organization admin to add them to a workspace and refresh.

Step 1 — create the in-cluster environment

The first environment must be in-cluster: it runs on the platform's own cluster, so no kubeconfig is needed. You only choose a name (the default is In-cluster).

Remote clusters (bring your own kubeconfig) can be added later under Cloud → Environments (see Workspaces and environments) — only the first environment is required to be in-cluster.

Step 2 — create the first workspace

Next you name the first workspace. Creating it provisions one Kubernetes namespace on the environment's cluster — the flow shows "Provisioning namespace…" while this happens.

On success the console selects the new workspace as your Build scope and lands you on Build → Overview. From here you can invite teammates (Organization → Settings) and create your first agent.

After onboarding

The two-step flow never appears again once a workspace exists. Additional workspaces are created from the workspace picker in the sidebar ("+ New workspace" — org admins only), and additional environments from Cloud → Environments.