Chef EU Alternative 2026: Progress Software Acquisition, CLOUD Act 18/25, and EU-Native Config Management

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

Chef began in 2008 as Opscode, Inc. in Seattle, Washington. Founded by Jesse Robbins and Adam Jacob, it pioneered the idea of treating infrastructure as code using Ruby-based DSLs — knife, cookbooks, and recipes became the vocabulary of a generation of DevOps engineers. The company rebranded to Chef Software in 2013 and built a commercial ecosystem around Chef Infra (formerly Chef Client), Chef InSpec (compliance automation), Chef Automate (observability), and Chef Habitat (application packaging). In October 2020, Progress Software Corporation acquired Chef Software for approximately $220 million.

That acquisition is the central fact for any European organization evaluating Chef today.

Progress Software Corporation: The New Owner

Progress Software Corporation (NASDAQ: PRGS) is headquartered in Waltham, Massachusetts, and incorporated in Delaware — the jurisdiction with the most developed US corporate law and the default choice for companies subject to US court orders and federal requests. Progress is a multi-product software company with annual revenues around $600 million and roughly 3,000 employees worldwide. Its portfolio includes Telerik (UI components), OpenEdge (application development platform), DataDirect (data connectivity), Sitefinity (CMS), and — since the Chef acquisition — the entire Chef infrastructure automation suite.

Progress Software is a publicly traded company on NASDAQ. Its largest shareholders are US institutional investors: Vanguard Group, BlackRock, and various US mutual fund managers collectively hold the majority of shares. There is no independent European entity with meaningful governance over Chef's development roadmap, data handling practices, or response to US government requests.

Why NASDAQ Listing Matters for CLOUD Act Exposure

A company traded on a US exchange and incorporated in Delaware is unambiguously subject to US jurisdiction under the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713). The CLOUD Act requires US-based providers to disclose stored communications and data to US federal authorities upon valid legal process — regardless of where that data is physically stored. For Progress Software, this means:

• Chef Automate telemetry stored on EU-region infrastructure is still subject to US warrants
• Node metadata, compliance scan results, and cookbook deployment logs transmitted to Progress systems can be compelled
• There is no EU-based subsidiary with independent legal authority to challenge such requests

CLOUD Act Exposure Score: 18/25

We evaluate Chef using the same five-dimension framework applied throughout this series:

Chef scores 18/25 — solidly in the high-risk range for European enterprises subject to GDPR. The score is lower than Ansible's 20/25 primarily because Chef's enterprise deployment model is predominantly self-hosted, reducing the data surface area compared to Red Hat's cloud-connected services. However, several telemetry and licensing mechanisms create unavoidable data flows to US infrastructure.

Five GDPR Risks in Chef's Architecture

Risk 1: Chef Supermarket Telemetry (GDPR Art. 44 — Third Country Transfer)

Chef Supermarket (supermarket.chef.io) is the central cookbook repository — the npm registry equivalent for Chef. When Chef Infra Client cookbooks are downloaded, uploaded, or searched via the Supermarket API, the following data flows to Progress US infrastructure:

• Cookbook names, version numbers, and download counts
• API authentication tokens
• Source IP addresses of download requests
• Knife CLI command metadata

The Supermarket is hosted on US CDN infrastructure operated by Progress. For European organizations, each cookbook download constitutes a data transfer to the US under GDPR Article 44. Since Progress Software is not subject to the EU-US Data Privacy Framework as a certified organization, there is no adequacy decision or standard contractual clause (SCC) in place for routine Supermarket interactions.

Mitigation: Self-host a private Supermarket instance within the EU (github.com/chef/supermarket is open source) or use Cinc's community Supermarket.

Risk 2: Chef Automate License Verification Pings (GDPR Art. 28 — Data Processor)

Chef Automate (the observability and compliance dashboard for enterprise Chef deployments) performs periodic license verification callbacks to Progress US servers. These callbacks transmit:

• Unique installation identifier
• Node count (number of managed systems)
• Environment names (often descriptive of infrastructure topology)
• Cookbook names deployed across the environment
• Chef Automate version and feature usage data

Even for self-hosted Automate deployments, these license pings create a data flow to Progress US systems. Under GDPR Article 28, Progress Software would need to act as a compliant data processor — but standard Chef Automate license agreements are US-law-governed contracts, not EU GDPR data processing agreements with the required provisions for data subject rights, breach notification, and sub-processor disclosure.

Risk 3: Chef Infra Client Run Telemetry (GDPR Art. 25 — Privacy by Design)

Chef Infra Client includes telemetry via Chef::EventDispatch that is enabled by default in older enterprise versions. This telemetry reports:

• Convergence statistics (resources managed, resources changed)
• Error types and frequencies
• Run durations and node characteristics
• Resource type usage patterns

The data flows to Progress analytics infrastructure in the US. GDPR Article 25 (Data Protection by Design and by Default) requires that data minimization be built into systems from the ground up — not added as an opt-out. Chef Infra's default-on telemetry inverts this requirement. While telemetry can be disabled via chef_guid and data_collector configuration, enterprise deployments often inherit these defaults silently.

Mitigation: Set data_collector['server_url'] = nil and enable_telemetry false in /etc/chef/client.rb.

Risk 4: Chef InSpec Telemetry (GDPR Art. 13 — Transparency)

Chef InSpec is Chef's compliance automation framework — it runs control profiles against infrastructure and produces compliance reports used for GDPR audits, ISO 27001 assessments, and FedRAMP certifications. The irony: InSpec itself may generate GDPR compliance violations through its own telemetry.

InSpec telemetry transmits:

• Control IDs executed during compliance scans
• Pass/fail counts per control
• Target system metadata (OS type, platform version)
• InSpec profile names and sources

These telemetry events are sent to Progress infrastructure by default. Under GDPR Article 13, data subjects must be informed of any data collection affecting them. System metadata transmitted during compliance scans may include attributes of systems processing personal data — creating a secondary compliance obligation that organizations rarely document in their GDPR records of processing activities (RoPAs).

Risk 5: Chef Habitat Builder (GDPR Art. 5 — Data Minimisation)

Chef Habitat (acquired alongside Chef Software) is an application packaging and runtime system. Habitat Builder (bldr.habitat.sh) is its central repository for packages. When using the public Habitat Builder, the following is transmitted to Progress US cloud:

• Package metadata (name, version, origin, channel)
• Service topology descriptions
• Supervisor network peering information
• Build pipeline artifacts and build logs (for cloud builds)

GDPR Article 5 requires that personal data be "adequate, relevant and limited to what is necessary." Package metadata and build artifacts from production applications may include environment names, internal service identifiers, and system configuration details that exceed what is necessary for package hosting. Progress's ability to access these artifacts via their US-hosted Builder service creates ongoing CLOUD Act exposure for European organizations using Habitat for production deployments.

Mitigation: Self-host Habitat Builder using the open-source repository (github.com/habitat-sh/builder).

Corporate Structure Diagram

Progress Software Corporation
├── Incorporated: Delaware, USA
├── HQ: Waltham, Massachusetts, USA
├── Exchange: NASDAQ (PRGS)
├── Revenue: ~$600M/year
├── Shareholders: Vanguard ~10%, BlackRock ~8%, US institutional majority
│
├── Chef Infra (configuration management)
│   └── Telemetry → Progress US analytics ⚠️
├── Chef InSpec (compliance automation)
│   └── Control telemetry → Progress US ⚠️
├── Chef Automate (observability dashboard)
│   └── License pings + usage data → Progress US ⚠️
├── Chef Habitat (application packaging)
│   └── Builder metadata → Progress US cloud ⚠️
└── Chef Supermarket (cookbook repository)
    └── Download telemetry → US CDN ⚠️

All five product lines create data flows to US-controlled infrastructure, and all five are subject to US CLOUD Act compulsion.

EU-Native Alternatives to Chef

Option 1: Cinc Project — The Direct Drop-In Replacement

Cinc (pronounced "sink") is a community-maintained, open-source distribution of Chef software — built from the same Apache 2.0 licensed source code as Chef Infra, Chef InSpec, and Chef Workstation, but with all Progress Software telemetry, license enforcement, and commercial callbacks removed. It is maintained by the Cinc Project community under the Open Source Initiative model.

CLOUD Act Score: 0/25 — Cinc is not a company. It has no US corporate parent, no license verification servers, no telemetry endpoints, and no investors. When self-hosted on EU infrastructure, it has zero CLOUD Act exposure.

Drop-In Compatibility:

• cinc-client is a drop-in replacement for chef-client (same Ruby DSL, same cookbook format)
• cinc-auditor replaces chef-inspec (same InSpec control profiles)
• cinc-workstation replaces chef-workstation (same knife commands)
• Existing cookbooks from Chef Supermarket work with Cinc without modification
• CINC community Supermarket available at supermarket.cinc.sh

EU Hosting:

# Install Cinc Client on a Debian/Ubuntu EU node (Hetzner, OVH, etc.)
curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -P cinc

# Verify - no Progress license check, no telemetry ping
cinc-client --version
# Output: Cinc Client 18.x.x

# Self-hosted Cinc Supermarket
# Deploy on EU server: https://github.com/cinc-project/supermarket

Cost Comparison:

Option 2: Rudder — Compliance-First Config Management (France)

Rudder is developed by Normation SAS, a French company based in Paris. Rudder takes a different approach from Chef: instead of Ruby DSLs and cookbooks, it uses a web-based policy editor with a graphical compliance dashboard.

CLOUD Act Score: 0/25 — Normation SAS is incorporated in France, subject to EU law, with no US corporate parent, no US investors, and EU-only infrastructure.

Key Differentiators from Chef:

• Web UI for policy management (no CLI-first learning curve)
• Built-in GDPR compliance scoring and audit trails
• Real-time compliance inventory across all managed nodes
• Native integration with French and EU regulatory frameworks
• Packaging: DEB/RPM agents, works on most Linux distributions

Installation (EU-hosted Rudder server):

# On Rudder server (Debian 12, e.g. OVH Strasbourg)
echo "deb http://repository.rudder.io/apt/8.0 bullseye main" > /etc/apt/sources.list.d/rudder.list
apt-get update && apt-get install rudder-server

# On managed nodes
echo "deb http://your-rudder-server/rudder-apt bullseye main" > /etc/apt/sources.list.d/rudder.list
apt-get install rudder-agent

Pricing: Rudder is open source (GPLv3) for the community edition. Commercial support from Normation starts at approximately €12/node/year for enterprise support — significantly less than Chef Enterprise.

Option 3: CFEngine AS — Maximum Scale, Norwegian Pedigree

CFEngine AS is headquartered in Oslo, Norway and is the creation of Mark Burgess, the computer scientist who invented the theoretical foundations of modern configuration management (Promise Theory, 1993). CFEngine predates Chef by 15 years.

CLOUD Act Score: 0/25 — Norwegian AS (Aksjeselskap), no US parent, no US investors, EU jurisdiction.

Technical Characteristics:

• C-based agent: ~2MB binary, runs on systems with 64MB RAM
• Promise-based DSL (not Ruby) — steeper learning curve but highly expressive
• Scales to 100,000+ nodes on a single policy server
• Sub-minute convergence cycles (vs Chef's 30-minute default)
• Built-in classes for automatic platform detection

Migration from Chef to CFEngine:

# Chef cookbook concept in CFEngine policy language
bundle agent configure_nginx
{
  packages:
    "nginx"
      package_policy => "add",
      package_method => apt;

  files:
    "/etc/nginx/nginx.conf"
      content => "$(nginx_template)",
      perms => mog("644", "root", "root");

  services:
    "nginx"
      service_policy => "start";
}

Pricing: CFEngine Community Edition is free (GPLv3). CFEngine Enterprise starts at approximately €8/node/year — positioning between Cinc (free) and Chef Enterprise (€30-50/node/year).

Migration Paths from Chef

Path 1: Chef → Cinc (Minimal Effort, Maximum Compatibility)

This is the fastest migration for organizations that want to eliminate CLOUD Act exposure without rewriting their infrastructure-as-code:

1. Audit existing cookbooks — run cinc-client in --why-run mode against existing cookbooks
2. Replace Chef Infra Client — substitute cinc-client on all managed nodes (package swap, no DSL changes)
3. Replace Chef InSpec — substitute cinc-auditor (same control profiles, same inspec.yml)
4. Self-host Supermarket — deploy supermarket.cinc.sh mirror or self-hosted instance in EU
5. Remove Progress telemetry — verify data_collector and telemetry configs are disabled
6. Replace Chef Automate — use Cinc's open-source reporting or alternative dashboards

Timeline: 2-4 weeks for most environments. Cookbooks require zero modification in most cases.

Path 2: Chef → Rudder (Compliance-Driven Environments)

Best for organizations where compliance reporting drives the choice of tool:

1. Export Chef node lists and map to Rudder groups
2. Convert Chef resources to Rudder techniques (most common resources map directly)
3. Import compliance controls — InSpec profiles can be adapted to Rudder's compliance framework
4. Validate in staging before production cutover

Timeline: 6-12 weeks. Requires rewriting policy in Rudder's format, but gains native web UI and GDPR audit trail.

Path 3: Chef → CFEngine (Scale-Critical Environments)

Best for large-scale deployments (500+ nodes) where performance and scale are primary concerns:

1. Learn CFEngine's Promise Theory model — significant paradigm shift from Chef's imperative-influenced DSL
2. Port cookbook resources to CFEngine bundles and bodies
3. Set up policy server — CFEngine's cf-serverd replaces Chef Server
4. Migrate node definitions — CFEngine's classes map to Chef's node attributes

Timeline: 12-20 weeks for complex environments. More learning investment, but highest long-term scalability.

IaC Series Summary: CLOUD Act Scores Through Post #4

All four tools share the same fundamental problem: Delaware incorporation and US corporate control. The CLOUD Act exposure is structural, not configurable. Even complete EU hosting of the infrastructure cannot eliminate the legal compellability of Progress Software to disclose data it holds, or to provide access to systems it controls.

The EU-native alternatives (Cinc, Rudder, CFEngine) eliminate this structural risk entirely. For European organizations operating under GDPR, NIS2, or sector-specific regulations (financial services under DORA, healthcare under MDR), this distinction may determine whether configuration management infrastructure itself becomes a compliance liability.

Practical Recommendations

For teams currently using Chef Automate Enterprise: → Evaluate Cinc as a drop-in replacement. The €0 software cost vs €30-50/node/year for Chef Enterprise typically pays for 12-18 months of EU infrastructure within the first year.

For teams where compliance reporting is primary: → Evaluate Rudder. Its web UI and built-in GDPR audit trails reduce the compliance-documentation burden that Chef's CLI-first model creates.

For large-scale deployments (1,000+ nodes): → Evaluate CFEngine. Its C-based agent and proven scalability make it the pragmatic choice when node count drives costs.

For teams needing a European vendor relationship: → Normation (Rudder) and CFEngine AS both offer commercial support contracts governed by EU law, with data processing agreements that satisfy GDPR Article 28 requirements without US transfer complexity.

The next post in the series examines Terraform and OpenTofu — HashiCorp's acquisition by IBM brings Terraform into the same CLOUD Act risk category as Ansible, while the OpenTofu fork (Linux Foundation) offers a community-maintained EU-hostable path forward.

sota.io helps European companies deploy applications on EU-sovereign infrastructure. No US corporate parent, no CLOUD Act exposure, GDPR-native from day one. Start for free →

See Also

• Pulumi EU Alternative 2026: Seattle-Based IaC, CLOUD Act 17/25 — Pulumi Cloud state files expose your entire EU infrastructure topology to CLOUD Act §2713 compulsion; self-hosted backend migration reduces exposure from 17/25 to 0/25.
• Ansible EU Alternative 2026: Red Hat/IBM, CLOUD Act 20/25 — The IBM acquisition pattern mirrors Chef's Progress Software acquisition; AAP cloud execution logs and Galaxy data carry the highest CLOUD Act score in the series at 20/25.
• Puppet EU Alternative 2026: Perforce Acquisition, CLOUD Act 16/25 — Puppet and Chef share the same US-PE-acquisition story; CFEngine (Norway) and Rudder (France) serve as EU-native alternatives for both configuration management platforms.