Posts tagged "infrastructure" | Rust Blog

Infrastructure Team 2026 Q3 Recap and Q4 Plan

2026-10-12T00:00:00+00:00

Here's what the Infrastructure Team delivered in Q3 2026 and what we're focusing on in Q4.

You can find the previous blog post of this series here.

Q3 2026 Accomplishments

Audit logs in Datadog Cloud SIEM

We enabled audit logs for the following services and sent them to Datadog, so that the Rust Foundation security team can analyze them using Cloud SIEM:

The Rust GitHub Enterprise and the Rust Foundation GitHub Enterprise, via audit log streaming.
AWS, via CloudTrail.
Heroku, Wiz, Fastly, and Datadog itself.

See the GitHub issue for more details.

Web Application Firewall and DDoS protection for crates.io and docs.rs

Together with the crates.io and docs.rs teams, we set up the Fastly Next-Gen WAF (Web Application Firewall) for docs.rs and crates.io (see the GitHub issue). The WAF blocks potential security threats and enforces rate limits.

We also enabled Fastly DDoS protection for both services.

Together, these helped us mitigate DDoS attacks against crates.io this quarter, and reduce the load on the docs.rs server.

CDN improvements for crates.io and docs.rs

We made several improvements to the Fastly configuration of crates.io and docs.rs:

Faster crate downloads processing: We removed a regex from the Fastly code that handles crate downloads, and did some other optimizations (#1095, #1096). Requests now take 10% less compute time in the Fastly CDN nodes. Most users won't notice the difference, since networking dominates download latency, but it makes our CDN setup more efficient and sustainable.
Content-Length in HEAD responses: Fastly HEAD responses now include the Content-Length header for non-compressible artifacts such as .crate files. This fixes some issues encountered when using Buck2.
crates.io static assets served from the edge: GET and HEAD requests for READMEs and other static assets of crates.io are now resolved by the CDN instead of the crates.io web app hosted on Heroku.
docs.rs CDN logs in Datadog: The docs.rs Fastly service now sends its logs to Datadog (#1196, #1197, #1226), giving us better observability of the service.
CloudFront traffic: In the past months, we sent 100% of crates and releases download traffic over Fastly to spend our AWS credits on other resources. We restored a small share of traffic (approximately 0.4%) over CloudFront to make sure it keeps working as intended, in case we need to fall back to it.

New message queue between crates.io and docs.rs

We provisioned an AWS SQS FIFO queue that crates.io can use to notify docs.rs about new releases.

The queue is meant to replace the crates.io git index for this use case. It's currently unused for lack of engineering time from the crates.io team.

Renovate for the `rust` repository

We configured Renovate for the rust-lang/rust repository (see the configuration file). Renovate automatically opens PRs to fix security findings and update Cargo lockfiles and GitHub Actions.

From the dependency dashboard, maintainers can ask Renovate to update individual dependencies when they want to. You can see all the PRs opened by Renovate here.

GitHub security alerts

We enabled Dependabot alerts in the rust-lang GitHub organization. This means that:

Maintainers receive alerts for vulnerabilities affecting their repositories.
Maintainers can see these vulnerabilities at https://github.com/rust-lang/<repo>/security/dependabot.
If configured, Renovate can open PRs to fix these vulnerabilities. See the Renovate docs to learn more.

Note that this setting doesn't enable automatic Dependabot PRs. That's a separate setting called "Dependabot security updates", which we don't plan to enable because we prefer using Renovate.

More settings configured in the `team` repo

We keep moving manually configured settings into Infrastructure as Code (IaC) in the team repository:

GitHub Pages: Rust Project members can now set up GitHub Pages for their repositories by opening a PR. See the docs and an example. Thanks to cuba0001 for working on this!
Custom Properties: GitHub Custom Properties are now configurable in the team repo. This allows repositories to opt in to automations developed by the Infrastructure Team.

Hardware security keys

As a follow-up to the hardware security keys work we did in Q2, we added a convention in the team repository for Project members who want to share the PIV attestation certificates extracted from their YubiKeys. We can validate these certificates against our inventory of hardware keys through their serial numbers.

More details in the docs.

GitHub Actions audits

We deployed the crabwatch workflow to audit GitHub Actions workflows in the rust-lang GitHub organization. We enabled 23 Zizmor audits by default, and we want to enable more in the future! In the meantime, project members can override what audits run in their repositories.

Thanks to Sandra, the Outreachy intern who helped us work on this! You can read about her internship experience in her blog.

Improving user experience of reviewers

Our merge queue bot (bors) is now able to gate approvals on pull request CI success in the rust-lang/rust repository. This makes it easier for reviewers to approve pull requests without having to babysit them until PR CI succeeds.

Trusted contributors

The Rust Project created a trusted-contributors marker team for trusted contributors who are not members of rust-lang teams but regularly contribute to rust-lang/rust. This team has try and perf permissions, so that these contributors can start try builds and performance runs independently, without repeatedly asking a Project member to delegate permissions.

Learn more about membership in the Forge docs.

More powerful dev desktops and Rust Playground

We upgraded the EC2 instances of the dev desktops and the Rust Playground to make these services faster for Rust contributors and the Rust community:

Playground: from c5a.large to c7a.xlarge (PR).
Dev desktops (PR):
- dev-desktop-eu-1: from c6g.8xlarge to c9g.8xlarge.
- dev-desktop-us-1: from c7g.12xlarge to c9g.12xlarge.

We also increased the disk quota to 200GB per user on all four dev desktops (#1182, #1187).

Learn more about dev desktops in the Forge docs.

ARM machine for rustc-perf

We provisioned an EC2 m9g.metal-48xl instance to run rustc-perf on ARM. This allows the compiler team to measure optimizations done for the ARM architecture.

New CI runners

In partnership with Canonical, we enabled new External GitHub Actions runners for the Rust Project:

s390x-unknown-linux-gnu: currently being evaluated in the compiler-builtins repository.
armv7-unknown-linux-gnueabihf: used in the compiler-builtins repository.

We also enabled three large ARM GitHub Actions runners (8 vCPU, 32 GB RAM) for the rustls organization, covering Ubuntu 24.04, Ubuntu 26.04, and Windows 11. This additional CI capacity is sponsored by ARM.

`riscv64gc-unknown-linux-musl` promoted to tier 2 with host tools

We promoted the riscv64gc-unknown-linux-musl target to tier 2 with host tools. RISC-V users targeting musl no longer need to compile Rust tools like rustc and cargo themselves.

On-call rotation moved to Datadog

Since the Rust Foundation joined Datadog's Open Source Program, we migrated the Rust Foundation on-call rotation from PagerDuty to Datadog On-Call. This allows us to save money and to remove one service from our dependencies.

Team leader rotation

We established a new policy for the Infrastructure Team leader.

As a result, we rotated one team leader: Marco took the place of JD.

Main branch

We renamed the default branch of 25 repositories to main: lang-team, rustc-hash, rustc-perf, rust-artwork, .github, compiler-team-prioritization, project-ffi-unwind, project-safe-transmute, wg-allocators, wg-cargo-std-aware, futures-rs, pin-utils, thanks, rust-forge, triagebot, mdBook, portable-simd, rustup-components-history, std-dev-guide, polonius, cargo-bisect-rustc, rust-mode, rust.vim, types-team, rfcs.

Among public repositories in the rust-lang organization that are neither archived nor forks, 113 use main and 56 still use master.

Trusted publishing

We converted 7 crates to use trusted publishing:

rustc-hash
jobserver
libc
ctest
docs_rs_crates_io
font-awesome-as-a-crate
cargo-bisect-rustc

Triagebot Assign-priority command

We improved and added a shortcut to the assign-priority command (e747558e), see docs on the forge.

Q4 2026 Plans

Finish Q3 goals

In Q3, we didn't manage to finish all our goals, so we will continue working on them in Q4:

Improve access controls for Rust infrastructure with SAML SSO.
Move mailing lists from Mailgun to Google Groups to reduce spam.
Consolidate logs on Datadog.
Stricter networking access rules for crater agents.

You can read more about these goals in our Q3 2026 plan.

Secure deployments

Today, we deploy infrastructure from our personal laptops. Instead, we want to deploy from a secure environment with strong access controls, where access is limited to the people who maintain the deployment processes. Deploying from a centralized environment also makes it easier to automate deployments and to monitor for unauthorized access or suspicious activity.

As a first step, we want to simplify our Infrastructure as Code setup, which currently uses both Terraform and Terragrunt. We want to investigate whether it is still worth using both tools (see the GitHub issue).

After simplifying the setup, we will decide how to automate deployments and start automating them.

Decommission the monitoring instance

As part of our move to Datadog, we want to decommission our self-hosted monitoring instance, which runs Prometheus, Alertmanager and Grafana.

Join us

If you're interested in contributing to Rust's infrastructure, have a look at the infra-team repository to learn more about us and reach out on Zulip.

We are always looking for new contributors!

Infrastructure Team 2026 Q2 Recap and Q3 Plan

2026-07-15T00:00:00+00:00

Here's what the Infrastructure Team delivered in Q2 2026 and what we're focusing on in Q3.

You can find the previous blog post of this series here.

Q2 2026 Accomplishments

GitHub Rulesets are now the default protections

We migrated the rust-lang/rust repository to GitHub Rulesets and finished moving off the legacy GitHub branch protections. Rulesets are now the default way to configure protections for rust-lang repositories through team.

GitHub apps are now enabled through team

We re-enabled the ability to install GitHub apps in rust-lang repositories through team. This improves the developer experience for contributors and reduces the operational overload for Infrastructure Team members.

Shared Renovate Presets

Renovate is the tool the Infrastructure Team recommends to the Project for keeping dependencies and GitHub Actions up to date.

We created shared Renovate presets to simplify the Renovate configurations of the rust-lang repositories. These presets aim to get the benefits of dependency updates while minimizing the number of PRs to review. We also documented how to adopt Renovate in repositories.

Code security for rust-lang repositories

As part of our security work, we enabled GitHub Secret Scanning for all rust-lang repositories. We triaged all alerts tagged as leaked secrets and confirmed that they were false positives.

In addition, in collaboration with the crates.io team, we started experimenting with Datadog Code Security to get additional visibility into security issues inferred directly from source files. We documented how to opt into this feature, and we want to try it with more repositories in the future. This work is a follow-up of the Rust Foundation partnership with Datadog.

New GitHub Actions runners powered by external hardware

We enabled new powerpc64 and RISC-V GitHub Actions runners for rust-lang repositories. We also documented which external runners are powered by external hardware and where they are used in rust-forge.

In addition, we created a new infrastructure guideline to help onboard external hardware into the Rust CI infrastructure.

Experiments with macos-26 on CI

We started experimenting with macos-26 in rust-lang/rust CI. We created an additional CI job and have been tracking how it performs. It's worth mentioning that GitHub will migrate all macos-latest images to macos-26 in June and July.

CI dashboard available again

In December 2024, we created a Datadog dashboard to track CI visibility for the rust-lang/rust repository. It proved very valuable, but we had to remove it because its cost was not sustainable.

Now that the Rust Foundation is part of Datadog's Open Source Program, we enabled it again.

In the past, the dashboard helped us track the top failing jobs, slowest jobs, and overall pipeline duration over time. We expect it to be just as useful going forward.

Hardware Security Keys for critical infrastructure access

We introduced official support for hardware keys as part of the Rust infrastructure security processes. We created a policy mandating multi-factor authentication with hardware keys for people and teams with access to systems considered critical, and in partnership with Yubico we empowered Rust Project members with YubiKeys.

We also documented how Project members can configure these devices for existing use cases. We want to expand this support further, enabling new ways to use the keys.

Partnership with Canonical and Ubuntu Pro for EC2 instances

As a follow-up to Canonical joining the Rust Foundation in March, we got access to Ubuntu Pro licenses and applied them to our EC2 instances, including the instance running docs.rs.

We improved our Infrastructure as Code setup to apply these changes, so that Ubuntu Pro will be enabled by default even in future instances.

Faster mergeability checks in Bors

We switched from GitHub's REST API to the GraphQL API and cut Bors pull request mergeability check times from an average of 30 minutes to just 1 minute.

Add the concept of community reviews before PR assignment

As part of multiple discussions that happened during the 2026 All-hands, the Clippy team asked the Triagebot team to be able to delay the assignment of a reviewer until one or multiple community reviews were done.

That work was carried out in triagebot#2426 (docs) and has just been enabled in the Clippy repository.

Reintroduce delegation approval for merge queue repositories

When we switched our repositories to GitHub merge queues instead of bors (our custom merging bot), we lost the ability to delegate approval on behalf of the reviewer.

That functionality is quite useful when there are only some nits left and the reviewer feels confident about the author's ability to resolve them without having to re-review and approve the changes.

Work was carried out in triagebot#2412 and triagebot#2436 to add such functionality back. It's currently only enabled in the Clippy repository:

@rustbot delegate[=@handle]
@rustbot merge

Continue supporting the moderation team with locking/unlocking of issues

As part of the effort to help the moderation team better moderate issues and pull requests in our different repositories and organizations, triagebot gained support for locking and unlocking an issue/PR from a GitHub command and Zulip DM.

Quality of life improvements in our range-diff viewer for GitHub PRs

We landed multiple quality of life improvements in our range-diff viewer for GitHub PRs.

Filtering of context-only hunks

As part of our range-diff, we try as much as possible to only show the relevant parts of a diff. Context changes (lines that changed on main only) are not relevant, and we made a significant effort to filter them out from the shown diff.

More details are available in triagebot#2398.

Commit messages diff

Our range-diff now shows the list of commits and diffs them with the previous ones.

New commits:

Warning against Unicode Bidi characters

Following what GitHub does when it detects Unicode Bidi characters in a PR diff, we now also warn since triagebot#2440.

Small tweaks to the triagebot

A new triagebot command to assign a priority value to regressions directly from Zulip, useful when doing triage. Example:

@**triagebot** assign-priority 123456 high

Minor tweaks (in b1e783a2 and 6611570e) to the triagebot backport and user-info commands, which now support shorter variants:

# Supported syntaxes for the `backport` command
@**triagebot** backport accept beta 123456
@**triagebot** backport accept beta
@**triagebot** backport accept

# Supported syntaxes for the `user-info` command
@**triagebot** user-info https://www.github.com/apiraino
@**triagebot** user-info apiraino

Q3 2026 Plans

Finish leftover work from Q2

In Q3, we will continue working on some of the things we could not finish in Q2:

Improve access controls for Rust infrastructure with SAML SSO.
Modernize the docs.rs infrastructure.

Improve GitHub Actions security

We've been actively working on GitHub Actions security through our Outreachy mentorship program. This effort started in April when we adopted zizmor as a Static Application Security Testing solution for GitHub Actions in some of our repositories.

As a follow-up of one of our Rust All-Hands sessions, we started working on a system to foster zizmor auditing and progressive adoption across the rust-lang organization.

Move mailing lists from Mailgun to Google Groups to reduce spam

As a follow-up to setting up the Google Workspace for the Rust Project, we want to evaluate whether Google Groups can reduce spam for existing mailing lists, which are currently managed through Mailgun. We want to keep the same developer experience by provisioning these new mailing lists through team. If the results are satisfactory, we will also migrate existing lists.

Consolidate logs on Datadog

As part of our efforts to improve observability, we want to consolidate all log management in Datadog. Next, we want to push logs from all services into it, including those from our bots (triagebot, bors, etc).

Reduce reliance on external resources in CI

We want rust-lang/rust CI to depend less on third-party services during builds and tests. When CI downloads required artifacts from external sources, an outage in those services can cause failures unrelated to Rust itself.

To make CI more reliable, we plan to mirror more of those artifacts in the Rust project's CI mirrors.

Stricter networking access rules for crater agents

As discussed during the Rust All-Hands, we want to improve the security of crater agents by isolating their network access.

Start planning for GitHub REST API upgrade

The current GitHub REST API version ("2022-11-28") will be deprecated in about 2 years (see the GitHub announcement). We pinpointed it in our GitHub client and plan to start testing the new version ("2026-03-10") and see what it breaks.

Join us

If you're interested in contributing to Rust's infrastructure, have a look at the infra-team repository to learn more about us and reach out on Zulip.

We are always looking for new contributors!

Infrastructure Team 2026 Q1 Recap and Q2 Plan

2026-04-14T00:00:00+00:00

Here's what the Infrastructure Team delivered in Q1 2026 and what we're focusing on in Q2.

You can find the previous blog post of this series here.

Q1 Accomplishments

Move to GitHub Rulesets

We started migrating from branch protection rules to GitHub Rulesets.

Rulesets are the new way in which GitHub suggests protecting branches and tags. They allow more configurability with respect to classic branch protections, and they are the only way in which you can setup new functionalities such as merge queues via API.

We converted all repositories, except for the rust repository. We are working on it!

As part of this effort, we also made all the branch protection and ruleset options we use configurable via the team repository, so that they can be managed as Infrastructure as Code (IaC).

Here are the newly available configuration options:

allowed-merge-apps
merge-queue
prevent-deletion
prevent-force-push
require-conversation-resolution
require-linear-history

For more details, see the GitHub issue.

Improved CI security

We always try to improve our security posture. Here are the most relevant examples for this quarter:

In the team repository, we enabled Renovate, a bot that automatically creates pull requests to keep GitHub Actions and Rust dependencies up to date. This makes it easier for us to keep our dependencies up to date and fix security issues in a timely manner.
In the compiler-builtins CI, we enabled Renovate and resolved the security issues reported by zizmor in preparation for running the RISC-V self-hosted runner in CI in a more secure way.
We released crates-io-auth-action v1.0.4, updating its dependencies and moving it from Node 20 to Node 24 after GitHub announced the deprecation of Node 20 on Actions runners.

Two new dev desktops

We provisioned two new dev desktops: dev-desktop-us-2.infra.rust-lang.org and dev-desktop-eu-2.infra.rust-lang.org.

We also enabled IPv6 access for dev desktops, making them easier to reach from more network environments. See the GitHub issue.

Learn more in the Forge docs.

Bigger docs.rs instance

We are experiencing an unprecedented increase in crates published on crates.io, which is putting a lot of pressure on the docs.rs infrastructure, which has to build the documentation for more crates than before.

To keep up with this growth, we upgraded the docs.rs instance to a more powerful one, doubling the available RAM and CPU cores.

Improved access controls for Rust infrastructure with SAML SSO

We introduced Google SSO as part of Rust infrastructure offerings. We enabled Google Workspace accounts for the infrastructure team and validated the SAML setup for some of the key infrastructure providers, like Datadog and Fastly.

Triagebot enhancements

Triagebot is our trusty bot incessantly processing workflows on GitHub and on our Zulip chat.

We implemented several notable changes in Q1 2026.

GitHub issue comments viewer

We've added to Triagebot a GitHub issues and PRs viewer. It's primarily designed for long issues and PRs where GitHub is unhelpful with its "Load More" button.

It can be accessed via the View all comments link at the top of long issues and PRs.

Example for triagebot#2251:

And while it started rather small in its ambitions, it evolved quite a bit over the last quarter with:

a self-contained "Export" button (implemented in #2274)
a table of contents for review threads (implemented in #2360)
expand/collapse thread buttons (implemented in #2355)
and other small improvements

Organization-wide default configuration

Triagebot has many features and configurations, and while it's not difficult to enable a feature in a repo (the cost of a PR), it doesn't scale to the size of the rust-lang organization and its >200 repositories.

In order to address the uneven availability of features across all the repositories, we've added support for organization-wide default configuration in the Triagebot codebase and started enabling some features org-wide.

Announcements of soon-to-be-enabled org-wide features are done in #t-infra/announcements>Triagebot Organization-Wide Defaults on Zulip.

`user-info` command

This new Zulip command first appeared as the comments command for viewing recent user comments, but was extended into a more general user-info command, which shows recent activity (PRs, repositories) and account creation date for the given GitHub user account.

This is part of our efforts to help reviewers and maintainers with sloppy AI-generated PRs.

Per-team rotation mode

Triagebot handles the automatic assignment of reviewers in multiple repositories. Until February, it was not possible to set per-team rotation mode.

This is now possible via the Zulip command work set-team-rotation-mode <team> off/on, implemented in #2273 by @Kobzol.

Per-repository review preferences

Continuing with the theme of reviewer assignments, it was previously only possible to set a review preference for rust-lang/rust, despite the multiple repositories handled by Triagebot.

@Kobzol fixed that in #2286. It is now possible to set per-repository review preferences.

Report banned users to moderator stream on Zulip

As part of supporting different team needs, we've implemented an automatic reporting system on Zulip for banned users in our GitHub organization (implemented in #2269).

The goal of this feature is to relieve moderators from taking screenshots and manually archiving offending comments and user actions by automatically retrieving that information and posting it in the moderators’ Zulip channel.

Clippy's Zulip lint nomination topic

Similar to the previous topic, we've also helped T-clippy set up an automatic FCP topic on Zulip when they want to nominate a lint for discussion.

As part of this work, we have also added the ability to add back a comment on GitHub with the link to the created Zulip topic.

New Zulip commands to handle backports and assign priority to issues

Project members can now use two new Zulip commands to apply labels on rust-lang/rust issues and pull requests:

backport [stable | beta ] [approve | decline ] <pr #>: to accept or decline for backport a patch fixing a regression
assign-prio <issue #> [ critical | high | medium | low | <empty>]: to assign a priority label to an issue (admittedly mostly used by the Compiler Team but it's available to everyone)

For more details, see the documentation.

Q2 Plans

Finish Q1 goals

In Q1, we didn't manage to finish all our goals, so we will continue working on them in Q2:

docs.rs infrastructure modernization: Although we made some improvements to docs.rs in Q1, such as using GitHub OIDC for publishing container images to AWS ECR, we still want to move from the single EC2 instance to a modern, managed deployment.
External hardware CI policy: Publish requirements for running Rust CI on external hardware.
Move to GitHub Rulesets: Migrate the rust repository to GitHub Rulesets.
SAML SSO:
- Enable provisioning Google Workspace accounts from the team repository.
- Onboard all users that require infrastructure access and add the SAML setup for other service providers, like AWS.

Improve CI security and developer experience

We want to keep making the CI of the Rust Project both safer and easier to work with.

We have many ideas and we're not sure which ones we will prioritize yet, but here are some examples:

Make it easier for Rust Project members to adopt tools like Renovate to keep their dependencies up to date and secure.
Check CVEs of our dependencies.
Add more static analysis tools such as zizmor to secure more CI workflows.
Improve our CI observability by creating dashboards around metrics such as CI jobs duration and failure rate. Since the Rust Foundation joined Datadog’s Open Source Program, we plan to use Datadog for this task.
Improve visibility of the test coverage of the CI jobs.

Hardware security keys for critical infrastructure access

We want to secure access to critical Rust infrastructure even further by using hardware security keys. The Rust Foundation partnered with Yubico, and we want to provide YubiKeys to the Rust teams with access to critical infrastructure.

Our plan is to distribute hardware keys in May, during the Rust All Hands. See the related GitHub issue.

Join us!

If you're interested in contributing to Rust's infrastructure, have a look at the infra-team repository to learn more about us and reach out on Zulip.

We are always looking for new contributors!

Infrastructure Team 2025 Q4 Recap and Q1 2026 Plan

2026-01-13T00:00:00+00:00

As we close out the fourth quarter of 2025 and step into 2026, here’s what the Infrastructure Team delivered and what we’re focusing on next.

You can find the previous blog post of this series here.

Q4 2025 Accomplishments

More settings configured in the `team` repo

The Infrastructure Team always tries to move manually configured settings into Infrastructure as Code (IaC). IaC has various benefits:

It helps teams self-serve, since they can inspect their configuration even without admin privileges and request changes via pull requests.
It improves security by making configuration drift harder. Manual changes are still possible, but they will be detected more easily and reverted on the next run of the IaC automation.

GitHub environments

All GitHub environments for Rust Project repositories are now defined in the team repo.

Here's an example from the bors repository file:

[environments.production]
branches = ["main"]

[environments.staging]
branches = ["main"]

Thanks to amustaque97 for his great work on the GitHub environments issue!

Trusted publishing

All crates owned by the Rust Project that use crates.io trusted publishing now configure it as IaC via the team repo.

Here's an example from the measureme repository file:

[[crates-io]]
crates = ["analyzeme", "decodeme", "measureme"]
publish-workflow = "publish.yml"
publish-environment = "publish"

The work to configure trusted publishing for all the Rust Project crates will be easier now.

Crates.io index and docs.rs served via Fastly

The crates.io index and the docs.rs website are now served by the Fastly CDN.

We made this change because Fastly donates its CDN to us, and we want to use our AWS credits for other resources.

For docs.rs, we also enabled Fastly shielding, which adds an additional caching layer to reduce the load on our origin server. Here's the effect of enabling shielding on the number of active connections after a brief experiment on December 2 and enabling it permanently on December 3:

Note that the crates.io index is still partially served by CloudFront, and we can configure how much traffic goes to each CDN.

Thanks to the crates.io and docs.rs teams for helping with this!

The new Bors is used to merge Rust compiler pull requests

The Infra and Bors teams continued working on migrating the Rust CI from the legacy Bors (Homu) to the new Bors, written in Rust.

We have now enabled the new bot to merge rust-lang/rust PRs, completing the migration off Homu and improving the reliability of our continuous integration infrastructure 🎉.

We would like to thank all contributors who contributed to the development of bors, in particular Võ Hoàng Long and Sakibul Islam.

rustc-perf benchmarks are now executed in parallel

We made progress with the Project Goal for parallel benchmarking of the Rust compiler. We now have two x64 machines that run benchmarks in parallel, which reduced the latency of getting a full compiler benchmark result from ~1h 20m to ~40m.

In 2026, we plan to make further improvements to the benchmarking suite, such as enabling benchmarking on other hardware architectures.

Repository default branch renames

The following repositories have renamed their default branch from master to main:

annotate-snippets-rs
ar_archive_writer
cmake-rs
compiler-builtins
docs.rs
infra-team
moderation-team
rust
rustfmt
rustup
rustwide
stdarch
team
this-week-in-rust

Hired a new teammate

The Rust Foundation hired a new Infrastructure Engineer in Q4. They’ll start in January 2026, increasing the team’s capacity to better serve the Project.

Thanks to Kobzol for helping with the hiring process!

Triagebot enhancements

Triagebot is our trusty bot incessantly processing workflows on GitHub and on our Zulip chat.

We implemented several notable changes in Q4 2025.

Triagebot label command now supports aliases

We now have a mechanism for creating aliases when applying batches of labels to an issue (or a pull request) on GitHub. If you find yourself repeatedly applying or removing the same set of labels, you can now create an alias.

Example:

@rustbot label +regression-untriaged +I-prioritize +needs-repro

could become an alias:

@rustbot label regression-needs-triaging

Thanks to @apiraino for implementing the feature in #2216 (documentation).

Turn automatic backport nominations into suggestions

We now offer project teams a streamlined workflow for backports to the stable/beta release channels. Patches fixing regressions can be manually "nominated" for backport by anyone interested in having said patch tested earlier. Backport nominations are discussed during the weekly triage team meetings (and then approved or declined).

Now teams can configure the triagebot to:

Automatically nominate patches fixing P-high/P-critical regressions occurred in the beta/stable release channels.
Automatically open topics in our Zulip chat to evaluate backports asynchronously (see the compiler and rustdoc channels). During the triage meeting, the topic is quickly skimmed and a decision can be taken faster.

Thanks to @apiraino for implementing the feature in #2191 (documentation).

New Triagebot commands: `r? me` and `@rustbot reroll`

Two new triagebot features have been added to improve reviewer assignment.

First, @Urgau implemented support for using r? me as a shorthand for self-assignment in #2218. This provides a convenient alternative to manually typing r? @username when assigning a pull request to yourself.

Second, @Kobzol added the new @rustbot reroll command in #2219. This new command re-runs the automatic reviewer assignment logic normally triggered when a PR is first opened, using the latest diff and owner map.

`[no-mentions]` handler removed from Triagebot

We have removed the [no-mentions] handler from triagebot, as it is no longer needed. This handler was originally used to ask users to avoid @-mentions in commit messages to avoid triggering user notifications.

Thanks to GitHub’s recent change, which disables notifications for mentions in commits, this workaround is no longer necessary. We appreciate GitHub for making this improvement and simplifying the workflow for everyone involved.

Highlighting of log lines in Triagebot’s GHA log viewer

Triagebot’s GitHub Actions log viewer now supports highlighting selected log lines, similar to GitHub’s own code highlighting feature.

This improvement was implemented by @Urgau in #2234. It allows users to select one or more lines in build logs and share them easily using highlighted URLs, making it simpler to point others directly to relevant sections of long logs.

Here’s an example of the new functionality in action:

Triagebot `[mentions]` now supports glob patterns

The [mentions] configuration in triagebot now supports glob pattern matching.

This improvement was implemented by @Urgau in #2244. With this change, it’s now possible to group related paths under a single rule.

For example, it is now possible to write:

[mentions."library/{dec2flt,flt2dec}"]
cc = ["@ghost"]

instead of maintaining two separate entries for each directory.

Internal Sites team takes its first action

The new t-internal-sites team, responsible for maintaining and supporting the Rust project’s internal websites such as the Forge and the RFCs site, has taken its first action.

The team began by addressing stale non-RFC pull requests which had been stale due to the lack of ownership before t-internal-sites introduction.

Q1 2026 Plans

Finish Q4 2025 goals

In Q4 2025, we didn't manage to finish all our goals, so we will continue working on them in Q1 2026:

docs.rs infrastructure modernization: Although we made various improvements to docs.rs in Q4 2025, such as improving the CDN setup, we still want to move from the single EC2 instance to a modern, managed deployment.
External hardware CI policy: publish requirements for running Rust CI on external hardware.
GCP Dev Desktops: spin up one or two dev desktops in GCP.

You can read more about these goals in our Q4 2025 plan.

Account and Access Management

Finish the work started in rust-lang/infra-team#64 by setting up a Google Workspace for the Rust Project for automated account and access management using SAML.

Move to GitHub Rulesets

To have more flexibility and configurability, we want to migrate from branch protection rules to GitHub Rulesets across all Rust Project repositories.

The branch protection rules are already defined as code in the team repo, so we will need to update the IaC automation to create rulesets instead of branch protection rules.

This would also allow us to configure merge queues as IaC, which is currently not possible (see rust-lang/team#1735).

Join us!

If you're interested in contributing to Rust's infrastructure, have a look at the infra-team repository to learn more about us and reach out on Zulip.

We are always looking for new contributors!

Interview with Jan David Nose

2025-11-25T00:00:00+00:00

On the Content Team, we had our first whirlwind outing at RustConf 2025 in Seattle, Washington, USA. There we had a chance to speak with folks about interesting things happening in the Project and the wider community.

Jan David Nose, Infrastructure Team

In this interview, Xander Cesari sits down with Jan David Nose, then one of the full-time engineers on the Infrastructure Team, which maintains and develops the infrastructure upon which Rust is developed and deployed -- including CI/CD tooling and crates.io.

We released this video on an accelerated timeline, some weeks ago, in light of the recent software supply chain attacks, but the interview was conducted prior to the news of compromised packages in other languages and ecosystems.

Check out the interview here or click below.

Transcript

Xander Cesari: Hey, this is Xander Cesari with the Rust Project Content Team, recording on the last hour of the last day of RustConf 2025 here in Seattle. So it's been a long and amazing two days. And I'm sitting down here with a team member from the Rust Project Infra Team, the unsung heroes of the Rust language. Want to introduce yourself and kind of how you got involved?

Jan David Nose: Yeah, sure. I'm JD. Jan David is the full name, but especially in international contexts, I just go with JD. I've been working for the Rust Foundation for the past three years as a full-time employee and I essentially hit the jackpot to work full-time on open source and I've been in the Infra Team of the Rust Project for the whole time. For the past two years I've led the team together with Jake. So the Infra Team is kind of a thing that lets Rust happen and there's a lot of different pieces.

Xander Cesari: Could you give me an overview of the responsibility of the Infra Team?

Jan David Nose: Sure. I think on a high level, we think about this in terms of, we serve two different groups of people. On one side, we have users of the language, and on the other side, we really try to provide good tooling for the maintainers of the language.

Jan David Nose: Starting with the maintainer side, this is really everything about how Rust is built. From the moment someone makes a contribution or opens a PR, we maintain the continuous integration that makes sure that the PR actually works. There's a lot of bots and tooling helping out behind the scenes to kind of maintain a good status quo, a sane state. Lots of small things like triage tools on GitHub to set labels and ping people and these kinds of things. And that's kind of managed by the Infra Team at large.

Jan David Nose: And then on the user side, we have a lot of, or the two most important things are making sure users can actually download Rust. We don't develop crates.io, but we support the infrastructure to actually ship crates to users. All the downloads go through content delivery networks that we provide. The same for Rust releases. So if I don't do my job well, which has happened, there might be a global outage of crates.io and no one can download stuff. But those are kind of the two different buckets of services that we run and operate.

Xander Cesari: Gotcha. So on the maintainer side, the Rust organization on GitHub is a large organization with a lot of activity, a lot of code. There's obviously a lot of large code bases being developed on GitHub, but there are not that many languages the size of Rust being developed on GitHub. Are there unique challenges to developing a language and the tooling that's required versus developing other software projects?

Jan David Nose: I can think of a few things that have less to do with the language specifically, but with some of the architecture decisions that were made very early on in the life cycle of Rust. So one of the things that actually caused a lot of headache for mostly GitHub, and then when they complained to us, for us as well, is that for a long, long time, the index for crates.io was a Git repo on GitHub. As Rust started to grow, the activity on the repo became so big that it actually caused some issues, I would say, in a friendly way on GitHub, just in terms of how much resources that single repository was consuming. That then kind of started this work on a web-based, HTTP-based index to shift that away. That's certainly one area where we've seen how Rust has struggled a little bit with the platform, but also the platform provider struggled with us.

Jan David Nose: I think for Rust itself, especially when we look at CI, we really want to make sure that Rust works well on all of the targets and all the platforms we support. That means we have an extremely wide CI pipeline where, for every Tier 1 target, we want to run all the tests, we want to build the release artifacts, we want to upload all of that to S3. We want to do as much as we reasonably can for Tier 2 targets and, to a lesser extent, maybe even test some stuff on Tier 3. That has turned into a gigantic build pipeline. Marco gave a talk today on what we've done with CI over the last year. One of the numbers that came out of doing the research for this talk is that we accumulate over three million build minutes per month, which is about six years of CPU time every month.

Jan David Nose: Especially when it comes to open source projects, I think we're one of the biggest consumers of GitHub Actions in that sense. Not the biggest in total; there are definitely bigger commercial projects. But that's a unique challenge for us to manage because we want to provide as good a service as we can to the community and make sure that what we ship is high quality. That comes at a huge cost in terms of scaling. As Rust gets more popular and we want to target more and more platforms, this is like a problem that just continues to grow.

Jan David Nose: We'll probably never remove a lot of targets, so there's an interesting challenge to think about. If it's already big now, how does this look in 5 years, 10 years, 15 years, and how can we make sure we can maintain the level of quality we want to ship? When you build and run for a target in the CI pipeline, some of those Tier 1 targets you can just ask a cloud service provider to give you a VM running on that piece of hardware, but some of them are probably not things that you can just run in the cloud.

Xander Cesari: Is there some HIL (Hardware-In-the-Loop) lab somewhere?

Jan David Nose: So you're touching on a conversation that's happening pretty much as we speak. So far, as part of our target tier policy, there is a clause that says it needs to be able to run in CI. That has meant being very selective about only promoting things to Tier 1 that we can actually run and test. For all of this, we had a prerequisite that it runs on GitHub Actions. So far we've used very little hardware that is not natively supported or provided by GitHub.

Jan David Nose: But this is exactly the point with Rust increasing in popularity. We just got requests to support IBM platforms and RISC-V, and those are not natively supported on GitHub. That has kicked off an internal conversation about how we even support this. How can we as a project enable companies that can provide us hardware to test on? What are the implications of that?

Jan David Nose: On one side, there are interesting constraints and considerations. For example, you don't want your PRs to randomly fail because someone else's hardware is not available. We're already so resource-constrained on how many PRs we can merge each day that adding noise to that process would really slow down contributions to Rust. On the other side, there are security implications. Especially if we talk about promoting something to Tier 1 and we want to build release artifacts on that hardware, we need to make sure that those are actually secure and no one sneaks a back door into the Rust compiler target for RISC-V.

Jan David Nose: So there are interesting challenges for us, especially in the world we live in where supply chain security is a massive concern. We need to figure out how we can both support the growth of Rust and the growth of the language, the community, and the ecosystem at large while also making sure that the things we ship are reliable, secure, and performant. That is becoming an increasingly relevant and interesting piece to work on. So far we've gotten away with the platforms that GitHub supports, but it's really cool to see that this is starting to change and people approach us and are willing to provide hardware, provide sponsorship, and help us test on their platforms. But essentially we don't have a good answer for this yet. We're still trying to figure out what this means, what we need to take into consideration, and what our requirements are to use external hardware.

Xander Cesari: Yeah, everyone is so excited about Rust will run everywhere, but there's a maintenance cost there that is almost exponential in scope.

Jan David Nose: It's really interesting as well because there's a tension there. I think with IBM, for example, approaching us, it's an interesting example. Who has IBM platforms at home? The number of users for that platform is really small globally, but IBM also invests heavily in Rust, tries to make this happen, and is willing to provide the hardware.

Jan David Nose: For us, that leads to a set of questions. Is there a line? Is there a certain requirement? Is there a certain amount of usage that a platform would need for us to promote it? Or do we say we want to promote as much as we can to Tier 1? This is a conversation we haven't really had to have yet. It's only now starting to creep in as Rust is adopted more widely and companies pour serious money and resources into it. That's exciting to see.

Jan David Nose: In this specific case, companies approach the Infra Team to figure out how we can add their platforms to CI as a first step towards Tier 1 support. But it's also a broader discussion we need to have with larger parts of the Rust Project. For Tier 1 promotions, for example, the Compiler Team needs to sign off, Infra needs to sign off. Many more people need to be involved in this discussion of how we can support the growing needs of the ecosystem at large.

Xander Cesari: I get the feeling that's going to be a theme throughout this interview.

Jan David Nose: 100%.

Xander Cesari: So one other tool that's part of this pipeline that I totally didn't know about for a long time, and I think a talk at a different conference clued me into it, is Crater. It's a tool that attempts to run all of the Rust code it can find on the internet. Can you talk about what that tool does and how it integrates into the release process?

Jan David Nose: Whenever someone creates a pull request on GitHub to add a new feature or bug fix to the Rust compiler, they can start what's called a Crater run, or an experiment. Crater is effectively a large fleet of machines that tries to pull in as many crates as it can. Ideally, we would love to test all crates, but for a variety of reasons that's not possible. Some crates simply don't build reliably, so we maintain lists to exclude those. From the top of my head, I think we currently test against roughly 60% of crates.

Jan David Nose: The experiment takes the code from your pull request, builds the Rust compiler with it, and then uses that compiler to build all of these crates. It reports back whether there are any regressions related to the change you proposed. That is a very important tool for us to maintain backwards compatibility with new versions and new features in Rust. It lets us ask: does the ecosystem still compile if we add this feature to the compiler, and where do we run into issues? Then, and this is more on the Compiler Team side, there's a decision about how to proceed. Is the breakage acceptable? Do we need to adjust the feature? Having Crater is what makes that conversation possible because it gives us real data on the impact on the wider ecosystem.

Xander Cesari: I think that's so interesting because as more and more companies adopt Rust, they're asking whether the language is going to be stable and backward compatible. You hear about other programming languages that had a big version change that caused a lot of drama and code changes. The fact that if you have code on crates.io, the Compiler Team is probably already testing against it for backwards compatibility is pretty reassuring.

Jan David Nose: Yeah, the chances are high, I would say. Especially looking at the whole Python 2 to Python 3 migration, I think as an industry we've learned a lot from those big version jumps. I can't really speak for the Compiler Team because I'm not a member and I wasn't involved in the decision-making, but I feel this is one of the reasons why backwards compatibility is such a big deal in Rust's design. We want to make it as painless as possible to stay current, stay up to date, and make sure we don't accidentally break the language or create painful migration points where the entire ecosystem has to move at once.

Xander Cesari: Do you know if there are other organizations pulling in something like Crater and running it on their own internal crate repositories, maybe some of the big tech companies or other compiler developers or even other languages? Or is this really bespoke for the Rust compiler team?

Jan David Nose: I don't know of anyone who runs Crater itself as a tool. Crater is built on a sandboxing framework that we also use in other places. For example, docs.rs uses some of the same underlying infrastructure to build all of the documentation. We try to share as much as we can of the functionality that exists in Crater, but I'm not aware of anyone using Crater in the same way we do.

Xander Cesari: Gotcha. The other big part of your job is that the Infra Team works on supporting maintainers, but it also supports users and consumers of Rust who are pulling from crates.io. It sounds like crates.io is not directly within your team, but you support a lot of the backend there.

Jan David Nose: Yeah, exactly. crates.io has its own team, and that team maintains the web application and the APIs. The crates themselves, all the individual files that people download, are hosted within our infrastructure. The Infra Team maintains the content delivery network that sits in front of that. Every download of a crate goes through infrastructure that we maintain. We collaborate very closely with the crates.io team on this shared interface. They own the app and the API, and we make sure that the files get delivered to the end user.

Xander Cesari: So it sounds like there's a lot of verification of the files that get uploaded and checks every time someone pushes a new version to crates.io. That part all happens within crates.io as an application.

Jan David Nose: Cargo uses the crates.io API to upload the crate file. crates.io has a lot of internal logic to verify that it is valid and that everything looks correct. For us, as the Infra Team, we treat that as a black box. crates.io does its work, and if it is happy with the upload, it stores the file in S3. From that point onward, infrastructure makes sure that the file is accessible and can be downloaded so people can start using your crate.

Xander Cesari: In this theme of Rust being a bit of a victim of its own success, I assume all of the traffic graphs and download graphs are very much up and to the right.

Jan David Nose: On the Foundation side, one of our colleagues likes to check how long it takes for one billion downloads to happen on crates.io, and that number has been falling quickly. I don't remember what it was three years ago, but it has come down by orders of magnitude. In our download traffic we definitely see exponential growth. Our traffic tends to double year over year, and that trend has been pretty stable. It really seems like Rust is getting a lot of adoption in the ecosystem and people are using it for more and more things.

Xander Cesari: How has the Infra Team scaled with that? Are you staying ahead of it, or are there a lot of late nights?

Jan David Nose: There have definitely been late nights. In the three years I've been working in the Infra Team, every year has had a different theme that was essentially a fire to put out.

Jan David Nose: It changes because we fix one thing and then the next thing breaks. So far, luckily, those fires have been mostly sequential, not parallel. When I joined, bandwidth was the big topic. Over the last year, it has been more about CI. About three years ago, we hit this inflection point where traffic was doubling and the sponsorship capacity we had at the time was reaching its limits.

Jan David Nose: Two or three years ago, Fastly welcomed us into their Fast Forward program and has been sponsoring all of our bandwidth since then. That has mostly helped me sleep at night. It has been a very good relationship. They have been an amazing partner and have helped us at every step to remove the fear that we might hit limits. They are very active in the open source community at large; most famously they also sponsor PyPI and the Python ecosystem, compared to which we're a tiny fish in a very big pond. That gives us a lot of confidence that we can sustain this growth and keep providing crates and releases at the level of quality people expect.

Xander Cesari: In some ways, Rust did such a good job of making all of that infrastructure feel invisible. You just type Cargo commands into your terminal and it feels magical.

Jan David Nose: I'm really happy about that. It's an interesting aspect of running an infrastructure team in open source. If you look at the ten-year history since the first stable release, or even the fifteen years since Rust really started, infrastructure was volunteer-run for most of that time. I've been here for three years, and I was the first full-time infrastructure engineer. So for ten to twelve years, volunteers ran the infrastructure.

Jan David Nose: For them, it was crucial that things just worked, because you can't page volunteers in the middle of the night because a server caught fire or downloads stopped working. From the beginning, our infrastructure has been designed to be as simple and as reliable as possible. The same is true for our CDNs. I always feel a bit bad because Fastly is an amazing sponsor. Every time we meet them at conferences or they announce new features, they ask whether we want to use them or talk about how we use Fastly in production. And every time I have to say: we have the simplest configuration possible. We set some HTTP headers. That's pretty much it.

Jan David Nose: It's a very cool platform, but we use the smallest set of features because we need to maintain all of this with a very small team that is mostly volunteer-based. Our priority has always been to keep things simple and reliable and not chase every fancy new technology, so that the project stays sustainable.

Xander Cesari: Volunteer-based organizations seem to have to care about work-life balance, which is probably terrific, and there are lessons to be learned there.

Jan David Nose: Yeah, it's definitely a very interesting environment to work in. It has different rules than corporations or commercial teams. We have to think about how much work we can do in a given timeframe in a very different way, because it's unpredictable when volunteers have time, when they're around, and what is happening in their lives.

Jan David Nose: Over the last few years, we've tried to reduce the number of fires that can break out. And when they do happen, we try to shield volunteers from them and take that work on as full-time employees. That started with me three years ago. Last year Marco joined, which increased the capacity we have, because there is so much to do on the Infra side that even with me working full-time, we simply did not have enough people.

Xander Cesari: So you're two full-time and everything else is volunteer.

Jan David Nose: Exactly. The team is around eight people. Marco and I work full-time and are paid by the Rust Foundation to focus exclusively on infrastructure. Then we have a handful of volunteers who work on different things.

Jan David Nose: Because our field of responsibility is so wide, the Infra Team works more in silos than other teams might. We have people who care deeply about very specific parts of the infrastructure. Otherwise there is simply too much to know for any one person. It has been a really nice mix, and it's amazing to work with the people on the team.

Jan David Nose: As someone who is privileged enough to work full-time on this and has the time and resources, we try to bear the bigger burden and create a space that is fun for volunteers to join. We want them to work on exciting things where there is less risk of something catching fire, where it's easier to come in, do a piece of work, and then step away. If your personal life takes over for two weeks, that's okay, because someone is there to make sure the servers and the lights stay on.

Jan David Nose: A lot of that work lives more on the maintainer side: the GitHub apps, the bots that help with triage. It's less risky if something goes wrong there. On the user side, if you push the wrong DNS setting, as someone might have done, you can end up in a situation where for 30 minutes no one can download crates. And in this case, "no one" literally means no user worldwide. That's not an experience I want volunteers to have. It's extremely stressful and was ultimately one of the reasons I joined in the first place—there was a real feeling of burnout from carrying that responsibility.

Jan David Nose: It's easier to carry that as a full-timer. We have more time and more ways to manage the stress. I'm honestly extremely amazed by what the Infra Team was able to do as volunteers. It's unbelievable what they built and how far they pushed Rust to get to where we are now.

Xander Cesari: I think anyone who's managing web traffic in 2025 is talking about traffic skyrocketing due to bots and scrapers for AI or other purposes. Has that hit the Rust network as well?

Jan David Nose: Yeah, we've definitely seen that. It's handled by a slightly different team, but on the docs.rs side in particular we've seen crawlers hit us hard from time to time, and that has caused noticeable service degradation. We're painfully aware of the increase in traffic that comes in short but very intense bursts when crawlers go wild.

Jan David Nose: That introduces a new challenge for our infrastructure. We need to figure out how to react to that traffic and protect our services from becoming unavailable to real users who want to use docs.rs to look up something for their work. On the CDN side, our providers can usually handle the traffic. It is more often the application side where things hurt.

Jan David Nose: On the CDN side we also see people crawling crates.io, presumably to vacuum up the entire crates ecosystem into an LLM. Fortunately, over the last two years we've done a lot of work to make sure crates.io as an application is less affected by these traffic spikes. Downloads now bypass crates.io entirely and go straight to the CDN, so the API is not hit by these bursts. In the past, this would have looked like a DDoS attack, with so many requests from so many sources that we couldn't handle it.

Jan David Nose: We've done a lot of backend work to keep our stack reliable, but it's definitely something that has changed the game over the last year. We can clearly see that crawlers are much more active than before.

Xander Cesari: That makes sense. I'm sure Fastly is working on this as well. Their business has to adapt to be robust to this new internet.

Jan David Nose: Exactly. For example, one of the conversations we're having right now is about docs.rs. It's still hosted on AWS behind CloudFront, but we're talking about putting it behind Fastly because through Fastly we get features like bot protection that can help keep crawlers out.

Jan David Nose: This is a good example of how our conversations have changed in the last six months. At the start of the year I did not think this would be a topic we would be discussing. We were focused on other things. For docs.rs we have long-term plans to rebuild the infrastructure that powers it, and I expected us to spend our energy there. But with the changes in the industry and everyone trying to accumulate as much data as possible, our priorities have shifted. The problems we face and the order in which we tackle them have changed.

Xander Cesari: And I assume as one of the few paid members of a mostly volunteer team, you often end up working on the fires, not the interesting next feature that might be more fun.

Jan David Nose: That is true, although it sounds a bit negative to say I only get to work on fires. Sometimes it feels like that because, as with any technology stack, there is a lot of maintenance overhead. We definitely pay that price on the infrastructure side.

Jan David Nose: Marco, for example, spent time this year going through all the servers we run, cataloging them, and making sure they're patched and on the latest operating system version. We updated our Ubuntu machines to the latest LTS. It feels a bit like busy work—you just have to do it because it's important and necessary, but it's not the most exciting project.

Jan David Nose: On the other hand, when it comes to things like CDN configuration and figuring out how bot protection features work and whether they are relevant to us, that is also genuinely interesting work. It lets us play with new tools vendors provide, and we're working on challenges that the wider industry is facing. How do you deal with this new kind of traffic? What are the implications of banning bots? How high is the risk of blocking real users? Sometimes someone just misconfigures a curl script, and from the outside it looks like they're crawling our site.

Jan David Nose: So it's an interesting field to work in, figuring out how we can use new features and address new challenges. That keeps it exciting even for us full-timers who do more of the "boring" work. We get to adapt alongside how the world around us is changing. If there's one constant, it's change.

Xander Cesari: Another ripped-from-the-headlines change around this topic is software supply chain security, and specifically xz-utils and the conversation around open source security. How much has that changed the landscape you work in?

Jan David Nose: The xz-utils compromise was scary. I don't want to call it a wake-up call, because we've been aware that supply chain security is a big issue and this was not the first compromise. But the way it happened felt very unsettling. You saw an actor spend a year and a half building social trust in an open source project and then using that to introduce a backdoor.

Jan David Nose: Thinking about that in the context of Rust: every team in the project talks about how we need more maintainers, how there's too much workload on the people who are currently contributing, and how Rust's growth puts strain on the organization as a whole. We want to be an open and welcoming project, and right now we also need to bring new people in. If someone shows up and says, "I'm willing to help, please onboard me," and they stick around for a year and then do something malicious, we would be susceptible to that. I don't think this is unique to Rust. This is an inherent problem in open source.

Xander Cesari: Yeah, it's antithetical to the culture.

Jan David Nose: Exactly. So we're trying to think through how we, as a project and as an ecosystem, deal with persistent threat actors who have the time and resources to play a long game. Paying someone to work full-time on open source for a year is a very different threat model than what we used to worry about.

Jan David Nose: I used to joke that the biggest threat to crates.io was me accidentally pulling the plug on a CDN. I think that has changed. Today the bigger threat is someone managing to insert malicious code into our releases, our supply chain, or crates.io itself. They could find ways to interfere with our systems in ways we're simply not prepared for, where, as a largely volunteer organization, we might be too slow to react to a new kind of attack.

Jan David Nose: Looking back over the last three years, this shift became very noticeable, especially after the first year. Traffic was doubling, Rust usage was going up a lot, and there were news stories about Rust being used in the Windows kernel, in Android, and in parts of iOS. Suddenly Rust is everywhere. If you want to attack "everywhere," going after Rust becomes attractive. That definitely puts a target on our back and has changed the game.

Jan David Nose: I'm very glad the Rust Foundation has a dedicated security engineer who has done a lot of threat modeling and worked with us on infrastructure security. There's also a lot of work happening specifically around the crates ecosystem and preventing supply chain attacks through crates. Luckily, it's not something the Infra side has to solve alone. But it is getting a lot more attention, and I think it will be one of the big challenges for the future: how a mostly volunteer-run project keeps up with this looming threat.

Xander Cesari: And it is the industry at large. This is not a unique problem to the Rust package manager. All package registries, from Python to JavaScript to Nix, deal with this. Is there an industry-wide conversation about how to help each other out and share learnings?

Jan David Nose: Yeah, there's definitely a lot happening. I have to smile a bit because, with a lot of empathy but also a bit of relief, we sometimes share news when another package ecosystem gets compromised. It is a reminder that it's not just us, sometimes it's npm this time.

Jan David Nose: We really try to stay aware of what's happening in the industry and in other ecosystems: what new threats or attack vectors are emerging, what others are struggling with. Sometimes that is security; sometimes it's usability. A year and a half ago, for example, npm had the "everything" package where someone declared every package on npm as a dependency, which blew up the index. We look at incidents like that and ask whether crates.io would struggle with something similar and whether we need to make changes.

Jan David Nose: On the security side we also follow closely what others are doing. In the packaging community, the different package managers are starting to come together more often to figure out which problems everyone shares. There is a bit of a joke that we're all just shipping files over the internet. Whether it's an npm package or a crate, ultimately it's a bunch of text files in a zip. So from an infrastructure perspective the problems are very similar.

Jan David Nose: These communities are now talking more about what problems PyPI has, what problems crates.io has, what is happening in the npm space. One thing every ecosystem has seen—even the very established ones—is a big increase in bandwidth needs, largely connected to the emergence of AI. PyPI, for example, publishes download charts, and it's striking. Python had steady growth—slightly exponential, but manageable—for many years. Then a year or two ago you see a massive hockey stick. People discovered that PyPI was a great distribution system for their models. There were no file size limits at the time, so you could publish precompiled GPU models there.

Jan David Nose: That pattern shows up everywhere. It has kicked off a new era for packaging ecosystems to come together and ask: in a time where open source is underfunded and traffic needs keep growing, how can we act together to find solutions to these shared problems? crates.io is part of those conversations. It's interesting to see how we, as an industry, share very similar problems across ecosystems—Python, npm, Rust, and others.

Xander Cesari: With a smaller, more hobbyist-focused community, you can have relaxed rules about what goes into your package manager. Everyone knows the spirit of what you're trying to do and you can get away without a lot of hard rules and consequences. Is the Rust world going to have to think about much harder rules around package sizes, allowed files, and how you're allowed to distribute things?

Jan David Nose: Funnily enough, we're coming at this from the opposite direction. Compared to other ecosystems, we've always had fairly strict limits. A crate can be at most around ten megabytes in size. There are limits on what kinds of files you can put in there. Ironically, those limits have helped us keep traffic manageable in this period.

Jan David Nose: At the same time, there is a valid argument that these limits may not serve all Rust use cases. There are situations where you might want to include something precompiled in your crate because it is hard to compile locally, takes a very long time, or depends on obscure headers no one has. I don't think we've reached the final state of what the crates.io package format should look like.

Jan David Nose: That has interesting security implications. When we talk about precompiled binaries or payloads, we all have that little voice in our head every time we see a curl | sh command: can I trust this? The same is true if you download a crate that contains a precompiled blob you cannot easily inspect.

Jan David Nose: The Rust Foundation is doing a lot of work and research here. My colleague Adam, who works on the crates.io team, is working behind the scenes to answer some of these questions. For example: what kind of security testing can we do before we publish crates to make sure they are secure and don't contain malicious payloads? How do we surface this information? How do we tell a publisher that they included files that are not allowed? And from the user's perspective, when you visit crates.io, how can you judge how well maintained and how secure a crate is?

Jan David Nose: Those conversations are happening quite broadly in the ecosystem. On the Infra side we're far down the chain. Ultimately we integrate with whatever security scanning infrastructure crates.io builds. We don't have to do the security research ourselves, but we do have to support it.

Jan David Nose: There's still a lot that needs to happen. As awesome as Rust already is, and as much as I love using it, it's important to remember that we're still a very young ecosystem. Python is now very mature and stable, but it's more than 25 years old. Rust is about ten years old as a stable language. We still have a lot to learn and figure out.

Xander Cesari: Is the Rust ecosystem running into problems earlier than other languages because we're succeeding at being foundational software and Rust is used in places that are even more security-critical than other languages, so you have to hit these hard problems earlier than the Python world did?

Jan David Nose: I think that's true. Other ecosystems probably had more time to mature and answer these questions. We're operating on a more condensed timeline. There is also simply more happening now. Open source has been very successful; it's everywhere. That means there are more places where security is critical.

Jan David Nose: So this comes with the success of open source, with what is happening in the ecosystem at large, and with the industry we're in. It does mean we have less time to figure some things out. On the flip side, we also have less baggage. We have less technical debt and fifteen fewer years of accumulated history. That lets us be on the forefront in some areas, like how a package ecosystem can stay secure and what infrastructure a 21st century open source project needs.

Jan David Nose: Here I really want to call out the Rust Foundation. They actively support this work: hiring people like Marco and me to work full-time on infrastructure, having Walter and Adam focus heavily on security, and as an organization taking supply chain considerations very seriously. The Foundation also works with other ecosystems so we can learn and grow together and build a better industry.

Jan David Nose: Behind the scenes, colleagues constantly work to open doors for us as a relatively young language, so we can be part of those conversations and sit at the table with other ecosystems. That lets us learn from what others have already gone through and also help shape where things are going. Sustainability is a big part of that: how do we fund the project long term? How do we make sure we have the human resources and financial resources to run the infrastructure and support maintainers? I definitely underestimated how much of my job would be relationship management and budget planning, making sure credits last until new ones arrive.

Xander Cesari: Most open core business models give away the thing that doesn't cost much—the software—and charge for the thing that scales with use—the service. In Rust's case, it's all free, which is excellent for adoption, but it must require a very creative perspective on the business side.

Jan David Nose: Yeah, and that's where different forces pull in opposite directions. As an open source project, we want everyone to be able to use Rust for free. We want great user experience. When we talk about downloads, there are ways for us to make them much cheaper, but that might mean hosting everything in a single geographic location. Then everyone, including people in Australia, would have to download from, say, Europe, and their experience would get much worse.

Jan David Nose: Instead, we want to use services that are more expensive but provide a better experience for Rust users. There's a real tension there. On one side we want to do the best we can; on the other side we need to be realistic that this costs money.

Xander Cesari: I had been thinking of infrastructure as a binary: it either works or it doesn't. But you're right, it's a slider. You can pick how much money you want to spend and what quality of service you get. Are there new technologies coming, either for the Rust Infra Team or the packaging world in general, to help with these security problems? New sandboxing technologies or higher-level support?

Jan David Nose: A lot of people are working on this problem from different angles. Internally we've talked a lot about it, especially in the context of Crater. Crater pulls in all of those crates to build them and get feedback from the Rust compiler. That means if someone publishes malicious code, we will download it and build it.

Jan David Nose: In Rust this is a particular challenge because build scripts can essentially do anything on your machine. For us that means we need strong sandboxing. We've built our own sandboxing framework so every crate build runs in an isolated container, which prevents malicious code from escaping and messing with the host systems.

Jan David Nose: We feel that pain in Crater, but if we can solve it in a way that isn't exclusive to Crater—if it also protects user machines from the same vulnerabilities—that would be ideal. People like Walter on the Foundation side are actively working on that. I'm sure there are conversations in the Cargo and crates teams as well, because every team that deals with packages sees a different angle of the problem. We all have to come together to solve it, and there is a lot of interesting work happening in that area.

Xander Cesari: I hope help is coming.

Jan David Nose: I'm optimistic.

Xander Cesari: We have this exponential curve with traffic and everything else. It seems like at some point it has to taper off.

Jan David Nose: We'll see. Rust is a young language. I don't know when that growth will slow down. I think there's a good argument that it will continue for quite a while as adoption grows.

Jan David Nose: Being at a conference like RustConf, it's exciting to see how the mix of companies has changed over time. We had a talk from Rivian on how they use Rust in their cars. We've heard from other car manufacturers exploring it. Rust is getting into more and more applications that a few years ago would have been hard to imagine or where the language simply wasn't mature enough yet.

Jan David Nose: As that continues, I think we'll see new waves of growth that sustain the exponential curve we currently have, because we're moving into domains that are new for us. It's amazing to see who is talking about Rust and how they're using it, sometimes in areas like space that you wouldn't expect.

Jan David Nose: I'm very optimistic about Rust's future. With this increase in adoption, we'll see a lot of interesting lessons about how to use Rust and a lot of creative ideas from people building with it. With more corporate adoption, I also expect a new wave of investment into the ecosystem: companies paying people to work full-time on different parts of Rust, both in the ecosystem and in the core project. I'm very curious what the next ten years will look like, because I genuinely don't know.

Xander Cesari: The state of Rust right now does feel a bit like the dog that caught the car and now doesn't know what to do with it.

Jan David Nose: Yeah, I think that's a good analogy. Suddenly we're in a situation where we realize we haven't fully thought through every consequence of success. It's fascinating to see how the challenges change every year. We keep running into new growing pains where something that wasn't an issue a year ago suddenly becomes one because growth keeps going up.

Jan David Nose: We're constantly rebuilding parts of our infrastructure to keep up with that growth, and I don't see that stopping soon. As a user, that makes me very excited. With the language and the ecosystem growing at this pace, there are going to be very interesting things coming that I can't predict today.

Jan David Nose: For the project, it also means there are real challenges: financing the infrastructure we need, finding maintainers and contributors, and creating a healthy environment where people can work without burning out. There is a lot of work to be done, but it's an exciting place to be.

Xander Cesari: Well, thank you for all your work keeping those magic Cargo commands I can type into my terminal just working in the background. If there's any call to action from this interview, it's that if you're a company using Rust, maybe think about donating to keep the Infra Team working.

Jan David Nose: We always love new Rust Foundation members. Especially if you're a company, that's one of the best ways to support the work we do. Membership gives us a budget we can use either to fund people who work full-time on the project or to fill gaps in our infrastructure sponsorship where we don't get services for free and have to pay real money.

Jan David Nose: And if you're not a company, we're always looking for people to help out. The Infra Team has a lot of Rust-based bots and other areas where people can contribute relatively easily.

Xander Cesari: Small scoped bots that you can wrap your head around and help out with.

Jan David Nose: Exactly. It is a bit harder on the Infra side because we can't give people access to our cloud infrastructure. There are areas where it's simply not possible to contribute as a volunteer because you can't have access to the production systems. But there is still plenty of other work that can be done.

Jan David Nose: Like every other team in the project, we're a bit short-staffed. So when you're at conferences, come talk to me or Marco. We have work to do.

Xander Cesari: Well, thank you for doing the work that keeps Rust running.

Jan David Nose: I'm happy to.

Xander Cesari: Awesome. Thank you so much.

Infrastructure announcement Zulip channel

2025-11-16T00:00:00+00:00

The Infrastructure Team is working on improving communication for project infrastructure changes that may impact project team members and Dev Desktop users.

We are creating a new low traffic Zulip channel, #infra/announcements, dedicated to infrastructure change announcements. Examples of announcement topics may include, but are not limited to:

Commissioning/decommissioning of Dev Desktops
Significant CI changes
Significant permission changes
Significant prolonged outages of infrastructure services
... and other significant events which the Infrastructure Team anticipates may impact project members.

Transient outages will not be posted to in this announcement channel to maintain a high signal-to-noise ratio of this announcement channel.

We will subscribe:

All project team members
gsoc-contributors, ospp-contributors and cloud-compute marker team members

with registered Zulip IDs to the dedicated #infra/announcements zulip channel.^[1]

For project team members without registered Zulip IDs, you are encouraged to do so by updating your people/<handle>.toml entry in the rust-lang/team repository so that the Infrastructure Team can consistently announce project infrastructure changes that may impact you.

Note that you can mute specific topics that do not concern you specifically. We adopted this "blanket" announce approach because in our experience, not reaching impacted project team members and Dev Desktop users is significantly more problematic. ↩

Renaming the default branch of rust-lang/rust

2025-10-16T00:00:00+00:00

The rename happened on November 10, 2025. The default branch of rust-lang/rust is now named main.

We will be renaming the default branch of the rust-lang/rust repository from master to main on 2025-11-10. We've chosen main specifically as it's the default for newly-created repositories in GitHub and the renaming will leverage the GitHub tooling built to make this easier.

If you maintain a tool that currently assumes the default branch of rust-lang/rust is named master, using HEAD instead will work both before and after the rename.

After the rename, contributors will need to run a few git commands in their local checkout of the repository to update. Note that the specific commands that should be executed might differ based on the way you use git and how your local checkout is configured. We provide a guide below that we think should work for most use-cases, but your mileage may vary.

Please try to follow the guide step-by-step, and if you run into any problems, feel free to ask in this Zulip channel.

Renaming your fork's default branch

If you have a fork of the rust-lang/rust repository on GitHub, you should first update its default branch name before continuing. If you do not rename it and later run git checkout master, git will create a master branch based on your fork's outdated master branch, which can be confusing. Some of the following git commands in this post might also not work as expected.

Here is how you can update your fork's default branch:

Go to https://github.com/<your-username>/rust/settings
Find the default branch section, click on the "Rename branch" button (pencil icon) and rename the branch to main.

Updating your local git checkout

Execute the following git commands in your local checkout of the rust repository.

Note that the instructions below make two assumptions:

You have a git remote called upstream that points to the rust-lang/rust repository and a remote called origin that points to your <username>/rust fork. Please update the commands accordingly if you use a different setup.
- You can find out which remotes you have configured using the git remote -v command.
Your local master branch tracks the default branch of your fork, not the default branch of the upstream rust-lang/rust repository. If that is not the case, execute the commented git branch command instead.
- You can find which remote your local master branch tracks by using git branch -vv --contains master (the tracked branch should be shown in square brackets).

# Update the local branch name
git branch --move master main

# Update local references to your <username>/rust fork
git fetch origin
git branch --set-upstream-to=origin/main main # If your main branch tracks your fork
git remote set-head origin --auto

# Update local references relevant to the upstream rust-lang/rust repository
git fetch upstream
#git branch --set-upstream-to=upstream/main main # If your main branch tracks the upstream repo
git remote set-head upstream --auto

# Remove old branch names (optional, but recommended)
git remote prune origin
git remote prune upstream

Infrastructure Team 2025 Q3 Recap and Q4 Plan

2025-10-16T00:00:00+00:00

As we wrap up the third quarter of 2025, the Infrastructure Team is excited to share what we've accomplished and what's coming next.

Q3 2025 Accomplishments

crates-io-auth-action

We created the crates-io-auth-action, which can be used to obtain publish tokens for crates.io using trusted publishing.

Critical data asset backup

One of our most important security improvements this quarter was establishing an out-of-band backup system for Rust's critical data assets. Previously, all of Rust's releases and crates were stored exclusively on AWS. We've now created a backup in Google Cloud Platform that includes all Rust releases and crates, with daily incremental updates.

The GCP account is owned by two Rust Foundation staff members who are not AWS administrators (i.e., they aren't admins on the Infrastructure Team). This makes it significantly more difficult for an attacker to compromise or delete both the primary and backup data, as they would need to breach at least two separate accounts.

Learn more about this initiative in our docs.

CDN alerts

The CDNs for Rust releases and crates are critically important for users of Rust. If either suffers a service disruption, it directly impacts users' ability to install Rust and build their projects.

In the past, we had set up integrations for AWS CloudFront and Fastly, our Content Delivery Networks, with Datadog, our monitoring platform. While we had metrics coming into Datadog in real time, we had not set up alerts on top of them.

In Q3, we created multiple alerts that monitor our CDNs and report when traffic falls below predefined thresholds. These alerts ping the engineering team at the Rust Foundation, which has a runbook for incidents, including notifying the community.

GitHub issue: rust-lang/infra-team#179.

`rust-lang.org` is now a static website

We converted rust-lang.org from a Rust web server deployed on Heroku to a static website hosted on GitHub Pages. This change eliminates several security and operational concerns:

Enhanced security: Static sites are inherently more secure and less vulnerable to DDoS attacks.
Simplified infrastructure: Removes the complexity of managing a web server, which is unnecessary to serve static content.
Cost reduction: GitHub Pages hosting is free, while the Foundation was paying for the previous Heroku deployment.
Improved robustness: Static hosting is generally more reliable and performant.

Thanks to Manishearth and senekor from the website team for their reviews and support.

GitHub PR: rust-lang/www.rust-lang.org#2174.

GitHub organization members cleanup

The Infra Team created an automated process to clean up all GitHub organizations managed by the Rust Project by removing members who are not part of any team within those organizations. You can learn more in the Inside Rust Blog post.

Thanks to me-diru for starting the implementation.

The new Bors runs Rust CI try builds

The Infra and Bors teams continued working on migrating the Rust CI from the legacy Bors (Homu) to the new Bors, written in Rust.

Starting in July, all try builds (@bors try) have run exclusively through the new bors. This is a significant step forward in improving the reliability of our continuous integration infrastructure.

GitHub PR: rust-lang/bors#352

The GSoC project for implementing merge functionality in Bors has concluded (we will post a blog post in the upcoming weeks that will describe the results of all our GSoC projects). We plan to deploy bors to production and fully replace homu by it in the upcoming months.

Improving rebase force-push review experience with a range-diff for GitHub PRs

The triagebot team has worked on implementing an emulated git range-diff for GitHub PRs.

The feature is enabled on rust-lang/rust^[1] and automatically posts a comment when a force-push with a rebase is detected, containing a link to the comparison.

An example of the same push shown by GitHub and shown by our range-diff.

See #t-compiler > Experimental range-diff for force-push for more details.

Improving reviewing experience on GitHub PRs

Following the range-diff feature the triagebot team has worked on improving the experience of reviewing GitHub PRs in particular focusing on changes since the last review.

This new feature is enabled on rust-lang/rust^[2] and automatically adds a comparison link to every top-level review comment.

Support optional CI jobs

Until now, CI only had jobs that ran on PRs or when a merge to the default branch was attempted (i.e., the auto build). We added support for CI jobs that run only on demand, allowing contributors to run these tests on PRs whenever they are concerned about breaking certain parts of the codebase. This is useful for testing tier 2 and tier 3 targets in CI, whose tests don’t always run on CI by default.

This feature was requested in #t-infra > Testing for T2/T3 targets and documented in rust-lang/rust#143283.

Automating subtree synchronization

We have implemented a new tool called rustc-josh-sync, which makes it easier to synchronize changes between Josh subtrees and the main rust-lang/rust repository. We have migrated the existing Josh subtrees (such as miri or rust-analyzer) to this tool, which enables us to perform subtree synchronizations in a more unified way.

Implementing support for multiple machines for rustc-perf

We made a lot of progress with the Rust project goal for improving our compiler benchmark suite. The benchmark suite is now able to run benchmarks on multiple machines (called collectors) in parallel. This will enable us to reduce the latency of waiting for benchmark results, and also allow us to benchmark the compiler on different architectures than just x64 (e.g. ARM) and in theory even on different OSes than just Linux (e.g. Windows). The project goal has been carried over to the next goal period. We plan to deploy the new system into production in the upcoming months.

Repository default branch renames

We're updating our repositories to use more inclusive naming conventions. This quarter, we renamed the default branches from master to main in the rustc-dev-guide (PR), www.rust-lang.org (PR) and blog.rust-lang.org (PR) repositories.

Thanks to senekor, tshepang, carols10cents, and everyone else involved.

Talks and interviews

At RustConf 2025:

JD was interviewed about the Rust Infrastructure team. You can find the video here.
Marco presented the talk "How We Made the Rust CI 75% Cheaper". You can find the video here.

Q4 2025 Plans

Looking ahead to Q4, we have planned the following initiatives:

Hire a new Rust Foundation infrastructure engineer

JD, one of the two Infrastructure Engineers employed full-time by the Rust Foundation, resigned to start his own company. JD is staying on the team as a volunteer, but he will be able to dedicate less time than before. This quarter, we want to hire a new Infrastructure Engineer to restore the previous capacity of the team. If you are interested, check the Rust Foundation careers page.

We would like to take this opportunity to thank JD for his three years of invaluable contributions and support to the Rust Infrastructure Team and the Rust community. To learn more about his transition, you can read his blog post.

docs.rs infrastructure modernization

docs.rs is still deployed to a single, manually provisioned and managed EC2 instance. We want to collaborate with the docs.rs team to understand what kind of infrastructure would best fit docs.rs and to provision it, making docs.rs more robust and scalable.

External hardware CI policy

Today, we run CI only on AWS and GitHub-hosted runners, which are operated by us. Unfortunately, these cloud providers don't support all Rust targets, and emulation has limitations. To raise the tier of some of these targets, some organizations have offered to run the Rust CI on their own hardware.

We want to write a policy to define the requirements that the external hardware and the entity operating it must satisfy. For example, if the hardware has an uptime of 50%, we can't run CI jobs on it, because it would block the development of Rust.

GitHub issue: rust-lang/infra-team#201

GCP Dev Desktops

Google donated some GCP credits to the Rust Foundation for next year. We plan to use part of the credits to spin up one or two dev desktops in GCP to provide more VMs to contributors working on Rust.

Note that these machines can be discontinued in the future based on funding.

Learn more about Dev Desktops in the Rust Forge.

Conferences

Some members of the Infrastructure team will attend EuroRust and RustLab. Feel free to reach out to us if you want to meet in person!

In particular, on November 4th, Marco is giving a talk at RustLab titled “1.5 years in the infra team: what we cooked and what’s next”.

Join us!

If you're interested in contributing to Rust's infrastructure, have a look at the infra-team repository to learn more about us and reach out on Zulip.

We are always looking for new contributors!

See the docs on the Forge. ↩
See the docs on the Forge. ↩

Removing inactive members from our GitHub organizations

2025-08-26T00:00:00+00:00

The Infrastructure Team is cleaning up GitHub organizations managed by the Rust Project (rust-lang, rust-dev-tools, rust-lang-deprecated, rust-lang-nursery and rust-analyzer) by removing members who are not part of any team within those organizations.

If you are currently a member of one of these GitHub organizations, you might receive a removal email from GitHub that notifies you that you have been removed from some of them. If you are currently an active Rust team member, then do not worry! Your access to the rust-lang organization won't be affected by this, and at most we will remove you from some of the legacy organizations that are no longer in active use.

If you contributed to Rust in the past and you are no longer an active contributor, then we will likely remove you from all of the mentioned GitHub organizations. We understand that some people publicly displayed their membership in the rust-lang organization as a recognition of past contributions. As an alternative, your contributor status is shown on the official teams page of the Rust website, which includes an alumni section for each team. Please reach out if your past team memberships are not reflected on this page. Also, we want to take this opportunity to thank you for the time you spent in the past making Rust what it is today!

If you have been removed from an organization you think you should be part of, or you have any other questions, please reach out on our chat platform, Zulip.

Archived teams

Unfortunately, archived teams are not shown on the website's governance page, so previous Rust Project members who were part of archived teams only won't be listed in any alumni section.

We created a GitHub issue to track this, but in the meantime we would like to thank these contributors in this post:

alexheretic
am-1t
arora-aman
autozimu
avadacatavra
azhng
azuremarker
basil-cow
bawerd
benlewis-seequent
chrispardy
comex
detrumi
djcarpe
gnunicorn
hameerabbasi
hdhoang
hkmatsumoto
inquisitivecrystal
jamespatrickgill
jasonwilliams
jduchniewicz
jechasteen
jenniferwills
logmosier
lucasbullen
markmccaskey
mstallmo
mystor
nagashi
nathanwhit
null-sleep
o0ignition0o
pcwalton
peschkaj
qmx
roxelo
seanchen1991
stupremee
tamuhey
valgrimm
vlad20012
whitequark
zaharidichev

Hidden teams

Some Rust teams, such as marker teams and some working groups are not shown in the website's governance page.

We would like to thank the contributors who only belong to these teams in this post:

adamgreig
AlexEne
andre-richter
AngelOnFira
Dajamante
eldruin
hargoniX
korken89
kvark
levex
luqmana
Nashenas88
retep998
ryankurte
thejpster
therealprof
tromey

Members without contact

Some past members are not listed in the rust-lang/team repo, so we are unable to add them to the alumni sections and list them in the website.

If you are one of these members and want to be listed in the alumni sections of your previous teams, please open a PR in the rust-lang/team repo.

We would like to thank these contributors in this post:

aajtodd
aatxe
adrq
ALCC01
alecmocatta
andrewtj
anp
anxiousmodernman
aravind-pg
arazabishov
ashfordneil
autodidaddict
azdle
blitzerr
bluss
brendanzab
cassiersg
championshuttler
chrisvittal
CryZe
dhuseby
dibsonmuad
Diggsey
dirtybit
dustypomerleau
dyxushuai
ehsanmok
ELD
emberian
ereichert
fairingrey
flaper87
fmckeogh
gaurikholkar-zz
gavento
GeertVL-zz
gereeter
giannicic
glandium
gruberb
gsollazzo
h1467792822
Haggus
hrvolapeter
ibabushkin
inejge
jbcden
jdm
jethrogb
jkelleyrtp
jkordish
jkozlowski
JoeyEremondi
JoshMcguigan
jroesch
jrozner
JuanPotato
justahero
khaledkbadr
KiChjang
kiljacken
kjeremy
kleimkuhler
koute
kulshrax
kupiakos
leoyvens
lf
lilyball
listochkin
lloydmeta
Lubits
marcusklaas
memoryruins
Michael-F-Bryan
mikhail-m1
mitsuhiko
nbp
NikVolf
nox
orenwf
orium
pambihira
pepyakin
PramodBisht
rholderfield
ritiek
rolftimmermans
sanxiyn
sapphire-arches
soniasingla
stokhos
strega-nil
sunjay
tinaun
tomaka
totsteps
treiff
tynril
uberjay
vadimcn
Veetaha
wain303009
wirelessringo
xmonader
Xylakant
Yarn

Demoting x86_64-apple-darwin to Tier 2 with host tools

2025-08-19T00:00:00+00:00

In Rust 1.90.0, the target x86_64-apple-darwin will be demoted to Tier 2 with host tools. The standard library and the compiler will continue to be built and distributed, but automated tests of these components are no longer guaranteed to be run.

Background

Rust has supported macOS for a long time, with some amount of support dating back to Rust 0.1 and likely before that. During that time period, Apple has changed CPU architectures from x86 to x86_64 and now to Apple silicon, ultimately announcing the end of support for the x86_64 architecture.

Similarly, GitHub has announced that they will no longer provide free macOS x86_64 runners for public repositories. The Rust Project uses these runners to execute automated tests for the x86_64-apple-darwin target. Since the target tier policy requires that Tier 1 platforms must run tests in CI, the x86_64-apple-darwin target must be demoted to Tier 2.

What changes?

Starting with Rust 1.90.0, x86_64-apple-darwin will be Tier 2 with host tools. For users, nothing will change immediately; builds of both the standard library and the compiler will still be distributed by the Rust Project for use via rustup or alternative installation methods.

Over time, this target will likely accumulate bugs faster due to reduced testing.

Future

If the x86_64-apple-darwin target causes concrete problems, it may be demoted further. No plans for further demotion have been made yet.

For more details on the motivation of the demotion, see RFC 3841.

Posts tagged "infrastructure" | Rust Blog

Infrastructure Team 2026 Q3 Recap and Q4 Plan

Q3 2026 Accomplishments

Audit logs in Datadog Cloud SIEM

Web Application Firewall and DDoS protection for crates.io and docs.rs

CDN improvements for crates.io and docs.rs

New message queue between crates.io and docs.rs

Renovate for the rust repository

GitHub security alerts

More settings configured in the team repo

Hardware security keys

GitHub Actions audits

Improving user experience of reviewers

Trusted contributors

More powerful dev desktops and Rust Playground

ARM machine for rustc-perf

New CI runners

riscv64gc-unknown-linux-musl promoted to tier 2 with host tools

On-call rotation moved to Datadog

Team leader rotation

Main branch

Trusted publishing

Triagebot Assign-priority command

Q4 2026 Plans

Finish Q3 goals

Secure deployments

Decommission the monitoring instance

Join us

Infrastructure Team 2026 Q2 Recap and Q3 Plan

Q2 2026 Accomplishments

GitHub Rulesets are now the default protections

GitHub apps are now enabled through team

Shared Renovate Presets

Code security for rust-lang repositories

New GitHub Actions runners powered by external hardware

Experiments with macos-26 on CI

CI dashboard available again

Hardware Security Keys for critical infrastructure access

Partnership with Canonical and Ubuntu Pro for EC2 instances

Faster mergeability checks in Bors

Add the concept of community reviews before PR assignment

Reintroduce delegation approval for merge queue repositories

Continue supporting the moderation team with locking/unlocking of issues

Quality of life improvements in our range-diff viewer for GitHub PRs

Filtering of context-only hunks

Commit messages diff

Warning against Unicode Bidi characters

Small tweaks to the triagebot

Q3 2026 Plans

Finish leftover work from Q2

Improve GitHub Actions security

Move mailing lists from Mailgun to Google Groups to reduce spam

Consolidate logs on Datadog

Reduce reliance on external resources in CI

Stricter networking access rules for crater agents

Start planning for GitHub REST API upgrade

Join us

Infrastructure Team 2026 Q1 Recap and Q2 Plan

Q1 Accomplishments

Move to GitHub Rulesets

Improved CI security

Two new dev desktops

Bigger docs.rs instance

Improved access controls for Rust infrastructure with SAML SSO

Triagebot enhancements

GitHub issue comments viewer

Organization-wide default configuration

user-info command

Per-team rotation mode

Per-repository review preferences

Report banned users to moderator stream on Zulip

Clippy's Zulip lint nomination topic

New Zulip commands to handle backports and assign priority to issues

Q2 Plans

Finish Q1 goals

Improve CI security and developer experience

Hardware security keys for critical infrastructure access

Join us!

Infrastructure Team 2025 Q4 Recap and Q1 2026 Plan

Q4 2025 Accomplishments

Renovate for the `rust` repository

More settings configured in the `team` repo

`riscv64gc-unknown-linux-musl` promoted to tier 2 with host tools

`user-info` command

More settings configured in the `team` repo

New Triagebot commands: `r? me` and `@rustbot reroll`

`[no-mentions]` handler removed from Triagebot

Triagebot `[mentions]` now supports glob patterns

`rust-lang.org` is now a static website