What you are running

You are running one Helm chart, platform, on your own Kubernetes cluster. It stands up a complete Solvegio deployment: the API, an auth realm, a web tier, the data services, and a license agent.

The chart plays one of two roles. You pick the role at install time and everything else follows from it.

MVNE or MVNO

An MVNO sells connectivity to end customers. It has a storefront, a catalog, customers who buy eSIMs, orders, subscriptions, and support tickets. If you are selling travel eSIMs under your own brand, you are running an MVNO.

An MVNE sits behind MVNOs. It holds supplier integrations and a wholesale catalog, and it provisions and licenses the MVNOs downstream of it. Its web tier is an operator console, not a shop. If you are white-labeling storefronts for your own customers, you are running an MVNE.

Both roles come from the same chart and the same install command. platform.kind selects the role, and the API image (solvegio/mvne-api or solvegio/mvno-api), the web image, and the Kafka client id all derive from it. Nothing else in the command changes:

--set platform.kind=mvno   # or: mvne

If you install from a repo checkout instead of the published chart, values-mvno.yaml and values-mvne.yaml set that one key for you. The two forms render identically.

An MVNO does not have to sit under an MVNE. It can activate directly against the Solvegio Hub, which is the normal shape for a single operator running their own storefront. An MVNE only enters the picture if someone is reselling to you, or if you are the one reselling.

What the Hub is

The Solvegio Hub is our service. It is the thing that knows your deployment exists, issues its license, and can revoke it. It is not part of what you install.

Your deployment talks to the Hub for a small, fixed set of reasons: it enrolls once with the activation code you give it, it renews and rotates its lease on a schedule, and it sends a periodic heartbeat. Those are all outbound calls from your cluster to https://hub.solvegio.com, the default value of activation.parentUrl.

The Hub never opens a connection into your cluster. There is no callback, no webhook we deliver to you, no agent we log into, no port you open for us. Your ingress does not need to admit anything from us. If your cluster can make HTTPS requests out, the licensing chain works. If it cannot, the deployment stops serving when its lease expires, and we still cannot reach in to fix it.

Revocation works the same way, in reverse. We flip a row on our side. Nothing pushes to you. Your deployment discovers it on its next check-in and parks itself. See How licensing works for the full lifecycle, and What phones home for exactly what leaves your cluster.

What you own

The cluster is yours. We have no credentials for it and no access path into it.

The database is yours. It runs in your namespace by default, or against a managed Postgres you point the chart at. Your customer data, your orders, your SIM inventory: we never see any of it, and we have no way to query it. The usage counters the heartbeat reports are aggregate numbers your own deployment computes and sends.

The signing key is yours. It is generated inside your cluster, on first enrollment, by the license agent. The private half is written into a Kubernetes Secret in your namespace and never leaves it. The Hub only ever sees the public half and a proof that you hold the private one. Your key never leaves explains the mechanism.

Next: Architecture, for what a single helm install actually brings up.