---
title: "The WASIX Registry"
description: "Most crates work with WASIX out of the box. For the ones that need WASIX-specific changes — the low-level stack around sockets, threads, and TLS (tokio, hyper, libc, ring, and friends) — we maintain forks and publish them to the WASIX registry, an overlay registry at https://cargo-registry.wasix.org/."
url: "https://wasix.org/docs/language-guide/rust/patched-repos/"
markdown: "https://wasix.org/docs/language-guide/rust/patched-repos.md"
---

# The WASIX Registry

Most crates work with WASIX out of the box. For the ones that need WASIX-specific changes — the low-level stack around sockets, threads, and TLS (`tokio`, `hyper`, `libc`, `ring`, and friends) — we maintain forks and publish them to the **WASIX registry**, an overlay registry at `https://cargo-registry.wasix.org/`.

The overlay serves WASIX crate forks from its own storage and transparently redirects every other request to crates.io. In practice that means:

- Where a WASIX fork exists, cargo resolves it automatically — fork versions look like `1.47.0+wasix.1` (the upstream version plus a `+wasix.N` build suffix, which is ignored by semver requirements, so `tokio = "1.47"` just works).
- Everything else comes straight from crates.io, downloaded directly from crates.io’s own CDN.
- Forks apply **transitively**: a fork’s dependencies resolve through the overlay too, so you get the whole patched stack (e.g. `reqwest` pulls the WASIX TLS stack) without naming a single fork yourself.

No `[patch.crates-io]` sections, no git URLs, no version pinning.

## Enabling the registry

`cargo wasix` configures the registry for you: every build-like command (`build`, `check`, `run`, `test`, `bench`, `tree`, `fix`) writes the required [source replacement ](https://doc.rust-lang.org/cargo/reference/source-replacement.html) config into your workspace’s `.cargo/config.toml` if it isn’t there yet. To set up (or verify) a project explicitly — for example right after creating it — run:

```shell
$ cargo wasix init
```

Either way, the resulting config is two stanzas:

File: `.cargo/config.toml`

```toml
[source.crates-io]
replace-with = "wasix"

[source.wasix]
registry = "sparse+https://cargo-registry.wasix.org/"
```

The config writer is careful with existing files: it only adds missing keys, preserves everything else (comments included), and never overrides a crates-io replacement you’ve already set up yourself.

> ℹ️
>
> Commit `.cargo/config.toml` to your project. A `Cargo.lock` produced through the overlay pins `+wasix.N` versions that only exist there, so builds without the config fail with “no matching package” — committing the config keeps every checkout and CI run consistent.

## Opting out

Set `CARGO_WASIX_NO_REGISTRY_CONFIG=1` to stop `cargo wasix` from writing the config automatically (an explicit `cargo wasix init` still works). This is for the rare project that deliberately must not resolve through the WASIX registry.

## Fork sources

The forks themselves live on GitHub under [wasix-org ](https://github.com/wasix-org) — that’s where to file issues or contribute WASIX support for a crate. Once a fork is published to the registry, consumers pick it up with a plain version requirement; there is no list to keep in sync.

> 💡
>
> Missing a fork for a crate that doesn’t build on WASIX? Open an issue on [wasix-org ](https://github.com/wasix-org) or the crate’s fork repository.

---

[Documentation index](https://wasix.org/llms.txt) · [HTML version](https://wasix.org/docs/language-guide/rust/patched-repos/)