Docs / Tenants & Bandwidth

CENVERO/DOCS

// Tenants & Bandwidth

Tenants & Bandwidth

A tenant is a named owner you attach resources to — networks, addresses, API keys and a bandwidth allowance. If you run workloads for several customers, teams or environments on the same hardware, tenants are how you keep them apart and how you cap what each one can consume.

If everything on your nodes belongs to you, you can ignore tenants entirely. Nothing requires one.

What a tenant actually separates

Creating a tenant does not create an enclosure that traffic cannot leave. It creates an ownership label plus two things that are genuinely enforced:

What you get	What it does
Ownership of resources	Networks and addresses are recorded against the tenant, so you can see and delete everything one customer owns as a unit.
A scoped API key	A key that can act only for that tenant — it cannot read or change another tenant's resources.
A bandwidth cap	A real rate limit, applied in the traffic path. See below.

Isolation between tenants comes from the network design — separate networks and firewall policy — not from the tenant record itself. Two tenants whose networks you have connected can reach each other; the tenant label does not stop that. Put each tenant on its own network and set your firewall default action to deny, and the separation is real. See Zero-Trust Firewall.

sudo cenvero-str-ctl tenant create --name acme
cenvero-str-ctl tenant list

Deleting a tenant is a cascade — it removes that tenant's API keys, quota, networks and address allocations together:

sudo cenvero-str-ctl tenant delete <tenant-id>

Scoped API keys

A tenant key lets you hand out API access that is confined to one tenant, instead of sharing an operator key that can change everything.

# Mint a key (optionally labelled, optionally time-limited)
sudo cenvero-str-ctl tenant key-generate <tenant-id> --name "acme-portal" --ttl 720h

cenvero-str-ctl tenant key-list <tenant-id>
sudo cenvero-str-ctl tenant key-revoke <key-id>

The key is shown once, when it is minted. Give it a TTL if it is going into a system you do not fully control — a key that expires on its own is one less thing to remember to revoke.

The tenant quota

A tenant's quota is its bandwidth cap, and that is the only resource capped. 0 means unlimited.

sudo cenvero-str-ctl tenant quota-set <tenant-id> --max-bandwidth-bps 1000000000
cenvero-str-ctl tenant quota <tenant-id>

Everything else is deliberately unlimited on every plan — there is no cap on how many addresses, workloads, networks or firewall rules a tenant may have. If you need those bounded for commercial reasons, bound them in your own provisioning layer, where you can refuse the request and tell the customer why.

Your plan's speed ceiling

Above every limit you set yourself sits one you do not: your licence carries the maximum speed the node may use, and it is applied to the node's uplink.

Plan	Maximum speed per node
Lab (free, non-commercial)	1 Gbps
Core	10 Gbps
Cloud	25 Gbps
Enterprise	100 Gbps

These are the current plans. The pricing section of the site is the authoritative list — your own ceiling is whatever your licence carries, which you can read with cenvero-str-ctl license status.

Four things worth knowing:

It is per node, not per account. Ten Core nodes are ten separate 10 Gbps ceilings, matching how the plans are priced.
It is the node's total, shared across all its network cards. A licensed node behaves as though its cards have exactly that much capacity between them: a 2 Gbps licence on a single 10 Gbps card passes 2 Gbps, and two cards share the same 2 Gbps — you can distribute traffic across them however you like, but the total is still 2 Gbps. Adding a card does not give you more headroom. (Your management interface is deliberately left alone — throttling the control plane would take the node out of its cluster.)
Speeds are bits per second, the way link speed and the plans are quoted — not bytes.
It applies on top of anything you configure. A tenant limit of 5 Gbps on a Core node gives that tenant 5 Gbps; setting a tenant to 50 Gbps does not lift the node past 10.
Changing plan takes effect without a restart. The node re-reads its licence periodically, so an upgrade raises the ceiling within about a minute of the new licence landing.

Going over the ceiling does not fail — it throttles. Traffic above the rate is held to it, exactly as described for bandwidth limits below, so a transfer slows rather than breaking.

The ceiling behaves like any other cap here — a credit allowance refilling at the licensed rate, with burst headroom so ordinary traffic is not penalised. See what that means for TCP and UDP below.

Bandwidth limits

Bandwidth is the one resource control that is real, and it is applied on the way out of a node — egress shaping. A limit is a rate in bits per second, and 0 always means unlimited.

There are two ways to apply one, and they answer different questions.

Per tenant — "this customer gets 1 Gbps in total":

sudo cenvero-str-ctl tenant quota-set <tenant-id> --max-bandwidth-bps 1000000000

Per target — "this particular workload gets 100 Mbps", regardless of who owns it:

cenvero-str-ctl bandwidth list
sudo cenvero-str-ctl bandwidth delete <id>

A per-target limit is submitted as a JSON object describing what to limit and at what rate — see the API Reference for the field names, and CLI Reference for the command form.

Pools

A pool is a shared allowance that several targets draw from together, rather than each holding its own independent cap. Use it when a group should be limited collectively — "these five workloads share 500 Mbps between them" — instead of five separate 100 Mbps limits that cannot lend capacity to one another.

cenvero-str-ctl bandwidth pool --help

What a limit does to traffic

This is the part to understand before you set one, because the behaviour is not what "shaping" usually implies.

A limit is a credit allowance that refills at the rate you set. Every packet spends credit equal to its size. While there is credit, traffic passes untouched. When the credit runs out, traffic over the rate is dropped — not queued and delivered late.

That distinction matters:

TCP copes well. Loss is exactly the signal TCP uses to slow down, so a TCP transfer finds the rate and settles there. This is the normal case and it works.
UDP does not. Nothing tells a UDP sender to slow down, so anything over the rate is simply lost. Video, voice, game traffic and metrics streams degrade rather than slow down. Size the limit for the peak these need, not the average.

Unused credit accumulates up to a ceiling, so a burst after a quiet period passes at full speed and only sustained traffic is held to the rate. A short spike is not punished.

Two more consequences worth planning around:

The cap is per node. A tenant with workloads on three nodes has the limit applied on each of them — it is not a single allowance summed across the cluster.
It applies on the way out. Limiting what a workload can receive means limiting whoever is sending to it, which you only control if the sender is also yours.

Monthly usage quotas

Separately from rate limiting, a node can track how much a workload transfers per calendar month and act when it crosses a threshold. This is a volume cap, not a speed cap — the two are independent, and you can use either or both.

cenvero-str-ctl quota list
cenvero-str-ctl quota get <mac>

Counters reset at the start of each month. Use rate limits to control how fast a tenant can go, and monthly quotas to control how much they can move in total.