> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.

# BYOC architecture

<Note>
  BYOC is currently in **early access**. [Contact us](mailto:support@stigg.io) to learn more or join the program.
</Note>

## Architecture overview

In a BYOC deployment, Stigg provisions a set of services and infrastructure components into your cloud environment using IaC. These components handle usage metering and — optionally — access enforcement and customer/subscription data storage, entirely within your VPC.

Stigg Cloud remains the authoritative source for your product catalog (plans, features, add-ons), credits, and governance configuration. Your BYOC environment receives updates from Stigg Cloud via an inbound sync channel and publishes aggregated usage back to Stigg Cloud for billing and analytics.

<Frame>
  <img src="https://mintcdn.com/stigg/Pb0UHOj_TJTmz7Qt/images/byoc-data-plane-architecture.png?fit=max&auto=format&n=Pb0UHOj_TJTmz7Qt&q=85&s=372bcf17749cf66187eac4859b4c81d2" alt="BYOC data plane architecture: customer cluster on the left ingests events through the Kubernetes metering namespace (Kafka → Flink → ClickHouse), syncs to Stigg Cloud control plane on the right via outbound-only TLS." width="2889" height="1159" data-path="images/byoc-data-plane-architecture.png" />
</Frame>

The diagram above shows a BYOC deployment. Your application sends events into the data plane running in your Kubernetes cluster. The metering namespace processes events through Kafka, Flink, and ClickHouse — all within your VPC. The shared namespace hosts the sync agent, which maintains an outbound-only connection to Stigg's control plane in AWS for catalog updates and aggregated billing rollups.

## Components

### Usage metering

The core BYOC component. All usage events from your application are ingested by the metering pipeline running in your Kubernetes cluster. It handles:

* High-throughput event ingestion (up to 1M events/sec)
* Local buffering and deduplication via **Kafka** running in your cluster
* Real-time stream processing and aggregation via **Flink** running in your cluster
* Durable, queryable event storage in **ClickHouse** running in your cluster
* Cold-tier archival to your own S3 / GCS / Blob bucket, encrypted by your KMS keys, under your retention policy

### Access enforcement (optional)

When enabled, entitlement checks are evaluated against subscription and usage data held locally in your cloud, without any call leaving your network. Responses are sub-millisecond from the local cache.

### Customer and subscription data (optional)

Customer records and subscription state can be stored in your cloud. When enabled, Stigg Cloud pushes subscription changes into your environment so the local copy stays current.

### Full self-host (optional)

All of the above components together. Stigg runs entirely within your VPC. Stigg Cloud acts only as a control plane for catalog, governance, and billing synchronization.

## Connectivity model

Your BYOC environment maintains a persistent connection to Stigg Cloud for:

| Direction                | Purpose                                                                                      |
| ------------------------ | -------------------------------------------------------------------------------------------- |
| Stigg Cloud → your cloud | Inbound sync: catalog updates, subscription changes, credit grants, governance configuration |
| Your cloud → Stigg Cloud | Usage rollups for billing; subscription lifecycle events                                     |

All communication is encrypted in transit. Your end-user data — raw usage events, customer records — does not leave your cloud.

## IaC and deployment

Stigg provisions your BYOC environment using infrastructure-as-code templates managed in Stigg's internal Git repository. This approach ensures:

* Repeatable, consistent deployments across customer environments
* All infrastructure changes go through code review and version control
* Upgrades are applied via the same IaC pipeline that created the environment

See [Deployment and operations](/documentation/high-availability-and-scale/byoc/deployment-and-operations) for details on how upgrades and service rollouts work.

## Data residency

With BYOC, all usage events, customer records (if the optional component is enabled), and subscription data (if enabled) are stored exclusively in your cloud account. Stigg never reads raw event data from your environment. Only aggregated usage totals — needed for billing — are sent to Stigg Cloud.