Philosophy & Approach

An upstream-first OpenBMC distribution focused on stability, long-term maintenance, testing, and developer enablement.

Our Core Philosophy

Canopy is an upstream-first OpenBMC distribution built on four core pillars:

  • Stability - Enterprise-grade reliability through comprehensive testing and validation
  • Long-Term Maintenance - LTS branches every two years, each maintained for five with security patches and critical fixes
  • Testing - Hardware CI testing on real boards for every commit
  • Developer Enablement - Modern tooling and streamlined workflows to accelerate development

By staying closely aligned with OpenBMC upstream while adding robust testing and long-term support, Canopy delivers the best of both worlds for production deployments.

Upstream-First Approach

Weekly Upstream Tracking

  • Weekly rebases against OpenBMC upstream
  • Automated CI/CD testing on every rebase
  • Latest features from the OpenBMC community
  • Active participation in upstream development

Production Stability

  • Six-month release cycles with extensive testing
  • Hardware CI testing on real boards
  • Long-term support (LTS) with security patches
  • Predictable maintenance lifecycles

The Four Pillars

Stability

Enterprise-grade reliability through comprehensive testing, validation, and six-month release cycles that provide predictable deployment schedules.

Long-Term Maintenance

LTS branches every two years, each maintained for five years with security patches, critical bug fixes, and defined maintenance lifecycles for production environments.

Testing

Hardware CI testing on real boards for every commit, ensuring rock-solid reliability and catching issues before they reach production.

Developer Enablement

Modern tooling, prebuilt binaries, streamlined configuration, and comprehensive documentation that make development productive and enjoyable.

Developer Enablement

Part of our core philosophy is developer enablement. We love developers, and we are developers as well! We want to provide more value for developers by easing out the development process.

How do we do that?

Extra Development Tools

We provide additional tools and utilities that make OpenBMC development easier and more productive, complementing the standard upstream toolchain.

Streamlined Configuration

We streamline the OpenBMC configuration process to make customization easier, reducing complexity and setup time for new projects.

Prebuilt Binaries

We provide prebuilt binaries for supported boards to lower the barrier to entry and reduce the time needed to get started with development.

Automation

We provide a fully automated CI/CD pipeline as part of our weekly rebase against upstream. Let's use 21st century development tools to make our life easier.

Release Channels

The same curated tree is delivered through three channels, so each part of your organization can pick the balance of freshness and stability it needs:

Bleeding Edge

main

Newest of everything, integrated continuously.

Fresh
Stable
  • Tracks upstream main with weekly rebases, plus in-flight and vendor patches
  • Freshest features, least hardening
For: active development, early board bring-up and feature preview.

Rolling Release

every 6 months

A stabilised snapshot on a fixed cadence.

Fresh
Stable
  • Tagged source with release notes and a hardware test report
  • Bug and security fixes between releases
For: the standard production cadence.

LTS Release

every 2 years

A release promoted to long-term support.

Fresh
Stable
  • Security and critical fixes only, backported for 5 years
  • No feature churn — API and behaviour held stable
For: fleets that need stability and compliance over new features.

Long-Term Support and Migration

A new LTS branch is cut every two years and maintained for five. Migration between branches is part of the support model rather than an afterthought, so a product stays supported as long as it needs to be:

LTS 2026.12 5 years of fixes
migrate on your schedule
LTS 2028.12 5 years of fixes
migrate on your schedule
LTS 2030.12 5 years of fixes

Five years per branch

Every LTS branch carries security patches and critical fixes for 5 years, and a new branch appears every two years — so there is always a maintained branch ahead of the one you are on.

We carry the migration

When you do move, we rebase the platform onto the new LTS. Vendor patches are carried forward, and anything already upstreamed arrives with the new base for free — so the delta you carry shrinks every cycle.

Proven by regression

The hardware regression suite runs on the new branch before you switch, proving functional parity on your boards rather than asserting it.

Never a support cliff

Because LTS branches overlap, there is always a maintained branch to move onto. Production never runs on an unmaintained tree.

Enterprise Use Cases

This philosophy specifically addresses the needs of enterprise environments that require:

  • Predictable Release Cycles - Plan deployments around our six-month stable release schedule
  • Validation and Testing - Comprehensive testing ensures compatibility and reliability
  • Security Assurance - Regular security audits and timely patch delivery
  • Support Commitments - Long-term support with defined service level agreements
  • Documentation - Thorough documentation for deployment, configuration, and troubleshooting
  • Migration Paths - Clear upgrade paths between releases with migration guides

Upstream-First Commitment

Our upstream-first philosophy ensures Canopy remains closely aligned with the OpenBMC community:

  • Weekly rebases ensure we never drift from upstream
  • Contributions flow back to OpenBMC from our testing and validation work
  • Bug fixes and improvements are shared with the broader community
  • Active participation in OpenBMC development and technical discussions
  • Community-driven development while maintaining production stability