Pulumi EU Alternative 2026: Seattle-Based IaC Platform, CLOUD Act 17/25, and Sovereign Infrastructure-as-Code

Post #1 in the sota.io EU IaC Tools Series

Your infrastructure code defines everything: which cloud accounts you use, what resources exist, how they connect, and the secrets that make it all work. When you run Pulumi to provision that infrastructure and store your stack state in Pulumi Cloud, the state files — which can contain resource configurations, output values, and references to secrets — are managed by a company incorporated in Delaware and headquartered in Seattle, Washington. That company is Pulumi Corporation, and it is fully subject to the US CLOUD Act.

The Clarifying Lawful Overseas Use of Data Act (18 U.S.C. §2713) requires US cloud providers to produce data to US law enforcement regardless of where that data is physically stored. Pulumi Cloud does not offer an EU data residency option for state backends. Your Hetzner-deployed infrastructure's state is held on Pulumi's US-governed servers. The EU location of your actual cloud resources is irrelevant to the jurisdiction of the company holding your state.

For EU engineering teams using Pulumi Cloud to manage GDPR-regulated infrastructure, this creates five concrete compliance problems — and forces a practical question: is there an EU-sovereign IaC alternative that provides the same developer experience without the US jurisdiction exposure?

What Pulumi Does and Why DevOps Teams Use It

Pulumi is a cloud infrastructure automation platform. Unlike Terraform (HCL) or CloudFormation (YAML/JSON), Pulumi lets you define infrastructure using general-purpose programming languages: TypeScript, Python, Go, C#, Java, and YAML. You write code that creates cloud resources, Pulumi tracks the current vs. desired state, and executes the minimal change set needed.

The developer experience advantage is real. A TypeScript Pulumi stack can use loops, conditionals, functions, and existing npm packages to build infrastructure that would require hundreds of repetitive HCL blocks in Terraform. Pulumi's component model allows reusable infrastructure abstractions across teams.

Pulumi corporate structure:

• Pulumi Corporation, Seattle, WA (HQ)
• Delaware corporation (incorporated 2017)
• Founded by former Microsoft engineers: Joe Duffy (CEO), Luke Hoban, Eric Rudder
• Total funding: $120M+ (Series C 2022)
• Key investors: NEA (US), Madrona Venture Group (Seattle), Index Ventures (UK/US)
• Workforce: ~250 employees, primarily US-based with full access to Pulumi Cloud infrastructure
• Infrastructure: Pulumi Cloud backend runs on AWS us-east-1 and us-west-2

The CLOUD Act problem statement: Pulumi Cloud is Pulumi Corporation's managed state backend service. It stores stack state files for every deployment, tracks resource history, manages team access, and provides audit logs. All of this data is held by a US Delaware corporation with infrastructure in AWS US regions. Under CLOUD Act §2713, Pulumi Corporation must comply with valid US government orders for that data — including state files containing your EU production infrastructure configurations and secret outputs.

Pulumi CLOUD Act Risk Score: 17/25

We use a 25-point rubric across five dimensions to measure CLOUD Act exposure. Pulumi scores 17/25 — high risk.

Score: 17/25 — CLOUD Act High Risk. Compared to Terraform/HCP Terraform (HashiCorp/IBM, 20/25), Pulumi's slightly smaller US footprint and Index Ventures' UK involvement push the score marginally lower. The absence of any EU state-backend option keeps the risk firmly in the high category.

Five GDPR Compliance Problems with Pulumi Cloud

Problem 1: State Backend Jurisdiction — Your Infrastructure Blueprint is in the US

Pulumi Cloud stores every stack's state file in US-governed infrastructure. A Pulumi state file is not a simple key-value store. It contains:

• All deployed resource IDs, ARNs, and connection strings
• Output values exported from your stacks (often database hostnames, API endpoints, internal IP addresses)
• Resource dependency graphs
• Historical deployment logs with before/after resource states

For an EU production environment, this state file is a detailed map of your entire infrastructure. CLOUD Act §2713 compels Pulumi Corporation to produce this map to US law enforcement on demand. GDPR Article 44 prohibits transfers of personal data to third countries without adequate protection. If your state outputs include anything derivable from personal data — user-count outputs, customer-segment resource tags, PII-adjacent configuration — you have an unlawful transfer risk.

The EU region illusion: Pulumi Cloud supports multiple cloud provider regions for your actual deployed resources. Your AWS RDS instance can be in eu-central-1. But the state file describing that RDS instance — its connection parameters, security group IDs, and subnet assignments — is held by Pulumi Corporation in the US.

Problem 2: Pulumi AI Copilot — Your Infrastructure Code Goes to US AI Services

Pulumi AI Copilot is integrated directly into the Pulumi Cloud console. When you use it to generate or debug IaC code, your infrastructure context — existing resource configurations, stack outputs, error messages — is sent to OpenAI's US-based API infrastructure.

This creates a dual CLOUD Act exposure: Pulumi Corporation (state data) plus OpenAI Inc. (code and infrastructure context). Under GDPR Article 28, Pulumi is acting as a data processor for your infrastructure data; forwarding that data to a sub-processor (OpenAI) without adequate contractual protections and without your explicit instruction creates a compliance violation.

The business risk compounds the legal risk: your infrastructure patterns, naming conventions, and resource configurations are training signals for US AI systems. Competitive infrastructure design is exposed beyond just legal compellability.

Problem 3: ESC (Environments, Secrets, Configuration) — Secrets in US Jurisdiction

Pulumi ESC is Pulumi's managed secrets and configuration service. It lets teams centralize environment variables, dynamic secrets, and configuration hierarchies. ESC integrates with AWS Secrets Manager, HashiCorp Vault, and similar backends — but the ESC metadata, access policies, and secret references are stored in Pulumi Cloud US infrastructure.

If you use ESC to inject secrets into Pulumi deployments, those secrets pass through Pulumi Cloud's US-governed orchestration layer even if the final secret values come from EU-hosted Vault. The access audit trail for every secret retrieval is logged in Pulumi Cloud US backends.

GDPR Article 32 requires appropriate technical measures for personal data security. Routing secret-retrieval audit trails through US-jurisdiction infrastructure creates a gap between your security controls (EU Vault) and your accountability records (US Pulumi Cloud).

Problem 4: Pulumi Insights — Cloud Asset Discovery Data in the US

Pulumi Insights is a cloud asset management and search service. It scans your connected cloud accounts, discovers resources across AWS, Azure, and GCP, and stores the inventory in Pulumi Cloud. This inventory can include:

• Resource names that contain environment or customer identifiers
• Network topology data (VPC configurations, subnet structures, security group rules)
• Tag data that may contain PII-adjacent information

This cloud asset metadata — aggregated from your entire EU infrastructure — is stored in US-governed Pulumi Cloud infrastructure. For GDPR-regulated workloads, any resource-level data that can be linked to natural persons (even indirectly through customer-specific resource naming) requires lawful transfer mechanisms under GDPR Chapter V.

Problem 5: Deployment Audit Logs — Who Did What, When, on Which Resource

Pulumi Cloud maintains a full audit trail: every stack update, every pulumi up, every pulumi destroy, every team member's deployment action. These logs include:

• User identity (email, GitHub identity)
• Timestamp and duration of deployment operations
• Resources created, modified, and destroyed with before/after states
• IP addresses and user-agent strings of CLI clients

GDPR Article 5(1)(f) integrity and confidentiality requirements, combined with Article 32 security measures, create a compliance obligation around audit log jurisdiction. When your deployment audit logs are in Pulumi Cloud US infrastructure, subject to CLOUD Act disclosure, you lose meaningful control over who can access evidence of your engineers' actions on EU production systems.

EU-Native Alternatives to Pulumi

Option 1: Pulumi CE + Self-Hosted State Backend (Best Migration Path)

The most direct EU-sovereign alternative preserves your Pulumi investment entirely. Pulumi's open-source CLI supports alternative state backends beyond Pulumi Cloud:

Self-hosted backend options:

• S3-compatible object storage on EU infrastructure: MinIO on Hetzner, Exoscale Object Storage, OVH Object Storage, Scaleway Object Storage. Pulumi supports pulumi login s3://your-bucket-name with any S3-compatible backend.
• Local filesystem or NFS mount: For smaller teams, pulumi login file://path with an EU-hosted NAS or EFS mount eliminates cloud backend dependency entirely.
• Azure Blob Storage (EU region): If you're already in Azure with an EU data boundary commitment, Azure Blob Storage in West Europe is a valid Pulumi state backend.

CLOUD Act score with self-hosted backend: 0/25. You use the open-source Pulumi CLI (Apache-2.0 licensed), connect to your own EU-hosted S3 backend, and Pulumi Corporation never holds your state. You lose Pulumi Cloud features (team management UI, audit log console, ESC, AI Copilot) but retain full CLI functionality, all language SDKs, all providers, and all component resources.

Migration effort: Low to medium. pulumi stack export → change backend → pulumi stack import. Existing stacks migrate without re-provisioning any infrastructure.

Option 2: OpenTofu (HCL-Compatible, 0/25 CLOUD Act)

OpenTofu is the Linux Foundation fork of Terraform, maintained under OpenTofu Foundation governance with Apache-2.0 licensing. If your Pulumi investment is not yet large, OpenTofu offers:

• Full HCL compatibility with Terraform (most modules and providers work)
• Self-hosted state backend options: S3, GCS, Azure Blob, local filesystem, or Terraform Enterprise-compatible backends
• Active development with features diverging from HashiCorp's BSL-licensed Terraform
• EU community governance (Linux Foundation, no US corporate control)

CLOUD Act exposure: 0/25 when self-hosted on EU infrastructure.

Limitation vs Pulumi: OpenTofu uses HCL, not general-purpose languages. If your team's productivity advantage comes from Pulumi's TypeScript/Python SDK, the migration cost is higher.

Recommended backend for OpenTofu on EU infrastructure:

terraform {
  backend "s3" {
    bucket   = "your-opentofu-state"
    key      = "production/terraform.tfstate"
    region   = "eu-central-1"
    endpoint = "https://s3.hetzner.com"  # or Exoscale/Scaleway/OVH
  }
}

Option 3: Crossplane (Kubernetes-Native IaC, 0/25)

Crossplane is a CNCF (Cloud Native Computing Foundation) incubating project that extends Kubernetes with Custom Resource Definitions (CRDs) to manage cloud infrastructure. Instead of Pulumi stacks or Terraform state files, Crossplane stores your infrastructure state as Kubernetes objects in your own cluster.

Architecture:

• Deploy Crossplane in your EU Kubernetes cluster (Hetzner k3s, Scaleway Kapsule, OVH Managed Kubernetes)
• Install provider-aws, provider-azure, or provider-gcp
• Define infrastructure as Kubernetes manifests (YAML)
• Crossplane reconciliation loop maintains desired state

CLOUD Act exposure: 0/25 — state lives in your EU-hosted Kubernetes etcd. No US entity holds your infrastructure state.

When to choose Crossplane over OpenTofu/Pulumi:

• Your team already manages Kubernetes clusters
• You want GitOps-first IaC (ArgoCD + Crossplane is a powerful combination)
• You need fine-grained Kubernetes RBAC for infrastructure changes
• You want to build internal developer platforms (IDPs) with self-service infrastructure

Limitation: Higher operational overhead — you're running a Kubernetes cluster as your IaC platform. Not suitable for teams without Kubernetes expertise.

Option 4: Spacelift (EU-Headquartered IaC CI/CD)

Spacelift (spacelift.io) is a Warsaw-based IaC workflow automation platform. It wraps Terraform, OpenTofu, Pulumi, and Ansible with a policy-as-code layer, approval workflows, and audit trails — all hosted in EU infrastructure under Polish law.

CLOUD Act exposure: Low (Polish company, EU hosting, GDPR-native). Not zero — Spacelift still holds your infrastructure metadata — but as an EU legal entity, it is not subject to US CLOUD Act compellability.

When to choose Spacelift: You want managed IaC CI/CD with approval workflows, policy enforcement (Rego), and a team management UI without a US-jurisdiction backend.

Migration Timeline: Pulumi Cloud → EU-Sovereign Backend

For teams currently using Pulumi Cloud, a 4-week migration to a self-hosted EU backend is achievable:

Total infrastructure cost for self-hosted backend: Scaleway Object Storage: €0.01/GB/month. For 10 stacks with typical state files: < €1/month. MinIO on Hetzner CX11 (€3.29/month): gives you a complete S3-compatible endpoint with full control.

What you lose from Pulumi Cloud:

• Team management and RBAC UI (replaceable with your own access controls on the state bucket)
• AI Copilot (replace with EU-hosted Mistral Codestral or self-hosted Continue)
• ESC managed secrets (replace with HashiCorp Vault CE on Hetzner or AWS SSM Parameter Store in eu-central-1)
• Deployment audit log UI (replaceable with structured logging from your CI/CD pipeline)

What you keep: All Pulumi CLI functionality, all language SDKs (TypeScript, Python, Go, C#), all cloud providers, all component resources, all existing stack code. Zero IaC migration required.

Decision Matrix: Choosing Your EU IaC Stack

The Structural Point: IaC State Files Are Infrastructure Intelligence

Infrastructure-as-Code state is qualitatively different from most other data processed by DevOps tools. It is, by design, a complete and authoritative description of your cloud infrastructure. When that state is held by a US company subject to CLOUD Act §2713:

• US law enforcement can obtain a blueprint of your entire EU production environment
• Resource configurations, security group rules, network topology, and output values are all compellable
• The people and organizations whose data lives on that infrastructure are indirectly affected

This is the argument that moves CISO and legal review from "probably fine" to "requires mitigation." The Pulumi CLI is excellent software. The Pulumi language SDKs are among the most productive IaC tools available. The problem is entirely in where state is stored — and that problem has a clean technical solution.

Migrate to a self-hosted EU state backend, keep your Pulumi SDK investment, and reduce your CLOUD Act exposure from 17/25 to 0/25. The migration takes one week and costs less than a cup of coffee per month.

Deploy Your IaC Stack on EU-Sovereign Infrastructure

sota.io runs on European infrastructure, under European law. Deploy your Pulumi stacks — or your OpenTofu, Crossplane, or Spacelift workflows — on a platform that is structurally outside US CLOUD Act jurisdiction.

Start your free trial on sota.io — EU-hosted, GDPR-native, no US parent company.

See Also

• Ansible EU Alternative 2026: Red Hat/IBM, CLOUD Act 20/25 — IBM's $34B acquisition of Red Hat makes Ansible Automation Platform subject to US CLOUD Act §2713; execution logs and inventory data compellable by US law enforcement.
• Puppet EU Alternative 2026: Perforce Acquisition, CLOUD Act 16/25 — Puppet's 2022 acquisition by Perforce (Clearlake Capital PE) brings the same US jurisdiction risk to configuration management; CFEngine and Rudder as EU-native replacements.
• Chef EU Alternative 2026: Progress Software, CLOUD Act 18/25 — Chef Automate telemetry and Habitat Builder data flow to Progress Software's US infrastructure; the Cinc Project fork and Rudder offer EU-sovereign paths forward.