Platform Components

The Contain Platform is a modular ecosystem built from a collection of managed Components. Understanding what a component is and how we manage its lifecycle is key to understanding the reliability, security, and flexibility of the platform.

A Component is our managed, self-contained software package that provides a specific capability. We take best-in-class open-source projects (like Prometheus, Velero, or Keycloak), and then we harden and integrate them into a seamless and secure package that is optimized to run on our platform.

This approach gives you the best of both worlds: the innovation and transparency of open source, combined with the assurance and operational excellence of a managed service.

What's in a Component?

A component is a complete package that includes everything needed to run, operate, and maintain a piece of software within your cluster.

• Container Images: One or more container images, scanned for vulnerabilities and stored in our secure registry.
• Declarative Configuration: Kubernetes manifests (like Deployments and Services) that define how the software runs, managed via GitOps.
• Integrated Observability: Pre-configured metrics, logging configurations, and alerting rules that plug directly into the Observability Plane.
• Security Policies: Hardened security contexts, network policies, and RBAC roles that ensure the component runs securely by default.
• Versioned Documentation: Clear documentation that is tied to a specific version of the component, ensuring what you read always matches what's running.

The Component Lifecycle: From Upstream to Your Cluster

We manage the entire lifecycle of a component to ensure it is secure, stable, and reliable. This process can be understood in three key phases.

Vetting & Curation

Before any software is considered for the platform, it undergoes a rigorous due diligence process. We analyze the upstream project's:

• Supply Chain Security: We investigate the project's origin, check for signed commits and images, and assess its overall security posture according to frameworks like SLSA.
• License Compliance: We verify that the project's license and all of its dependencies are compliant with our legal standards.
• Community Health: We assess the activity and governance of the upstream community to ensure the project is actively maintained and viable for the long term.
• Operational Readiness: We review its configuration, resource footprint, and compatibility to ensure it can be operated efficiently and securely on our platform.

Integration & Packaging

Once an upstream project is vetted, we package it as a Component. This involves:

• Runtime Hardening: We apply strict security contexts, create default-deny network policies, and configure the software to run with the least privilege required.
• Image Hardening: We use minimal and hardened base images to reduce the attack surface.
• Integrating Observability: We ensure the component exposes the right metrics and logs to seamlessly integrate with our central monitoring and alerting systems.
• Creating a Secure Package: The final component is packaged as a signed, verifiable artifact with cryptographic attestations that prove its origin and integrity.

Controlled Rollouts

We provide updates in a controlled, progressive manner to mitigate risk. This is managed through a system of Promotion Paths and Resilience Zones.

To learn more about how we ensure safe and predictable updates, see the Component Rollouts documentation.

Customizing Components

An Inside Look

The following section describes the internal mechanisms we use to manage and customize components. While this provides a transparent look into how our platform works, these are not features you will typically interact with directly. Customization is part of our managed service.

While our components come with sensible, secure defaults, we understand that one size does not fit all. We provide two levels of customization to adapt a component to your specific needs.

Variants

A Variant is a pre-defined, encapsulated configuration that adapts a component for a specific, broad use case. For example:

• The external-dns component has variants for different cloud DNS providers like AWS Route 53 or Azure DNS.
• A database component might have a development variant that runs as a single node and a production variant that runs in a high-availability topology.

Configuration Overrides (Bindings)

While variants handle major configuration shifts, we often need to provide environment-specific details. Configuration Overrides allow us to inject fine-grained values when a component is enabled on a specific cluster.

This is perfect for details that can't be known ahead of time, such as:

• Database credentials or API keys from a secret store.
• Hostnames that are specific to your environment.
• Resource limits (CPU/memory) tailored to a cluster's workload.

This system follows a clear precedence model, ensuring that configuration is always predictable and easy to manage.