BYOC architecture

​

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. 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: 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 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.