Create a project

By the end of this page one team has a namespace of their own on the supervisor, with its own slice of the address plan, isolated from every other project unless you said otherwise — and you will have verified all three rather than assumed them. This page starts where Platform onboarding ended: Networking is done, so there is an address plan to carve from. Projects explains what a project is; this is how you make one.

​

What this changes on your cluster

A namespace, and the Cilium objects for whichever slices you asked for: a CiliumPodIPPool, a CiliumLoadBalancerIPPool, one or more CiliumEgressGatewayPolicy objects, a CiliumNetworkPolicy when isolation is on, and a Service that advertises the egress address. An isolated project also gets a gateway of its own by default: Gateway <name>-envoy and its EnvoyProxy, with a VIP from the project’s LB pool. No row is written to Celum’s database. A project lives entirely in Kubernetes, which is why the supervisor is also where its address book is read from: the set of taken CIDRs is computed from the live cluster on every create, not from a ledger that could drift.

​

Before you start

• An onboarded supervisor. Cilium must be running; the objects above are all Cilium CRDs.
• The supervisor’s pool config must be seeded. Without it POST answers 412 — “supervisor pool config not set — configure pod supercidr (Cilium) + egress pool (NuviraClusterConfig) first”. This is the supervisor-wide address plan every project is carved from, and it is set once per supervisor.
• Permissions: project:GetConfig to read the plan, project:List to see what is taken, project:Create to make one. All are scoped supervisor:<name>:project:*.

​

The shape of it

Read what is free → pick the slices → create → verify it took. The first and last steps are the ones people skip, and both failure modes are quiet.

​

Step 1 — Read the address plan and what is already taken

Result: seeded: true, and a list of existing projects with their podCidr, lbCidr and egressIp. Those are the ranges you must not pick.

​

Step 2 — Choose the slices, and know what empty means

Five decisions, and an empty value does not mean the same thing for each of them. An empty pod CIDR or egress address inherits: nothing is created for the project. An empty LB range gets the next free slice of the LB band. An empty VM-identity range is decided later, when the first VM asks for an identity address. Read the second column before you leave a field empty. Three switches default to on. The first two are omitted-means-true, and the third follows the first:

• defaultIsolationPolicy — a new project is isolated unless you opt out. It creates a default-deny CiliumNetworkPolicy in the namespace.
• observabilityEgress — whether that isolation policy opens egress to the monitoring endpoints. It is only meaningful when isolation is on, since with no policy there is nothing to gate. Turning it off silently breaks every guest agent’s metrics and log shipping, which surfaces later as an empty dashboard rather than as an error here.
• dedicatedGateway (Dedicated Envoy in the form) — omitted, it follows isolation: an isolated project gets an Envoy gateway of its own wherever the supervisor can run one, and a line in warnings where it cannot. false keeps the project on the shared gateway; true is refused with 409 where it cannot work. See Projects → Dedicated Envoy.

A fourth, kamajiCPAccess (Kamaji control planes), defaults to off; creating a Kamaji cluster in the project turns it on.

​

Step 3 — Create it

The name must be a DNS label — ^[a-z0-9][a-z0-9-]{0,40}[a-z0-9]$ — because it becomes a namespace. Three refusals, each meaning something different: That last one is worth expecting rather than treating as an error. The taken-set is read live, so two people creating projects at the same moment can collide. Celum’s own end-to-end suite treats a 400 here as “re-read the plan and pick the next free slice”, and retries twice before giving up. Do the same. Result: 201, and the project appears in the list.

​

Verify

Three checks, in this order. Each one catches something the previous cannot. The namespace is proj-<name>, not <name>. Read it off the project rather than constructing it — this is the first thing Celum’s own test run got wrong on live infrastructure. The allocation that came back is the allocation you asked for. Compare podCidr, lbCidr and egressIp on the created project against what you sent. A mismatch means a re-pick happened somewhere. The profile actually took. isolationPolicyPresent is the actual state and defaultIsolationPolicy is the desired one — they are separate fields precisely because they can disagree. With egressNodeCount set, check that the expected number of egress IPs exists, one per candidate node. Then check on an independent path, the supervisor itself: kubectl get ciliumpodippools,ciliumloadbalancerippools lists the project’s pools with the ranges Celum returned. The address plan (GET /api/supervisors/{name}/networking/address-plan, MCP get_address_plan) shows them as taken. A project that looks right in Celum and is absent from the cluster is a real failure, and only a second path can see it.

​

If you need to undo it

Deleting a project deletes its namespace and everything in it. It is also the one operation here with no MCP tool: removing a project requires a person. Delete is not always immediate, and the responses say which case you are in: Afterwards, confirm the allocation was released: the project’s pools are gone from kubectl get ciliumpodippools,ciliumloadbalancerippools, and the address plan offers the range again. A deleted project that leaks its subnet blocks whoever asks for that range next.

​

What commonly goes wrong

​

Next