Gateway Fleet

Use Gateways to manage the control-plane inventory of connected gateway runtimes. The fleet view answers which runtimes are registered, when they last reported, which agent they serve, and which configuration they report.

It does not replace the local service manager. kt gateway status describes a locally installed process; the console describes the API's view of a connected gateway.

Register a connected gateway

1. Open Gateways and start gateway registration.
2. Enter a durable gateway name and the requested connection details.
3. Select an active agent when the gateway should be bound during setup.
4. Review the generated runtime command.
5. Run that command only in the intended gateway environment.
6. Return to the fleet and wait for the first report.

Treat the generated machine credential as a secret. Do not paste the command into tickets, shared chat, screenshots, or shell history retained outside your approved operational controls.

Connected relay mode is designed for gateways that initiate an outbound control connection, including runtimes behind NAT. It does not make every displayed hostname or endpoint reachable from every network.

Read fleet status

The fleet view can expose:

• connection and health state;
• endpoint and hostname metadata;
• current agent and configuration context;
• management mode;
• last-seen time; and
• creation and update time.

Interpret the fields separately:

Signal	What it proves
Registered	The API has a gateway record.
Recently seen	The control plane received a recent report.
Healthy	The reported health check passed for the represented runtime.
Agent bound	The control plane records the agent relationship.
Configuration shown	The gateway reports or is assigned that configuration context.
Representative request succeeds	The application can reach the gateway, provider routing works, and the exercised policy path completes.

No single inventory badge proves the last row.

Use the gateway detail view

Tab	Use it for
Overview	Identity, endpoint, agent binding, configuration, health, and Context Fabric summary
Runtime	Runtime and provider telemetry
Tags	Resource classification and grouping
Audit	Gateway-related Trail records

Legacy action and performance URLs redirect into the corresponding detail tabs. Bookmark the gateway detail page and select the tab you need.

Provider metrics are operational telemetry. A missing metric can mean no traffic, delayed reporting, a disconnected gateway, or insufficient access; it is not automatically a zero.

Verify a new or changed gateway

Use this sequence:

1. Validate the intended config with kt config validate.
2. Resolve providers and credentials with kt gateway check.
3. Start the runtime with --agent whenever using --policy-config.
4. Confirm the gateway appears and reports in the fleet.
5. Confirm the agent binding and configuration version.
6. Check /healthz for process health.
7. Send a representative supported request through the gateway.
8. Find the request with kt events tail --since 10m --json or GET /v1/events?since=10m; use History only when capture applies and retained session context is needed.
9. Review the related Trail chronology for control-plane changes.

The direct request is essential. /healthz does not call a provider or execute the full request policy path.

Rotate a machine token

The control-plane API supports POST /v1/gateways/{id}/machine-token; the current gateway detail view does not expose that operation as an interactive console control. Use an authorized, reviewed API workflow.

When a gateway credential may be exposed or is due for rotation:

1. Identify the exact gateway and maintenance window.
2. Call the machine-token rotation operation. The rotation transaction revokes the gateway's existing active runtime tokens before it returns the replacement, so plan for the runtime to lose its old credential immediately.
3. Copy the replacement token when returned; it is not a credential to recover later from the gateway record.
4. Update the runtime's secret source.
5. Restart or reconnect the runtime as required.
6. Confirm a new last-seen report and a representative request.
7. Review Trail.

Avoid sharing one machine credential across unrelated gateway records.

Remove a gateway

The fleet supports bulk deletion only for eligible, non-read-only records. Before removal:

• drain or redirect application traffic;
• unlink or replace the agent binding;
• preserve configuration and evidence needed for review;
• remove service-manager state separately when the runtime is locally installed; and
• confirm the record is not still declared by a control manifest.

Deleting the control-plane record does not guarantee that an independently managed process has stopped.

Next steps

• Connected Gateway Relay
• Gateway Administration
• Agents in the Console
• Config Validation
• Troubleshooting