complianceCI/CDcloud

Sovereign Preprod Patterns: Deploying Isolated CI Runners in a European Sovereign Cloud

UUnknown

2026-02-05

10 min read

Deploy CI runners and artifact storage entirely inside an EU sovereign cloud. Step-by-step patterns to guarantee data residency, traceability, and legal assurances.

Ship confidence — without leaving the EU: isolated CI runners for sovereign preprod

Pain point: Your CI builds or test artifacts accidentally cross borders, weak audit trails leave you exposed to regulatory risk, and Devs can’t reproduce production bugs because preprod drifts from the production footprint. In 2026, those risks are front-and-center: regulators and customers expect demonstrable data residency, supply-chain integrity, and legal assurances.

What this guide delivers

This is a hands-on, step-by-step playbook to deploy CI runners and store build artifacts entirely inside a European sovereign cloud so that your builds never leave EU jurisdictional boundaries. You’ll get architecture patterns, concrete Terraform/Kubernetes examples, security controls, signing and SBOM workflows, and validation steps to present to security and legal teams.

Why sovereign preprod matters in 2026

Major cloud providers launched dedicated sovereign offerings in late 2025 and early 2026 (for example, AWS’ European Sovereign Cloud). Governments and large enterprises increasingly demand technical and contractual assurances that data processing, logs, and artifacts remain under EU jurisdiction. On the security side, the rise of supply-chain regulation (NIS2, EU Digital Resilience trends, and stronger procurement rules) means preprod environments are no longer a “nice-to-secure”—they must be auditable and demonstrably compliant.

"Sovereign clouds combine physical separation, technical controls, and contractual assurances to help organizations meet jurisdictional and regulatory requirements." — observed trend across cloud providers in 2025–2026

Target outcomes (what you’ll achieve)

All CI jobs and build artifacts executed and persisted inside a European sovereign cloud.
Network and identity controls that prevent unauthorized egress and access.
Reproducible, signed artifacts with SBOMs and attestations stored on immutable backing stores.
Audit trails and cryptographic proofs suitable for legal and regulatory review.

High-level architecture

Design an architecture with these layers:

Identity & Access: Enterprise IdP federation (SAML/OIDC), least-privilege IAM roles, SCIM provisioning to SCM.
Network: Isolated VPC with private subnets, no public egress; VPC endpoints for storage/service access; transparent proxy for limited external dependencies.
CI Plane: Autoscaling self-hosted runners (Kubernetes pods or VMs) inside the sovereign cloud. See SRE patterns for autoscaling and observability best practices.
Artifact Layer: Private container registry (Harbor/ECR), object storage for artifacts and SBOMs with server-side encryption (SSE-KMS) and object lock.
Secrets & Attestation: HashiCorp Vault or cloud KMS, sigstore/Cosign for signing artifacts and storing signatures in a CT-like log confined to the sovereign environment.
Telemetry & Audit: Immutable audit storage, SIEM in-sovereign, and retention policies satisfying legal requirements.

Step-by-step: Build a sovereign CI runner platform

1) Plan scope, data map, and legal controls

Start by classifying what constitutes “preprod data” (logs, test data, build artifacts, third-party packages). Create a simple data flow diagram and map the resources that must be contained in the sovereign boundary. Engage legal/compliance to capture specific contractual language or audit requirements you must satisfy (retention windows, encryption standards, certification expectations).

2) Foundation: network and identity

Key goals: prevent unintended egress and enable secure, least-privilege access.

Create an isolated VPC with private subnets. No public IPv4 on runner hosts.
Use private endpoints (S3/ECR equivalents) so artifact storage is accessible without crossing the public internet.
Configure an outbound proxy with allow-listing if your builds require external package registries. Mirror dependencies inside the sovereign cloud where possible.
Identity setup: federate your corporate IdP to cloud IAM and SCM (GitHub/GitLab Enterprise) using SAML/OIDC. Use short-lived tokens and role assumption for ephemeral runner authorizations.

Sample Terraform snippet: private S3 + restricted access

# (Simplified) Create bucket with enforced encryption and restrict to VPC endpoints
resource "aws_s3_bucket" "artifacts" {
  bucket = "company-preprod-artifacts-eu"
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "aws:kms"
        kms_master_key_id = aws_kms_key.artifact_key.arn
      }
    }
  }
}

resource "aws_s3_bucket_public_access_block" "block" {
  bucket = aws_s3_bucket.artifacts.id
  block_public_acls       = true
  block_public_policy     = true
  restrict_public_buckets = true
}

3) Artifact storage & registry inside the sovereign boundary

Choose one or both depending on build artifacts:

Container images: Use a private registry — deploy Harbor in-cluster or use the provider’s container registry (ECR/GCR equivalent) but ensure it’s isolated and bound to the sovereign project/account.
Build artifacts & SBOMs: Use S3-compatible object storage with server-side encryption (SSE-KMS), enable object lock (immutability) for a retention policy, and enable bucket logging to an immutable audit store.

4) Provision the CI runners

Two common approaches:

a) Kubernetes runners (recommended for scale and isolation)

Run GitLab Runner or GitHub Actions Runner Controller as pods that spawn ephemeral job pods. Use PodSecurity admission, resource quotas, and network policies.

# Example: install GitLab Runner with Helm (values simplified)
helm repo add gitlab https://charts.gitlab.io/
helm install gitlab-runner gitlab/gitlab-runner \
  --set rbac.create=true \
  --set runners.privileged=false \
  --set runners.image=specific-runner-image:stable \
  --set metrics.enabled=true

Key controls:

Set runners.privileged=false and use rootless build images where possible.
Use OPA/Gatekeeper to enforce allowed container images and commands.
Mount ephemeral volumes for builds and wipe after job completion.

b) Autoscaling VM runners

Use an autoscaling group or managed instance fleet for self-hosted runners. Attach an instance role with narrow permissions. Use IMDS v2 and limit access to metadata endpoints.

5) Secure the build environment

Security controls you must operationalize:

Network egress control: Deny outbound internet by default; allow only specific endpoints (internal mirrors or approved registries) through a proxy.
Image provenance: Enforce allowed base images and scan images on pull.
Runtime confinement: Use seccomp, user namespaces, and restricted capabilities. Prefer rootless builds.
Secrets handling: Inject secrets at runtime from HashiCorp Vault or cloud KMS via short-lived credentials—never bake them into images.
Ephemeral runners: Ensure runner instances/pods are destroyed after each job or short-lived job pools.

6) Supply-chain hardening: SBOMs, signing, and provenance

Generate an SBOM for every build, produce cryptographic signatures, and store both SBOM and signature inside the sovereign artifact store.

# Example: sign a container image with Cosign inside your sovereign cloud
cosign sign --key ksm://projects/your-kms-key-id \
  eu-registry.company.example/project/app:sha256:abcd1234

# Save SBOM (CycloneDX) to object storage
sbom-generator --image app:latest --output /tmp/app.sbom.json
aws s3 cp /tmp/app.sbom.json s3://company-preprod-artifacts-eu/sboms/app/$(date +%s).json

Use a local instance of a transparency log (or a signing service that writes to an in-sovereign CT-like store) to avoid reliance on public log services that may be outside jurisdictional boundaries. See Edge Auditability & Decision Planes for approaches to local transparency logging and attestation.

7) Auditability: logs, immutability, and proof for legal teams

Retain and protect logs:

Forward runner audit logs to an immutable store with retention policy. Use object lock and server-side encryption.
Collect VPC flow logs, access logs for storage buckets, and CI job metadata (who triggered the build, commit SHA, runner ID).
Keep cryptographic signing records (signer identity, key material fingerprint) and SBOMs together with artifacts.

8) Test and validate the boundary

Before you claim compliance, run these validations:

Perform packet captures or VPC flow analysis during a build to confirm no egress to non-EU IPs.
Review IAM access logs and verify the runner role has only intended permissions.
Attempt to pull an artifact from outside the sovereign cloud to validate access restrictions.
Run a reproducible build from a clean runner and verify the produced SBOM and signature are stored inside the sovereign artifact store.

Concrete pipeline example: GitHub Actions using self-hosted runners

Below is a minimal workflow that uses an in-sovereign self-hosted runner and uploads an SBOM and signed artifact to in-cloud storage:

name: Build and Store Artifact (EU sovereign)
on: [push]

jobs:
  build:
    runs-on: [self-hosted, linux, eu-sovereign]
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: |
          docker build -t eu-registry.company.example/project/app:${{ github.sha }} .
      - name: Generate SBOM
        run: |
          syft eu-registry.company.example/project/app:${{ github.sha }} -o cyclonedx-json > app.sbom.json
      - name: Sign image
        run: |
          cosign sign --key ksm://projects/your-kms-key-id eu-registry.company.example/project/app:${{ github.sha }}
      - name: Push image
        run: |
          docker push eu-registry.company.example/project/app:${{ github.sha }}
      - name: Upload SBOM
        run: |
          aws s3 cp app.sbom.json s3://company-preprod-artifacts-eu/sboms/${{ github.sha }}.json

Notes: The runner tag eu-sovereign limits execution to runners inside your sovereign cloud. All artifact endpoints are inside the VPC and use the provider’s KMS for signing keys when possible.

Operationalizing controls and cost management

To keep costs predictably low while meeting compliance:

Use ephemeral runners that are billed only during the build window—scale-to-zero.
Implement lifecycle rules to move older SBOMs/artifacts to cold storage while preserving immutability and legal retention.
Use spot/interruptible instances for non-critical or reproducible builds where allowed by risk appetite.
Monitor idle runner time and enforce quotas per team to avoid runaway costs — see SRE cost control patterns for guidance.

Advanced strategies and future-proofing (2026+)

As sovereign clouds mature, adopt these advanced controls:

Confidential compute & TEEs: Run sensitive build steps in confidential VMs or enclaves to protect secrets and build graphs from host access.
Policy-as-code: Centralize compliance checks with Rego (OPA) and integrate policy gates in CI to auto-block non-compliant artifact publishes.
Local transparency logs: Operate an in-sovereign sigstore instance or signing authority to avoid reliance on globally distributed public logs.
Provenance attestation: Use in-toto/rekor workflows confined to the sovereign environment for end-to-end provenance.

Common gotchas and how to avoid them

Assuming private registry traffic is always in-bound: verify that your provider’s control plane or any external mirrors do not cause cross-border flows.
Embedding secrets into images: use runtime injection from Vault/KMS and enforce scanning policies to detect secret leakage.
Allowing open egress during debugging: apply temporary, auditable exceptions and revoke immediately after use.
Relying on public signing services: host signing and CT logs inside the sovereign boundary.

Checklist to present to risk/compliance

Data flow diagram showing all build-related data stays within EU sovereign accounts.
Evidence of network controls (VPC flow logs) proving no egress to non-EU destinations.
Key management description showing KMS keys are EU-resident and access-controlled.
Signed artifact + SBOM records stored in immutable object storage.
Runner lifecycle policy demonstrating ephemeral behavior and access revocation.

Actionable takeaways

Design for isolation first: treat network and storage boundaries as primary compliance controls.
Automate ephemeral runners: reduce blast radius and make builds reproducible.
Sign everything: SBOM + Cosign signatures + in-sovereign transparency log = provable provenance.
Audit continuously: collect immutable logs and automate checks for egress or policy violations.

Final notes — legal assurances and vendor selection

In 2026, large cloud vendors offer sovereign offerings with physical separation, contractual assurances, and regional data processing agreements. However, technical controls and operational discipline remain your responsibility. When evaluating vendors, ask for:

Explicit data residency and processing clauses tied to EU jurisdiction.
Details on control plane and control access locations.
Support for in-region KMS and key ownership models.
Audit and certification evidence (ISO 27001, SOC2, and any sovereign-specific attestations).

Call to action

Ready to prove your preprod pipeline never leaves EU soil? Start with a minimal pilot: deploy a Kubernetes namespace in a sovereign account, run a single ephemeral GitHub/GitLab runner, generate an SBOM and cosign it, and retain the artifacts in an immutable bucket. If you want a guided implementation, contact our preprod.cloud team for a hands-on workshop and a compliance-ready blueprint tailored to your EU requirements.

Build in-region. Sign in-region. Prove in-region. That’s how you turn preprod from a compliance risk into a competitive advantage in 2026.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.