GO — Healthy across all four use cases

• Last commit 1d ago
• 4 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 95% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Salvo is a production-ready async Rust web framework built on Hyper and Tokio that emphasizes minimal boilerplate and powerful features. It provides first-class support for HTTP/1, HTTP/2, HTTP/3, WebSocket, automatic TLS via ACME, and OpenAPI documentation generation—enabling developers to write web handlers as simple async functions with the #[handler] macro. Monorepo with workspace at root: crates/core/ contains the HTTP engine (Hyper-based), crates/macros/ provides the #[handler] and #[oapi] derive macros, crates/oapi/ handles OpenAPI/Swagger generation, and optional crates like crates/cache/ (Moka-backed), crates/compression/, crates/acme/, and crates/jwt-auth/ provide composable middleware. Main exports via salvo metapkg.

Rust backend developers and systems engineers building high-performance web services who want a modern async framework with less ceremony than Actix-web or Axum, and need built-in OpenAPI, ACME, and HTTP/3 support without external configuration.

Actively developed and production-ready. The project uses semver (v0.93.0 currently), has comprehensive CI across Linux/macOS/Windows, enforces test coverage via codecov, and requires Rust 1.92+. The monorepo structure with multiple stable crates and recent dependency updates indicate active maintenance, though the 0.x version suggests the API may still evolve between minor releases.

Low risk for production use but moderate API stability concern: the 0.x versioning allows breaking changes in minor versions, and the codebase is ~2.8MB of Rust across many optional feature crates. Single-maintainer risk is present (primary author listed as 'chrislearn'), but the GitHub Actions CI/CD is robust and the 'unsafe forbidden' badge indicates careful memory safety practices.

Active development on v0.93.0 with focus on HTTP/3 support (via salvo-http3 wrapper around external crate), compression middleware enhancement, cache integration, and OpenAPI tooling. CI workflows for coverage, formatting, fuzzing, and multi-platform releases are operational. The CHANGELOG.md and dependabot.yml indicate regular dependency maintenance.

Clone and build locally:

git clone https://github.com/salvo-rs/salvo.git
cd salvo
cargo build --workspace
cargo test --workspace

To run examples: cargo run --example basic (examples are in examples/ of individual crates).

Daily commands: No single 'dev server' — Salvo is a library. To test the framework itself:

cargo test --workspace
cargo build --all-features

To run examples from the quick-start guide (create a binary in your own project):

cargo new my-app
cd my-app
cargo add salvo tokio --features salvo/oapi,tokio/macros
cat > src/main.rs << 'EOF'
use salvo::prelude::*;
#[handler]
async fn hello() -> &'static str { "Hello World" }
#[tokio::main]
async fn main() {
  let router = Router::new().get(hello);
  let listener = TcpListener::new("127.0.0.1:7878").bind().await;
  Server::new(listener).serve(router).await;
}
EOF
cargo run

• crates/core/src/handler.rs — Core handler abstraction that defines how requests are processed; foundational to all request routing and middleware
• crates/core/src/http.rs — HTTP request/response types and abstractions; critical for understanding the framework's HTTP contract
• crates/core/src/cfg.rs — Server configuration and setup entry point; essential for understanding application lifecycle
• crates/core/src/extract.rs — Request parameter extraction and deserialization; key to understanding data binding patterns
• crates/core/src/router.rs — Router implementation and request matching; critical routing abstraction (inferred from structure)
• Cargo.toml — Workspace definition with version alignment and dependency management across all crates

Add a new HTTP endpoint (route + handler)

1. Create a handler function that accepts request parameters via the Extractor trait (query, path, body, headers) (crates/core/src/handler.rs)
2. Register the handler with the router using .get(), .post(), etc. methods (typically in main or config setup) (crates/core/src/cfg.rs)
3. Use the Extractor derive macro on a struct to automatically deserialize request data (query params, JSON body, form data) (crates/core/src/extract.rs)
4. Return a response type implementing the Writer trait (e.g., JSON, custom response body) to serialize the response (crates/core/src/http/body/res.rs)

Add middleware or request filtering

1. Implement a handler that wraps another handler using the fuse abstraction (before/after processing) (crates/core/src/fuse.rs)
2. Use the before() and after() methods to inject logic before request processing or after response generation (crates/core/src/fuse/flex.rs)
3. Register middleware globally on the router or per-route for targeted application (crates/core/src/cfg.rs)

Enable compression for responses

1. Add the compression crate to Cargo.toml as a feature dependency (Cargo.toml)
2. Initialize the compression middleware in the router setup with desired encoders (gzip, deflate, brotli, zstd) (crates/compression/src/lib.rs)
3. Responses are automatically compressed based on Accept-Encoding headers; no additional code needed in handlers (crates/compression/src/encoder.rs)

Add TLS/HTTPS support

1. Choose a TLS backend (rustls, native_tls, or openssl) and enable the corresponding feature (crates/core/src/conn/rustls.rs)
2. Load certificates and keys into a listener configuration struct (crates/core/src/conn/rustls/config.rs)
3. Pass the configured listener to the server during startup (crates/core/src/cfg.rs)
4. For automatic certificate provisioning, enable the acme feature and configure Let's Encrypt integration (crates/acme/src/listener.rs)

• Tokio async runtime — High-performance, non-blocking I/O for handling thousands of concurrent connections with minimal overhead
• Trait-based handler abstraction (Handler trait) — Enables pluggable request processing; supports both functions and complex middleware chains with type safety
• Derive macros for extraction (salvo_macros) — Zero-cost abstraction for automatic parameter binding; reduces boilerplate while maintaining compile-time safety
• Rustls/native_tls/OpenSSL/Quinn pluggable TLS — Multiple TLS backends allow users to choose between pure-Rust (rustls), system-native (native_tls), or advanced features (OpenSSL, QUIC)
• Moka in-memory caching layer — Concurrent, thread-safe caching with optional TTL and invalidation; reduces load on downstream services

• Simplified router abstraction vs. advanced regex/Trie routing

  • Why: Salvo prioritizes ease of use and predictability over maximum routing performance; most applications won't hit routing bottlenecks
  • Consequence: Slightly higher per-request routing overhead than highly-optimized frameworks; excellent for 95% of web apps

• Pluggable TLS backends (rustls/native_tls/OpenSSL) vs. single backend

  • Why: Flexibility for different security policies, compliance requirements, and deployment environments
  • Consequence: More code paths to maintain; feature flags add compile complexity; users must choose correct backend for their use case

• Request-scoped Depot for arbitrary data vs. typed context

  • Why: Simpler, more flexible API; avoids generic type explosion in middleware
  • Consequence: Type safety is deferred to runtime; potential for key collisions if developers aren't careful; less IDE autocomplete support

• Modular crates (compression, cache, acme) vs. monolithic core

  • Why: Reduces binary size for applications that don't
  • Consequence: undefined

Feature flags: Many crates have optional features (e.g., salvo/oapi, salvo/acme). Build without defaults to avoid surprise dependencies. Edition 2024: The workspace uses edition = "2024" (unstable), which may require a nightly Rust toolchain for local development despite the MSRV being 1.92. QUIC/HTTP3: Requires system QUIC libraries (BoringSSL or OpenSSL + quiche); may fail to build on some platforms. TLS certificates: Test certs are in crates/core/certs/ and are regenerated via the shell script — stale certs will cause TLS tests to fail. Workspace members: Always run cargo X --workspace or specify -p <crate> to avoid testing only the root package.

• Handler trait & macro-based routing — The #[handler] macro is Salvo's signature abstraction — it converts plain async functions into middleware-compatible handlers. Understanding how the macro desugars function parameters (e.g., &mut Request) into extractors is critical to writing custom handlers.
• HTTP/3 and QUIC — Salvo explicitly supports HTTP/3 via the QUIC protocol (wrapped in salvo-http3). This is non-trivial compared to HTTP/2 and requires understanding connection multiplexing over UDP and stream prioritization, crucial for high-performance APIs.
• ACME (Automatic Certificate Management Environment) — The crates/acme/ crate provides automatic TLS certificate provisioning and renewal via Let's Encrypt. Understanding ACME challenges, renewal hooks, and certificate storage is essential for deploying Salvo with zero-touch HTTPS.
• OpenAPI 3.0 code generation from annotations — Salvo's #[oapi] macros in crates/oapi-macros/ allow declarative API documentation. Understanding how derive macros extract type information and generate JSON schemas is key to leveraging auto-generated Swagger/ReDoc UI.
• Tree-based routing with middleware composition — Salvo uses a tree (trie-like) router structure where middleware can be attached at any node, not just globally. This allows fine-grained request filtering and is more flexible than flat routing; understanding Router::nest() and middleware order is crucial.
• Hyper's HttpService and Listener abstractions — Salvo abstracts server configuration via Listener traits (TcpListener, UnixListener, etc.) and the HttpService trait. This allows swapping transports without changing handler code, important for testing and alternative deployment scenarios.
• Compression middleware with streaming — crates/compression/ provides on-the-fly gzip/brotli encoding with streaming support (not buffering entire responses). Understanding encoder/decoder traits and chunked transfer encoding is essential for efficient content delivery.

• tokio-rs/axum — Direct competitor: also a Tokio-based Rust web framework, but more minimalist; compare routing, middleware, and API design philosophy.
• actix/actix-web — Alternative production Rust web framework with similar feature set (WebSocket, middleware, TLS); understanding tradeoffs (Actix uses its own executor vs. Tokio) is valuable.
• hyperium/hyper — Direct dependency: Salvo is built on Hyper; understanding the underlying HTTP primitives (Request, Response, Body) helps debug networking issues.
• tokio-rs/tokio — Foundational dependency: all async I/O in Salvo runs on Tokio; essential knowledge for understanding concurrency and performance tuning.
• salvo-rs/salvo-examples — Official examples repository (if it exists separately) or mirror — would contain runnable demos of each Salvo feature integration.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for TLS/HTTPS listeners across all protocols

The repo has multiple TLS implementations (native_tls, openssl, quinn for QUIC/HTTP3) in crates/core/src/conn/ but no dedicated integration tests validating that HTTPS works correctly across different TLS backends and protocol versions. This is critical for a web framework where security is paramount. Tests should verify certificate loading, handshake completion, and request handling for each TLS backend.

• [ ] Create crates/core/tests/tls_integration_tests.rs with test cases for native_tls listener
• [ ] Add similar test cases for openssl listener in the same file
• [ ] Add test cases for quinn/HTTP3 HTTPS in crates/http3/tests/ (if exists) or create it
• [ ] Verify tests use the existing cert.pem/key.pem in crates/core/certs/
• [ ] Run tests across linux.yml, macos.yml, and windows.yml GitHub Actions workflows to ensure cross-platform compatibility

Add missing README documentation for middleware crates (csrf, flash, jwt-auth, rate-limiter, proxy)

The workspace contains several middleware crates (crates/csrf, crates/flash, crates/jwt-auth, crates/rate-limiter, crates/proxy) listed in Cargo.toml dependencies but many are missing README.md files (visible in file structure: crates/cache/README.md and crates/compression/README.md exist, but not all others). New contributors cannot easily understand what these crates do or how to use them. Each README should include usage examples and API documentation.

• [ ] Create crates/csrf/README.md with CSRF protection usage examples and configuration options
• [ ] Create crates/flash/README.md documenting flash message pattern and session integration
• [ ] Create crates/jwt-auth/README.md with JWT validation, token creation, and middleware setup examples
• [ ] Create crates/rate-limiter/README.md with rate limiting strategies and configuration
• [ ] Create crates/proxy/README.md documenting reverse proxy capabilities and routing configuration
• [ ] Add cross-references in main README.md or ECOSYSTEM.md pointing to these new READMEs

Add unit tests for connection address parsing (crates/core/src/conn/addr.rs)

The crates/core/src/conn/addr.rs file handles network address parsing, which is fundamental to routing and request handling. Without dedicated unit tests, regressions in address parsing (IPv4, IPv6, socket addresses) could cause framework-wide issues. The existing test coverage for this module appears minimal based on the file structure.

• [ ] Create crates/core/tests/addr_parsing_tests.rs with comprehensive test cases
• [ ] Add test cases for parsing IPv4 addresses (127.0.0.1, 0.0.0.0, etc.)
• [ ] Add test cases for parsing IPv6 addresses ([::1], [::], [fe80::1], etc.)
• [ ] Add test cases for socket address construction with ports
• [ ] Add test cases for invalid address formats to ensure error handling
• [ ] Test any custom trait implementations on addr types (Display, Debug, Clone, etc.)

• Add examples/ directory with complete runnable examples for each major crate (compression, cache, acme, jwt-auth) — currently only referenced in READMEs but not present in the file list. This would lower the barrier for new users.
• Extend test coverage for error handling paths in crates/core/src/ — the CI has codecov enabled but no details on coverage gaps are visible; auditing panics and Result handling in the router and handler trait would improve robustness.
• Document the feature interaction matrix in CONTRIBUTING.md — there are many optional features across crates but no table showing which features require which dependencies or break compatibility; this would prevent misconfiguration by contributors.

The Salvo web framework demonstrates a solid security posture with established vulnerability reporting procedures, automated CI/CD pipelines, and multi-platform testing. The main concerns are minor: test certificates in the repository (mitigated if properly isolated), use of the very new Rust 2024 edition with potential ecosystem compatibility risks, and incomplete security policy documentation. The framework includes security-relevant features (HTTPS support via multiple TLS backends, CORS, JWT authentication, CSRF protection) and maintains active fuzz testing. No critical vulnerabilities were identified in the configuration, but continuous monitoring of dependency security and ecosystem support is recommended due to the cutting-edge edition choice.

• Medium · Test Certificates Stored in Repository — crates/core/certs/. The codebase contains test/development SSL certificates (cert.pem, key.pem, identity.p12, identity-legacy.p12) stored in the repository at crates/core/certs/. While these are marked as test certificates, storing any certificates in version control presents a risk if practices are not strictly followed. Fix: Ensure test certificates are clearly documented as test-only, consider moving them to a separate test-data repository, or use certificate generation scripts. Add .gitignore rules for any production certificates. Document the certificate generation process in crates/core/certs/generate.sh.
• Low · Edition 2024 May Have Limited Ecosystem Support — Cargo.toml (workspace.package). The Cargo.toml specifies edition = '2024', which is a very recent edition. While this enables new language features, it may have limited third-party crate support and compatibility issues with dependencies that target older editions. Fix: Monitor dependency compatibility and consider maintaining compatibility with edition 2021 until ecosystem maturity improves. Validate that all critical dependencies explicitly support edition 2024.
• Low · Security Policy Communication Channel — SECURITY.md. The SECURITY.md file specifies a single point of contact (chris@acroidea.com) for security reports. While this is correct, there is no backup contact or security@salvo.rs email alias mentioned, creating a single point of failure for critical security reports. Fix: Establish a security@salvo.rs email alias with multiple authorized recipients. Document the escalation process for when the primary contact is unavailable.
• Low · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears truncated (ends mid-sentence at 'public disclo'), and the full policy regarding embargo periods, CVE assignment, and post-fix disclosure timelines is not visible. Fix: Complete the SECURITY.md documentation to include: embargo periods, CVE assignment process, advisory timeline, and post-fix disclosure procedures. Consider adding security best practices for users of the framework.
• Low · Fuzz Testing Workflow Present — .github/workflows/fuzz.yml. While the fuzz testing workflow is present, there is no visible fuzzing configuration or corpus in the file structure provided. Fix: Ensure fuzzing is actively maintained with regular corpus updates and documented findings. Consider adding targets for critical components like connection handling, request parsing, and crypto operations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/salvo-rs/salvo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live salvo-rs/salvo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/salvo-rs/salvo.

What it runs against: a local clone of salvo-rs/salvo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in salvo-rs/salvo | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of salvo-rs/salvo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/salvo-rs/salvo.git
#   cd salvo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of salvo-rs/salvo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "salvo-rs/salvo(\\.git)?\\b" \\
  && ok "origin remote is salvo-rs/salvo" \\
  || miss "origin remote is not salvo-rs/salvo (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "crates/core/src/handler.rs" \\
  && ok "crates/core/src/handler.rs" \\
  || miss "missing critical file: crates/core/src/handler.rs"
test -f "crates/core/src/http.rs" \\
  && ok "crates/core/src/http.rs" \\
  || miss "missing critical file: crates/core/src/http.rs"
test -f "crates/core/src/cfg.rs" \\
  && ok "crates/core/src/cfg.rs" \\
  || miss "missing critical file: crates/core/src/cfg.rs"
test -f "crates/core/src/extract.rs" \\
  && ok "crates/core/src/extract.rs" \\
  || miss "missing critical file: crates/core/src/extract.rs"
test -f "crates/core/src/router.rs" \\
  && ok "crates/core/src/router.rs" \\
  || miss "missing critical file: crates/core/src/router.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/salvo-rs/salvo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.