> ## 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. # Networking, security, and data flow BYOC is currently in **early access**. [Contact us](mailto:support@stigg.io) to learn more or join the program. ## Network topology BYOC components run inside a VPC (or equivalent isolated network) in your cloud account. Your application services communicate with BYOC endpoints over your internal network — usage events and entitlement checks never leave your environment. ``` Your application → BYOC metering endpoint (internal) Your application → BYOC entitlement endpoint (internal, if access enforcement enabled) BYOC environment ↔ Stigg Cloud (for catalog sync, billing rollups, governance updates) ``` ## Egress-only connectivity Your BYOC cluster operates in **egress-only mode**. The data plane initiates all connections to Stigg Cloud — Stigg Cloud never initiates an inbound connection into your VPC. This means: * No inbound ports need to be opened on your firewall or security groups * No VPN peering or network gateway with Stigg is required * Adding Stigg's IP ranges to your allow-list is optional for standard operation, but required if you want to view pre-aggregation metering events through the Stigg UI (which queries your cluster directly) Your BYOC environment sends two types of outbound traffic to Stigg Cloud: * **Aggregated usage rollups** — periodic counters used for billing. Raw event payloads are never transmitted. * **Metering configuration pulls** — the cluster periodically fetches feature and plan configuration updates from Stigg Cloud. Stigg Cloud sends no event payloads, no raw telemetry, and no customer data back to its own systems. Only the aggregated totals required to compute billing are transmitted. ### Outbound connectivity summary | Traffic | Direction | Purpose | | ------------------------- | ------------------------ | -------------------------------- | | Aggregated usage rollups | Your cloud → Stigg Cloud | Billing | | Catalog and configuration | Your cloud ← Stigg Cloud | Plan/feature updates | | Credits and governance | Your cloud ← Stigg Cloud | Credit grants, governance config | | Subscription sync | Your cloud ← Stigg Cloud | Subscription lifecycle events | All connections are outbound-initiated from your cluster and encrypted with TLS 1.2+. Stigg Cloud does not initiate inbound connections into your VPC. ## Data residency | Data type | Stays in your cloud | Sent to Stigg Cloud | | -------------------------------------- | --------------------------- | ------------------- | | Raw usage events | ✓ | Never | | Customer records (optional component) | ✓ | Never | | Subscription data (optional component) | ✓ | Never | | Aggregated usage totals | ✓ | ✓ (for billing) | | Product catalog (plans, features) | Replicated from Stigg Cloud | — | Raw event data never leaves your environment. Only the aggregated usage totals required for billing are sent to Stigg Cloud. ## Encryption * **At rest** — all persistent storage (databases, event buffers) is encrypted using your cloud provider's native encryption keys (KMS/CMK where available) * **In transit** — all communication within your environment and between your environment and Stigg Cloud uses TLS 1.2+ * **Key management** — encryption keys are managed in your cloud account, giving you full control ## Maintenance and operational access When Stigg needs to perform maintenance or debug an issue in your environment, operations are executed by the **BYOC-runner** — a component running inside your cloud account that pulls action requests from Stigg Cloud rather than waiting for inbound connections. This keeps the egress-only model intact even during active operations. * Stigg queues an action request (e.g. a diagnostic script or configuration fix) in Stigg Cloud * The BYOC-runner polls Stigg Cloud, retrieves the request, and executes it within your account * Every action is fully audited — a record of what ran, when, and by whom is retained in your cloud account's audit log * No direct inbound access to your account or VPC is required at any point You retain the ability to revoke Stigg's IAM role at any time. Note that revoking access will prevent Stigg from performing upgrades or responding to incidents in your environment. ## Container image supply chain Stigg-built container images are **never pulled from an external registry at runtime**. During the provisioning phase, every image required by your BYOC deployment is mirrored into an in-account container registry (ECR, Artifact Registry, or ACR) within your cloud account: * Your Kubernetes cluster pulls images only from your own registry — there is no dependency on a Stigg-hosted registry at runtime * A breach of Stigg's credentials or registry cannot affect your running workloads * All images are scanned for CVEs before being mirrored into your account ## Access control Stigg's access to your account is controlled by: * A least-privilege IAM role or service account granted to Stigg and scoped exclusively to BYOC deployment resources * Audit logging of all actions taken by Stigg in your account — contact your Stigg representative for details on how audit records are surfaced in your environment * Access is scoped to BYOC resources only — Stigg cannot access other workloads or data in your account ## Compliance posture Running Stigg components in your own cloud account contributes to your compliance posture in several ways: * End-user data is processed and stored within your cloud region and account, satisfying data residency requirements * Your cloud provider's compliance certifications (SOC 2, ISO 27001, HIPAA BAA, etc.) extend to the infrastructure running BYOC components * Stigg's SOC 2 Type II certification covers the management plane and sync channel Contact us to discuss specific compliance requirements for your organization.