DocumentationLicense
Cloud
Cloudbeta

Regions and data residency

Choose where a published gateway runs, what a region choice commits to, why an instance stays where it was placed, and how to move one when you need to.

Every published instance runs in one region — a specific cluster in a specific place. --region picks it; if you don't pass one, the platform places the instance for you.

bash
mcpg cloud publish edge --config gw.yaml --region eu-west-1

Which regions you can use depends on your plan. mcpg cloud whoami shows the ones your organization is entitled to.

What a region choice actually commits to

The instance's pods, its config, and the traffic it terminates all stay in that region. That is the useful guarantee, and it is the one the placement system enforces structurally: a request for a region your plan doesn't grant is refused at publish time rather than quietly placed somewhere else.

text
403 region_not_licensed

If you see that on a plan you believe includes the region, your access token may predate the entitlement — sign out and back in, or wait for the licence refresh.

Data residency

Residency is a stronger promise than a region, and a separate one. A region says where the gateway runs. Residency says the whole control surface for your organization — its records, its audit trail, and any captured request payloads — lives inside one jurisdiction and never leaves it.

That is not something a region flag can deliver, so it isn't sold as one. A residency commitment is part of an enterprise agreement, and organizations under it are served by a control plane inside that jurisdiction. Once your organization is set up that way, everything follows automatically: publishes can only land on clusters inside the domain, and requests that reach a different control plane are redirected to yours rather than answered.

If you need this, talk to us — it's configured per organization at onboarding, not toggled per publish.

An instance stays where it was placed

Once an instance is running, its placement is fixed for its lifetime. Re-publishing the same name updates it in place, on the same cluster.

That means a re-publish with a different --region is refused:

text
409 placement_pinned

This is deliberate. The alternative — accepting the flag and ignoring it — would let you believe you had moved a workload that had not moved. Publish without --region to update in place.

Moving an instance

Moving is a real operation, not a side effect of a publish, because it is not seamless: the new instance is brought up alongside the old one, verified, and only then does the hostname point at it. Clients reconnect across a DNS propagation window.

To move an instance, ask support or use the migrate API with the target region. The instance keeps its name, its endpoint URL, and its config version history — only the cluster underneath changes.

Dedicated and bring-your-own clusters

Two options exist above shared capacity:

  • Dedicated — your organization's instances are the only ones on the cluster. Requested per organization; placement then refuses to schedule anyone else there.
  • Bring your own cluster — your Kubernetes cluster joins the platform as a placement target. It dials out to us; we never hold credentials to your apiserver, and nothing runs there that you didn't accept. Your instances are placed on it like any other cluster, and the rest of the product — publish, versions, rollback, logs — works unchanged.

Both are enterprise arrangements. Email agent@mcpg.dev.

Where to go next