Regions overview

A region runs the gateway stack close to the environment it protects.

A region is an Outgate gateway deployment that you run in the environment where traffic should be handled. Instead of sending all requests through one shared hosted gateway, you can place the gateway, guardrail service, logging service, Launchpad, and region agent close to your applications and data.

The global console remains the control plane. It creates the region record, generates the deployment configuration, sends commands, and displays status. The region itself handles request routing, guardrail validation, logging, metrics, and local service health.

This split keeps operational control centralized while letting runtime traffic stay inside the region you deploy.

What a region runs

The generated stack includes gateway, Redis, log manager, guardrail, Launchpad, and region-agent services.

When you download a region deployment, Outgate generates a Docker Compose stack for the services that make up the regional gateway.

The generated environment file includes identifiers for the region and organization, a webhook secret, an internal API key, database and Redis passwords, and any connectivity settings needed for the selected region mode.

Creating a region

Region creation prepares the control-plane record and deployment credentials.

Regions are created from the console by an organization owner or administrator. The current implementation requires a Pro plan with the Pro license accepted before a region can be created.

During creation, Outgate generates a region ID, a webhook secret, and an internal API key. These values bind the deployed stack back to the control plane and are included in the generated configuration you use when deploying the region.

For public regions, you provide a region URL that the control plane can reach. For private regions, Outgate creates the queue and scoped credentials needed for outbound-only command polling.

Private and public connectivity

Regions can receive commands over signed HTTP or by polling SQS.

Outgate supports two connectivity models for control-plane commands. The runtime gateway behavior is the same in both modes; the difference is how configuration changes reach the region agent.

Private mode is outbound-only from the region. The region agent polls its queue, executes commands locally, and posts signed results back to the control plane. Public mode accepts signed command requests at the region agent and verifies the signature before executing them.

Both modes use signed callbacks and signed heartbeats so the control plane can verify that updates are coming from the expected region.

Deploying the stack

The console produces Docker Compose and environment configuration for the region.

After a region is created, the console can generate the Docker Compose file and environment configuration for that region. The files are specific to the organization, region ID, connectivity mode, and generated secrets.

The stack starts the gateway, runs the gateway database migration, starts Redis, and then brings up the log manager, guardrail service, Launchpad, and region agent. The region agent also ensures required gateway extensions are present, including request correlation and global Outgate key extraction.

Public regions include HTTP command settings and the region endpoint in the generated environment. Private regions include the AWS and SQS settings needed for command polling.

Command flow

The region agent turns console actions into local gateway configuration changes.

Most region operations begin as commands from the control plane. Creating providers, updating shares, changing gateway configuration, managing chat sessions, and related actions are delivered to the region agent, which applies them to the services running inside the region.

In private mode, the control plane writes commands to the region SQS queue. The agent long-polls the queue, routes each command to the appropriate local handler, and sends a signed callback when the command completes or fails.

In public mode, the control plane sends a signed HTTP POST to the region agent. The agent verifies the signature, executes the command, and returns the command result through the same command path.

This keeps direct service mutation inside the region. The console decides what should change, but the region agent is responsible for applying those changes locally.

For chat and sandbox operations, the region agent forwards commands to Launchpad. Launchpad owns the regional thread lifecycle, starts sandbox containers, brokers messages, and records the stream state needed to resume or inspect sessions.

Heartbeats and health

Regions report service health, versions, uptime, and rotation state back to the console.

The region agent sends periodic signed heartbeats to the control plane. A heartbeat includes the region identity, service versions, stack status, uptime, heartbeat interval, and the public endpoint when one is configured.

Before sending the heartbeat, the agent checks the local stack, including the gateway, log manager, and guardrail service. The console uses that data to show whether the region is connected and healthy.

Heartbeats also support credential rotation. The control plane can return updated webhook secrets or AWS credentials, and the region agent applies those updates for future communication.

Guardrail LLM configuration

The regional guardrail service has its own model configuration.

The guardrail service runs inside the region and can be configured with its own LLM settings. This model is used for guardrail analysis and is separate from the upstream providers that handle application traffic.

The generated environment includes guardrail LLM configuration so the service can reach the model you choose for validation. In local or private deployments, teams commonly point this at a local or internal model endpoint. In other deployments, it can use an OpenAI-compatible endpoint.

Because guardrail evaluation happens in the region, sensitive request content can be inspected and anonymized before any application request is forwarded upstream.

Data and operational boundaries

Runtime logs and guardrail state are kept in the regional stack.

Regions are designed so runtime gateway data is handled by the regional services. Request logs, response metadata, metrics, guardrail decisions, and detection state are stored in the regional Redis and served by the regional log manager.

The console can read regional data through the region APIs, but the request path, logging path, and guardrail path live in the deployed region. That boundary is what lets a team operate a gateway close to the applications and data it protects.

The global control plane still stores the region record, command state, connectivity metadata, and the configuration needed to manage the region. It does not replace the local services that process runtime traffic.

Operational considerations

Treat a region as infrastructure that needs reachable dependencies and monitored health.

A region depends on its local services starting in the expected order. The gateway needs its database and migration, gateway extensions need to be installed, Redis needs to be available for logs, guardrail state, and Launchpad thread state, and the guardrail service needs access to its configured analysis model.

Private regions also depend on SQS access and valid scoped AWS credentials. Public regions depend on a stable endpoint that can receive signed control-plane commands.

Heartbeats are the main signal for whether the control plane can still manage the region. If heartbeats stop, the runtime gateway may still be serving traffic locally, but the console will not have a current view of health or command progress.

Bringing it together

Regions keep the gateway path local while preserving central control.

Once a region is deployed, your applications send traffic to the regional gateway. The gateway authenticates the request, applies guardrails, routes to the selected provider, and records logs and metrics inside the regional stack.

The console remains the place where teams create regions, review status, send configuration commands, and inspect operational data. The region agent bridges those control-plane actions to the local gateway services.

That gives teams one control surface for Outgate while keeping the request path close to the systems that use it.