Xeonr Developer Docs
API Specificationcontainers.api.v1.TeamSettingsService

Set Team Default Cluster

POST
/containers.api.v1.TeamSettingsService/SetTeamDefaultCluster

Sets, or with an empty cluster_id clears, the cluster a namespace created for this team is placed on when the request names none. The team must be able to place on the cluster (it owns it, holds a grant, or the cluster is GLOBAL); otherwise PermissionDenied. With it cleared, the platform's default cluster applies.

Access: an admin of the team, or a platform admin.

Authorization

BearerAuth
AuthorizationBearer <token>

A namespace-scoped API key (cpk_…) for machines, or a Xeonr Auth OIDC token for humans. The key's namespace and role are pinned server-side.

In: header

Header Parameters

Connect-Protocol-Version?number

Define the version of the Connect protocol

Connect-Timeout-Ms?number

Define the timeout, in ms

Request Body

application/json

team?string
Match^urn:xeonr:auth:team:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$
clusterId?string

Empty clears it.

Match^(cl-[0-9a-f]{16})?$
[key: string]?never

Response Body

application/json

application/json

curl -X POST "https://containers.xeonr.io/containers.api.v1.TeamSettingsService/SetTeamDefaultCluster" \  -H "Connect-Protocol-Version: 1" \  -H "Connect-Timeout-Ms: 1000" \  -H "Content-Type: application/json" \  -d '{}'
{
  "settings": {
    "team": "string",
    "defaultClusterId": "string"
  }
}
{
  "code": "not_found",
  "message": "string",
  "details": [
    {
      "type": "string",
      "value": "string",
      "debug": {}
    }
  ]
}

Get Team Settings POST

Returns a team's settings. A team the caller is not in is NotFound — which, for a namespace API key, is every team. A team with nothing set yet returns empty settings, not an error. **Access:** any member of the team, or a platform admin.

containers.api.v1.VolumeService

VolumeService manages platform-provisioned volumes: sparse ext4 disk images on node disk, attached by the platform's own CSI driver and mounted into a primitive via WorkspaceMount.volume (common.proto). How this differs from WorkspaceService, which is the question everyone asks: WorkspaceService is a CONTENT store. It knows files, dedupes blobs across every workspace, forks a snapshot for free because a fork is a metadata copy, and works identically whether or not anything is running. What it is bad at is being a filesystem: it has to be copied into the pod, one RPC per file, so start cost scales with file count and the big directories have to be excluded to keep it bearable. VolumeService is STORAGE. It knows bytes, not files. Nothing is copied at start, nothing is synced back, there is no ignore set, and size is a hard cap the filesystem enforces. What it is bad at is being content: a volume cannot be forked or diffed, it is opaque to anything that has not mounted it, and reaching it needs the node holding it to be up. They are complementary rather than competing. Content arrives via seed_snapshot_id and leaves via Archive; in between it is a filesystem. File operations are below. They route to the node holding the volume, which is the only thing that can open the image, and work whether or not a workload is running on it.