# Ferrocene: a qualified Rust toolchain you cannot download without an account

> Ferrocene is a downstream of rustc qualified for ISO 26262 ASIL D, IEC 61508 SIL 4 and IEC 62304, and the repository is Apache-2.0 or MIT. The catch for evaluation is that binaries come from releases.ferrocene.dev behind a login and the rendered documentation for all release channels is customer-only, so the public repository is source plus procedure, not a usable toolchain.

**ferrocene/ferrocene** — Source code of Ferrocene, safety-critical Rust toolchain

- Repository: https://github.com/ferrocene/ferrocene
- Website: https://ferrocene.dev
- Stars: 1,690 · Forks: 51
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-11-03 · Language: en
- Canonical page: https://hysenlabs.com/projects/ferrocene-ferrocene

## What qualified actually means here

Ferrocene is described as a toolchain to enable the use of Rust in safety-critical environments, and as a proper downstream of the main Rust compiler, rustc, maintained by the Rust project on `rust-lang/rust`.

The status section lists three qualifications: ISO 26262 at ASIL D, IEC 61508 at SIL 4, and IEC 62304. Qualification for other areas, including railway and aerospace, is described as planned.

The wording matters. This is a statement about the toolchain, not about a product built with it. Safety-critical qualification attaches to a development tool and its verification evidence, so what Ferrocene provides is the ability to say which compiler and standard library produced the binary, with documentation behind that claim. It does not make the software you write with it safe, and it does not remove the process obligations on your side.

The mission statement gives the other motivation: bringing open source practices to safety-critical industries and improving the Rust ecosystem through safety-critical practices.

Maintenance and support come from Ferrous Systems, with both standard and long-term support available, which is a commercial arrangement rather than a community one.

## Why the binaries are behind a login

The installation section is two sentences and it is the gating fact for anyone evaluating this project.

Prebuilt binaries are available for customers and partners. You visit releases.ferrocene.dev to download the release archives after logging in with your Ferrocene account. There is no public download, and no `curl | sh` line in this README, which is unusual for a Rust toolchain but consistent with a commercial product.

Documentation is split the same way. The rendered documentation at docs.ferrocene.dev is available to customers and partners and contains the documentation for all release channels. The site at public-docs.ferrocene.dev/main is publicly available and contains documentation for the latest commit merged on the `main` branch. So the public docs track moving `main`, not a version you could pin, and the pinned documentation is behind the login.

The in-repository documentation is the third layer. The README points at the `ferrocene/doc` directory, stating that it contains the project's procedures, its quality management measures and current testing coverage. That is what a safety auditor would want, and it is public.

Support follows the same line. Multiple levels of support are available for paying customers, and customers.ferrocene.dev is where you learn about your plan and how to send support requests. The issue tracker is explicitly not a support channel, which the README states directly.

## A downstream, which decides what changes are possible

The contribution policy explains the project's engineering posture better than any feature list could.

As a downstream of the Rust project, Ferrocene prefers to keep the compiler unmodified. General contributions to the compiler or its tools, and discussions about them, should happen upstream on `rust-lang/rust`. Ferrocene does serve as a community of peers to propose and produce changes useful in safety-critical contexts towards the project.

That is a real constraint on what you can expect. You are not going to get a downstream-only patch to the compiler that upstream has not accepted, because a fork that diverges is a fork you would have to requalify. The tool you get is upstream rustc plus whatever safety-relevant changes have been accepted.

The repository root shows how much of rust-lang/rust is here. `compiler/rustc` is a workspace member, and so are a long list of upstream tools: `src/tools/clippy`, `src/tools/compiletest`, `src/tools/miri` and `cargo-miri`, `src/tools/rustfmt`, `src/tools/rustdoc`, `src/tools/tidy`, `src/tools/run-make-support`, `src/tools/rust-installer`, `src/tools/jsondocck` and others. There is also `compiler/`, `library/`, `src/`, `tests/`, `configure`, `src/bootstrap` excluded from the workspace, and Ferrocene's own additions in `ferrocene/`.

The `Cargo.toml` also shows that the exclusion list is not purely upstream. Alongside `build`, `compiler/rustc_codegen_cranelift`, `compiler/rustc_codegen_gcc`, `src/bootstrap` and `tests/rustdoc-gui` there is an exclusion annotated as a Ferrocene addition pointing at a specific pull request, for `src/tools/rustc-perf/site`.

The build configuration is the familiar rust-lang one: `bootstrap.example.toml`, `rust-bors.toml`, `bors.toml`, `Cargo.lock` and `rustfmt.toml`.

## Licensing is double-licensed with a REUSE layer on top

The license section has three parts and the third is the interesting one.

First, the contents of the repository are primarily licensed under either the MIT or Apache 2.0 license, users can choose either, and contributors must license their changes under both. The README file itself carries an SPDX header reading `MIT OR Apache-2.0` and an SPDX copyright line for The Ferrocene Developers. Both license texts are at the root as `LICENSE-MIT` and `LICENSE-APACHE`.

Second, and this is the part that catches people, the repository contains files authored by third parties and published under different licenses, and the README says to see the annotations next to those files. The root has a `LICENSES/` directory, a `REUSE.toml` file and a `license-metadata.json`, which is the machinery for tracking that per-file licensing. There is also a `src/tools/collect-license-metadata` workspace member, so the license inventory is generated by a tool rather than maintained by hand.

Third, the name is not open. Ferrocene is a registered trademark of Critical Section GmbH, a subsidiary of Ferrous Systems, and the guidelines for its use are in `TRADEMARK.md`, which the README links.

A `COPYRIGHT` file, a `.mailmap` and `typos.toml` complete the governance files, alongside `CODEOWNERS`, `AGENTS.md` and `CLAUDE.md`. The presence of those last two is worth a note for contributors: the repository carries instructions aimed at coding agents, alongside `x`, `x.py`, `x.ps1` and a `.circleci/` directory for its own development workflow.

## Where Ferrocene is the wrong choice

There are three clear mismatches, and one of them is a budget question rather than a technical one.

If your product does not need a qualified toolchain, Ferrocene is strictly worse than upstream Rust for evaluation purposes. You cannot download the binaries without an account, the pinned documentation is behind the same login, and the versions you read about publicly track `main` rather than a release. For learning Rust or shipping a server, there is nothing here that upstream does not do better and cheaper.

If your standard is railway or aerospace, the README says qualification for those areas is planned. Planned is not qualified, and that is the boundary to check before designing an architecture around this toolchain.

If you need a target that does not exist yet, that is a project. The additional services section lists tailoring and integration, including porting the Rust compiler to the targets you need and qualifying them in Ferrocene, alongside inclusion of Ferrocene in your own SDK, trainings for teams, and infrastructure support described as Ferrocene being built for a DevOps world with Rust for cloud builds as a first-class citizen.

The alternative worth weighing is upstream Rust plus your own qualification evidence. The difference in approach is who carries the verification burden: Ferrocene carries the toolchain qualification, while the alternative leaves you assembling the argument for an auditor.

## Conclusion

Adopt Ferrocene if your product has to satisfy a functional safety standard and an assessment auditor will ask which compiler produced the binaries, because the answer must be a qualified toolchain and Ferrocene is one under ISO 26262 ASIL D, IEC 61508 SIL 4 and IEC 62304. Do not adopt it to try Rust for the first time, since prebuilt binaries are available to customers and partners only through releases.ferrocene.dev after logging in with a Ferrocene account, and support is a paid arrangement through customers.ferrocene.dev. Verify three things before committing: which targets are actually qualified for your standard, since the README names automotive and industrial standards and says qualification for railway and aerospace is planned rather than done; what your specific release channel's documentation contains, since docs.ferrocene.dev covers all release channels for customers while public-docs.ferrocene.dev/main only reflects the latest commit on `main`; and whether you need a target that does not yet exist, because porting the Rust compiler to additional targets and qualifying them is listed as a service rather than a shipped feature. The repository contents are primarily licensed under MIT or Apache-2.0, and the Ferrocene name is a registered trademark of Critical Section GmbH with rules in TRADEMARK.md.

## FAQ

### How do I download Ferrocene?

Prebuilt binaries are available to customers and partners at releases.ferrocene.dev after logging in with your Ferrocene account. There is no public download, and public documentation at public-docs.ferrocene.dev/main covers only the latest commit on the main branch.

### Which safety standards is Ferrocene qualified for?

ISO 26262 at ASIL D, IEC 61508 at SIL 4, and IEC 62304. Qualification for other areas such as railway and aerospace is described as planned rather than complete.

### What license applies to the Ferrocene source code?

The repository contents are primarily under either MIT or Apache-2.0, and contributors must license changes under both. It also contains third-party files under other licences, tracked with a LICENSES directory, REUSE.toml and license-metadata.json.

### Why does Ferrocene prefer to keep the compiler unmodified?

As a downstream of the Rust project it prefers to keep the compiler unmodified, so general contributions to the compiler or its tools should happen upstream on rust-lang/rust. Ferrocene proposes and produces changes upstream as a community of peers instead of forking.

### Can I get support for Ferrocene through GitHub issues?

No. The README states the issue tracker is not a support channel. Multiple levels of support are available for paying customers through customers.ferrocene.dev, provided by Ferrous Systems.

### Who maintains Ferrocene?

It is maintained and supported by Ferrous Systems, with both standard and long-term support available. The Ferrocene name is a registered trademark of Critical Section GmbH, a Ferrous Systems subsidiary, with usage guidelines in TRADEMARK.md.

## Sources

- [ferrocene/ferrocene on GitHub](https://github.com/ferrocene/ferrocene)
- [Issues](https://github.com/ferrocene/ferrocene/issues)
- [License: Apache-2.0](https://github.com/ferrocene/ferrocene/blob/main/LICENSE)
- [Project website](https://ferrocene.dev)
- [README](https://github.com/ferrocene/ferrocene/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ferrocene-ferrocene