crates.io: a release profile at optimisation level 2 and a sample session key in the repo

A SvelteKit frontend over an axum and diesel backend

The registry is a web application, and the stack is stated in one paragraph of the contributing section. The backend services are written in Rust, using the `axum` web framework and `diesel` for database access, plus a background worker system the project built itself rather than taking off the shelf, kept in its own crate. The frontend is a SvelteKit application written in TypeScript. The root package is named `crates_io` with the description "Backend of crates.io", on edition 2024, with `default-run` pointing at a `crates-io` binary. So a checkout contains at least three deployable pieces rather than one: the API and its worker in Rust, the site in TypeScript, and whatever the build pipeline glues together.

Release builds are compiled at optimisation level 2

The release profile in the manifest is not the default one:

[profile.release]
opt-level = 2

Rust's default for release is optimisation level 3, so this is a deliberate step down, and the manifest gives no reason for it. The development profile is where the reasoning is visible instead. Seven dependencies are pinned to `opt-level = 3` in the dev profile, `block-buffer`, `crypto-common`, `digest`, `generic-array`, `hmac`, `postgres-protocol` and `sha2`, with a comment explaining that this improves the speed of database connection setup in the test suite by building the crypto crates with optimisations even in debug. Two more, `insta` and `similar`, are pinned for the snapshot and diff testing libraries. So the project spends optimisation where tests are slow and takes it away where production throughput is what matters, which is a reasonable trade that a reader can only make because both halves are written down.

The sample environment file ships a session key in plain text

`.env.sample` is the local development recipe, and it is unusually candid. The session signing key example is a literal 32 character string, `badkey` followed by the alphabet, under a comment that says it must be at least 32 bytes and must be changed to a long random string for production. Anyone copying the file without changing that line runs a local instance with a publicly known cookie key, and the file makes the exact string visible rather than describing it. Other entries explain themselves in the same way: `WEB_ALLOWED_ORIGINS` lists two local ports for browser access to authenticated endpoints, `TEST_DATABASE_URL` is expected to point at a second database so a test run cannot truncate your working data, and `POSTGRES_BIN_DIR` exists for the database-dump job when the local `pg_dump` is a different major version from the server.

Edition 2024 code still runs 2018 and 2021 compatibility lints

The workspace lint table is comprehensive and slightly contradictory. The rustc side warns on `future_incompatible`, `nonstandard_style`, `rust_2018_idioms`, `unused`, and also `rust_2018_compatibility` and `rust_2021_compatibility`, which are the migration lints for editions two and one behind the crate's declared edition 2024. rustdoc allows `private_intra_doc_links` and warns on `unescaped_backticks`. Clippy warns on `dbg_macro`, `todo` and `too_long_first_doc_paragraph`, and allows exactly two rules with reasons written inline: `obfuscated_if_else`, because the `then(...).unwrap_or_default()` form is more compact than the `if`/`else` rustfmt produces, and `redundant_field_names`, recorded as a false positive in derive macros with a link to the clippy issue. Every crate opts in through `lints.workspace = true`, so nothing can quietly skip the table.

The browserslist ends with last 1 years and the author is empty

The root `package.json` is marked `private` with version `0.0.0`, which is correct for an application rather than a library, and it carries the same dual licence as the Rust side as `(MIT OR Apache-2.0)`. The `author` field is an empty string. Its `build` script does nothing at all, printing a note that it is a no-op kept for the `heroku-buildpack-crates-io` build step, which is the clearest evidence in the repository that this is still deployed somewhere that expects a Heroku style build hook. The scripts that do something are `lint:js` with eslint and a cache, prettier check and write, and one end-to-end run scoped to the Svelte app with `TEST_APP=svelte playwright test`. The `browserslist` array ends with an entry reading `last 1 years`, which is not a valid browserslist query, so the last entry does nothing.

Three crates pinned with an equals sign and one ignore list twice

Almost every dependency in the manifest is a caret requirement, which makes the two that are not stand out. `anyhow` is `=1.0.104` and `astral-tokio-tar` is `=0.7.0` with default features off, so an exact version is required for both and a patch release will not be picked up. `astral-tokio-tar` also appears in both the package metadata and the workspace metadata as the single entry ignored by `cargo-machete`, the tool that reports unused dependencies, so the same exemption is declared in two places where one would do. Everything else is versioned normally, and the frontend side is a pnpm workspace with a separate lock file, `pnpm-workspace.yaml`, alongside `packages/` and `svelte/`. So the repository carries two lock files and two toolchains, which is what a Rust and TypeScript service in one repository looks like in practice.

A triage bot, a blame ignore file, and a licence policy checker

Several root files exist to keep a large history navigable. `triagebot.toml` configures an automated issue triage bot, `.git-blame-ignore-revs` lists commits to exclude from blame so a repository-wide reformat does not own every line, and `deny.toml` is a `cargo-deny` configuration, which is how the licence and advisory policy of the dependency tree is enforced rather than hoped for. There is a `diesel-guard.toml` alongside `diesel.toml` for query checking and a `clippy.toml` for lint configuration. Deployment and tooling files sit next to them: a `Procfile`, an `Aptfile`, a `.buildpacks` directory, a `Justfile` for task running, `mise.toml` for tool versions and `rust-toolchain.toml` for the compiler. Testing spans `playwright.config.ts`, an `e2e/` directory, a `patches/` directory and `script/`, and an `.devcontainer/` sits alongside.

Editorial conclusion

Work on crates.io through the contribution guidelines and the agent documentation rather than by reading the README, which is a signpost, and start from the sample environment file, which is where the real dependency list lives: a Postgres database, a second database for tests, allowed origins and a session key. If you run a local instance, change that session key before anything else, since the file hands you a working default. When you contribute Rust, expect the lint table to be enforced across every crate, including migration lints for editions the code no longer targets. And if you are only here to consume crates, none of this matters: what you install through cargo is the registry, not this repository.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. rust-lang/crates.io on GitHub