Avoiding Vendor Lock-in with a Compatible, Migration-Friendly, Transparent Container Distro

By 2027, more than 90% of global organizations will be running containerized applications in production, up from just 40% in 2021, according to Gartner. And with open source components making up 70-90% of an average enterprise codebase, a vast majority of today’s innovation is powered by open source operating systems.

For developers, platform engineers, infra teams, and DevOps leaders, that means adopting the right Linux distribution to underpin their containerized workloads isn’t a decision to take lightly. The distro you adopt determines not only how efficient and effective your applications are today but also how adaptable your stack will be to tomorrow’s innovations.

If you’re curious about the rationale and background around Chainguard’s decision to bootstrap its own distro, check out our blog series on the genesis of Chainguard OS.

Evaluating Linux distros is complex. Having partnered with over 250 customers, one common evaluation question Chainguard hears from customers is around “vendor lock-in,” where switching to an alternative or interoperating outside of a given platform becomes prohibitively expensive, technologically challenging, or risky.

To help in evaluating distros in the context of lock-in, it’s useful to ask four core questions:

1. Does the distro interoperate nicely with my toolsets and processes, and the broader ecosystem as a whole?

2. Are the build processes of the distro transparent and accessible?

3. Is the distro easy to migrate to?

4. If I need to, how challenging is it to move off of this distro?

If you can answer these four, you’re already positioned to make smarter, more future-proof decisions. Let’s break each down.

Compatibility: How Does It Fit With the Ecosystem?

Compatibility and interoperability are critical in containerized environments. The distro you choose should seamlessly integrate with your existing toolchain, including CI/CD pipelines, vulnerability scanners, artifact repositories, and private registries, without forcing you into fragmented workflows or unnecessary duplication.

At a minimum, this means adhering to widely adopted standards and protocols. Examples include:

• OCI-compliant containers that ensure portability.

• SBOMs built on CycloneDX or SPDX for transparent supply chain metadata.

• Multi-architecture support, including both x86 and ARM.

It also means adopting underlying architectures that, while not explicit standards, are widely adopted toolsets. In the case of containerized workloads, this could be standard libraries like glibc, FHS compliance, and widely used package managers like apk.

In practice, a broadly compatible distro reduces friction across development and operations, reduces additional tool sprawl and context-switching, and makes it easier to enforce security policies and meet compliance obligations.

Build Transparency: Are the Build Processes of the Distro Transparent and Accessible?

Alongside compatibility and interoperability is simple transparency and accessibility. Does the distro make publicly available the tooling and processes required to build with it? This becomes a critical element of “popping the hood” on a given distro to understand its reproducibility, while also providing a clear understanding of what tooling is required on the distro side to deliver on the end state outcome of your own use case.

If the build process is obfuscated, or the tooling is inaccessible or doesn’t have accessible documentation, it should raise questions around whether the distro is leveraging proprietary processes that could lock you in.

Migration: How Easy Is It to Adopt?

Migrating workloads to a new distro can range from straightforward to daunting. The deciding factor often comes down to how standardized and complete the distro’s ecosystem is.

Key considerations include:

• Package availability: A deep and well-maintained repository increases the odds that the software you already depend on is supported out of the box.

• Enterprise support: For commercial distros, SLAs, professional expertise, and vendor backing can be invaluable when handling edge cases.

• Documentation and tooling: Migration guides, automation scripts, and robust docs help smooth the transition.

And don’t overlook post-migration quality of life. Ask yourself:

• How quickly does the distro patch CVEs?

• Does it reduce the attack surface with smaller base images?

• Are modern cryptographic libraries included by default?

• Does the vendor publish signed SBOMs, provenance data, and signatures?

A distro that excels here not only simplifies migration but also makes the change worthwhile by enhancing security, performance, and maintainability.

Migration Off: How Hard Is It to Leave?

When making the decision to migrate to something new, it’s tough to imagine a future where you’re migrating off already. But technology priorities shift, operational requirements change, and sometimes organizational direction takes an unexpected turn. When that happens, you don’t want to be trapped by a vendor’s ecosystem or at the whim of the vendor’s licensing power.

Evaluating exit costs means looking for the same traits that made your initial migration possible: standards-based components and architecture, broad package availability, and minimal proprietary lock-in. Ideally, the distro you choose should avoid introducing unique dependencies that tie you to a single vendor or ecosystem. Critical to avoiding lock-in is ensuring that you retain perpetual access to the OS you’re migrating away from, whether through your original commercial agreement or open source.

How Chainguard OS Stacks Up

Chainguard OS is a minimal, hardened Linux-based operating system designed for secure, containerized software delivery. Built in-house by Chainguard, it serves as the foundation for Chainguard’s container products and emphasizes continuous integration, immutable artifacts, and alignment with upstream software. The Wolfi Project is the open source counterpart to Chainguard OS, powering Chainguard’s free starter container images. In just a few years, both have gained traction with enterprises and open source adopters alike, combining modern security and performance practices with the interoperability teams demand.

Compatibility

Chainguard OS leverages glibc implementation and apk, two widely adopted building blocks that enable broad enterprise compatibility. It runs across both x86 and ARM, and now offers a complete kernel for container hosts, applications, and VM base images, making it possible to standardize on Chainguard OS for use cases outside of containerization. As an example of Chainguard’s compatibility, our FIPS-validated container images are kernel-independent, meaning they can maintain compliance while running on any underlying host OS.

All Chainguard container images are OCI compliant, with SPDX, CycloneDX, and Sigstore/Cosign integrations to simplify SBOM generation and cryptographic signing. This ensures Chainguard OS fits neatly into existing CI/CD and DevSecOps workflows, while being compatible with a wide array of scanners and artifact repositories.

Build Transparency and Open Source Tooling

Chainguard OS has open, accessible tooling to enable anyone to recreate a Chainguard build. Melange and apko are two of the core tools Chainguard uses to ensure image builds are fully transparent and reproducible. Melange is a package build system that lets you define how software is built from source into APK packages in a simple, declarative YAML format, and apko is a tool for assembling those APK packages into minimal, OCI-compliant container images.

Together, they make it possible for anyone to take the same build definitions Chainguard uses, run them locally or in their own CI/CD systems, and reliably reproduce a container image based on Chainguard OS or Wolfi.

While you may not be interested in rebuilding your complete base image from scratch, the openness and availability of the tooling guarantees verifiability, supply chain transparency, and trust while making clear that users aren’t held hostage by proprietary tooling.

Migration

Unlike traditional distros, Chainguard OS emphasizes minimal, distroless, purpose-built container images. It distinguishes between -dev variants (with shells and package managers) and production variants (stripped down only to the essentials), reducing attack surface without compromising functionality. This helps streamline the adoption of our images. Additionally, we’ve built open source tooling like Dockerfile Converter, which helps developers automate the migration to Chainguard Containers.

With a repository of 15,000+ packages (and growing based on customer needs), Chainguard OS eliminates many migration headaches through complete coverage of developers’ dependencies. Teams are far more likely to find the packages and versions they need without rewriting their applications or replacing dependencies – all of which simplifies adoption.

Chainguard OS and Wolfi also benefit from a fast-growing open source community, along with enterprise-grade documentation, tooling, and professional support. Customers such as Snowflake, BitDefender, Confluent, Shift5, and Snap have found success with Chainguard, citing not only compatibility but also the improved security posture and performance of Chainguard container images.

Migration Off

Moving off Chainguard OS would most likely involve changing Dockerfiles and possibly Helm Chart configurations to use alternative images and packages. Thanks to architectural foundations like glibc and Chainguard’s broad package repository built from source, organizations can feel confident the packages they need will be available in upstream distros.

We all know how frustrating it can be when companies try to switch licenses on you after you've invested in driving adoption. Rest assured that whatever direction you decide to head in, you'll always have a perpetual license to use the Chainguard OS you paid for so any container images pulled and/or mirrored can continue to be used.

In summary, Chainguard OS is rooted in open source, leverages open source and freely accessible build tooling, and embraces broadly adopted standards, empowering organizations to build applications on a secure-by-design foundation without the risk of vendor lock-in. The same compatibility, package breadth, and standards-based approach that ease migration to Chainguard also reduce the friction of migration away.

If you’d like to dive deeper, check out our “Chainguard your OS” paper to learn more about the approach behind Chainguard OS, or reach out to our team to explore how Chainguard Containers can fit into your environment.