Modernizing OpenROAD Deployment

Simpler installation and the transition to Bazel

We are modernizing OpenROAD deployment to make it easier for students, individual designers, and engineering teams to get started and maintain a reliable toolchain. Community feedback has shaped this work, with particular attention to restricted systems, large scale deployment support and the effort required to keep installations consistent.

Bazel is now the supported build system. CMake is deprecated and scheduled for removal on November 1, 2026. Existing users should plan their migration using the OpenROAD installation guide.

Why deployment is changing

Discussions spanning numerous academic and commercial environments highlighted recurring obstacles:

• In education, diverse student laptops, container updates, and virtualization overhead can make setup difficult and distract from design work.
• On air-gapped or restricted systems, container policies and unavailable network downloads complicate dependency management.
• In enterprise environments, inconsistent prerequisites and internal wrappers make reliable upgrades harder for central IT teams.

The deployment change aims to reduce these obstacles while giving users options that fit their environment. Predictable distribution and a simpler build interface are central to that goal.

Flexible deployment options

Use the supported operating systems matrix and the linked guides to choose how to install. We recommend picking the first option in the following list that meets your system requirements:

• Prebuilt packages: Available binaries and installation guidance.
• Containers: OpenROAD Docker installation; for the complete OpenROAD flow, see the ORFS Docker Shell guide.
• Packaged archives: Archive creation and installed runtime files.
• Source builds: Build and install with Bazel.

Migration for existing users

If your scripts or internal pipelines still call CMake directly, update them to the supported build path or an appropriate prebuilt distribution. The goal is to minimize disruption to developers and CI maintainers as the build infrastructure changes.

For wrapper behavior, installation prefixes, and supported option mappings, use Using etc/Build.sh. Check the documented handling of legacy options when reviewing existing automation.

For production build configuration, use the current link time optimization guidance. Developers can find test and profiling workflows in Testing local changes with Bazel.

Planning for your environment

Students and individual users can follow the installation route supported by their platform. Windows users should consult the WSL guide; macOS users should review the platform prerequisites.

Teams working on air-gapped systems should evaluate the packaged deployment route against their target environment and security requirements. Use the linked archive guidance above together with the prerequisite requirements when planning that evaluation.

Enterprise maintainers can incorporate their chosen packages or container images into internal distribution workflows to reduce dependence on ad hoc user setups and external artifact availability.

More predictable releases

Automated release publishing is a further deployment goal. The planned work includes native RPM and DEB packages and extractable tarball archives for official releases, making upgrades easier without requiring every user to compile from source. Stay tuned for this feature release shortly!

Together, these changes are intended to reduce onboarding friction and maintenance overhead. Choose a deployment route that fits your workflow, and use the linked documentation for the current installation and configuration details.