DEMO/Infrastructure

← Back to dashboard

Deploying a Gateway host

Audience: operator · Profile: both · Read this when: you are deploying a Gateway host, choosing its region and naming it.

Part of BeyondTrust Gateway Hosts.

Containers → Gateways → the deploy row at the top of the panel:

Field Notes
Cloud AWS / Azure / GCP. Changing it reloads the region list and re-suggests a name, because both are per-cloud.
Region A picker, not free text. (configured default) leaves it blank — resolved at deploy time — which is what a single-region install wants.
Zone GCP only, optional. Blank resolves from the region; the placeholder shows what that will be.
Name Prefilled with a free, cloud-legal default (gw-<region>-01). Editable.

Deploy gateway enqueues a gateway_deploy job and returns — the row appears immediately as provisioning with a Job link. The work runs on the durable worker, so a gunicorn recycle mid-deploy can't strand a half-built host:

Step What happens
Launching Ensures the host under the name you gave. Passing a name is precisely what marks this gateway as requested — the ensure skips its managed-adoption write, because the row already exists and is owned by the job.
Recording placement Writes back where the host actually landed (zone, egress IP), not what was asked for.
Updating node firewalls Re-applies the Rancher + Portainer node allow-lists. Best-effort — a firewall hiccup logs and never fails the gateway job.
Done Row flips to running with its host id.

Why the row records where it landed rather than what you picked. A blank GCP zone is resolved at launch, and a capacity-exhausted zone falls through to a sibling — so the requested zone is not reliably the real one. Teardown deletes by (zone, name), so a row holding the requested zone would later fail to find its own host.

Placement and the region picker

The picker offers only the configured default region plus every region that has a per-region config set of its own (the same list the Rancher and Portainer node pickers use — region_config.deployable_regions). That restriction is the feature, not a limitation.

The tab used to take the region as free text, and typing an unconfigured region was worse than a validation error. Every regional id a gateway needs — subnet, security group, ECS cluster — resolves through region_config.resolve_region, which falls each field back to the flat config keys. So the host came up on the default region's network while the row, the job, and you all said otherwise. Nothing failed; the gateway was simply somewhere else, with no line of sight to the private targets in the region you meant.

Restricting the picker makes "the region I picked" and "the region it lands in" the same thing. To deploy somewhere new, add that region under Settings → Multi-region first; it then shows up in the picker.

GCP has a second route to the same silent relocation: a gateway's subnet is derived from its zone, so a zone in another region would quietly override the region you chose. The deploy endpoint refuses that pair (HTTP 400) rather than queueing a job that lands elsewhere, and picking a new region clears any leftover zone.

Names, and why they matter more than they look

The name is not cosmetic — it is what keeps the managed and requested hosts apart in the cloud itself, because the managed idle teardown finds its host by name tag. A requested gateway wearing the managed name is one the idle teardown would terminate out from under you. So: