Install

Activation

Where the activation code comes from and what the license agent does with it.

Activation

Activation is the one thing your install cannot derive for itself. A deployment has to prove to the Hub that it is the deployment you said it was, and the Hub has to hand back a license that only this cluster can use. The activation code is what connects the two.

Getting a code

You mint the code from the Hub console, against the deployment record for this install. The console calls the admin-gated POST /v1/deployments/{id}/activation-code, so only someone who can already sign in as an operator can issue one.

An MVNO enrolling under an MVNE rather than under the public Hub mints its code from that MVNE's console instead, and passes the parent's URL alongside it:

helm install my-mvno oci://ghcr.io/solvegio/charts/platform --version <chart-version> \
  --namespace my-mvno --create-namespace \
  --set platform.kind=mvno \
  --set platform.host=esim.acme.com \
  --set activation.code=<code-from-the-mvne-console> \
  --set activation.parentUrl=https://mvne.themvne.com

activation.parentUrl defaults to https://hub.solvegio.com. It is the URL the agent enrolls against, and the URL your platform pins as its parent for everything afterwards.

What the code actually is

What the console gives you is one string with two parts joined by a dot: the code itself, and a fingerprint of the parent's signing key. Paste the whole thing into activation.code exactly as the console printed it. Do not split it, and do not trim anything after the last dot.

The fingerprint half is a trust anchor. Before the agent sends the code anywhere, it fetches the parent's public keys from <activation.parentUrl>/.well-known/jwks.json and checks that the fingerprint in your code matches a key that is really published there. If nothing matches, the agent refuses to enroll rather than trusting whatever answered. That check is why the code is worth pasting carefully: it is what stops a deployment from enrolling against something that merely looks like the Hub.

activation.allowUnpinned exists for local smoke runs and nothing else. Released builds refuse an unpinned enrollment whatever that value says.

What happens when the agent redeems it

The order here is the point.

The license agent generates an Ed25519 signing key first, inside your cluster, before it has spoken to anyone. It keeps the private half in your platform Secret, in your namespace. It then signs a proof of possession over the activation request itself (DPoP, RFC 9449) and posts the code, its public key, and that proof to POST /v1/deployments/activate.

The Hub verifies the proof before it touches the code. Only once it is satisfied that the caller really holds the private key does it redeem the code, and the license it mints back is bound to the fingerprint of that public key through a cnf claim (RFC 7800, thumbprint per RFC 7638). A license lifted out of your Secret is worth nothing to anyone who cannot also sign with the key it names.

The private key never leaves the cluster. The Hub only ever sees the public half. Your key never leaves goes through what that does and does not protect you from.

Single use, and short lived

A code redeems once and expires quickly: the default TTL is 15 minutes. Mint it when you are about to run helm install, not the day before. An expired code is not a problem, it is just a code you mint again.

A failed attempt does not burn the code. The Hub verifies the proof of possession before it marks the code consumed, so a bad proof, a network drop, or an agent that crashed halfway through leaves the code exactly as it was: still pending, still redeemable. The agent will keep retrying on its own, and a retry from the same deployment with the same key is treated as the same activation rather than a second one.

Leave the code in your values

Once the code is consumed, the value is harmless where it is. Running helm upgrade again with the same code does nothing at all: the agent tracks the codes it has already used and no-ops on one it has seen.

Keep it there anyway. Recovering a revoked deployment is a fresh code and a helm upgrade, and that path reads activation.code from the same place. See Revoke and recover.

When it does not work

The agent logs every attempt. Start with its logs, which Verify your install shows you how to read, and then Licensing failures for the specific errors. The wider picture, including what happens to the license after activation, is in How licensing works.

Copyright © 2026