What this prompt does
This prompt builds a high-performance Rust web service on the Axum framework rather than a bare router. You set [service_purpose] and [database], and the AI scaffolds a router with typed extractors (Path, Query, Json, State), SQLx integration with compile-time query checking, and a tower middleware stack covering tracing, compression, CORS, timeout, and rate limiting. SQLx's compile-time checks are the standout feature: they catch broken queries at build time, so you can refactor aggressively without runtime surprises showing up in production.
The variables select the concrete pieces of the stack. [auth_method] sets the authentication approach via extractors, [tracing_backend] wires OpenTelemetry to a backend like Jaeger, and [test_strategy] drives integration tests against a real test database. The prompt also asks for custom IntoResponse error types with problem details so errors are consistent and safe, sqlx-cli migrations, graceful shutdown with tokio::signal, and a multi-stage Docker build using cargo-chef to cache dependencies, which makes CI dramatically faster on every single deploy.
When to use it
- Building a Rust backend that must be fast and genuinely hard to crash under load
- Wanting compile-time-checked SQL so query bugs surface at build, not at runtime
- Standing up a tower middleware stack with tracing, CORS, timeout, and rate limiting
- Adding OpenTelemetry tracing to a service from the very start rather than retrofitting
- Wiring database migrations and integration tests against a real test database
- Speeding up your CI pipeline with a cached cargo-chef multi-stage Docker build
Example output
You get a workspace-aware Cargo.toml, an Axum router using typed extractors, SQLx queries with compile-time checking against your schema, and the tower middleware layers configured in a sensible order. It includes auth extractors for [auth_method], custom error responses with problem details, sqlx-cli migrations, OpenTelemetry tracing to [tracing_backend], graceful shutdown, integration tests using your [test_strategy], a multi-stage cargo-chef Dockerfile, an .env.example, and deployment documentation. The error types implement IntoResponse with problem-details bodies, so failures return a consistent, machine-readable shape instead of inconsistent ad-hoc strings.
Pro tips
- Make
[service_purpose]concrete so the routes and schema reflect real endpoints rather than placeholders - Keep compile-time SQLx checking on; it is the main reason to pick this stack over a looser, runtime-checked one
- Match
[tracing_backend]to what you actually run in your environment; Jaeger is a solid default for local tracing - Use a real
[test_strategy]like testcontainers with transaction rollback so tests stay isolated and fast - Confirm the cargo-chef layer ordering in the Dockerfile; that ordering is exactly what makes dependency caching work
- Order the tower middleware deliberately, since timeout, rate limiting, and compression behave differently depending on their position in the stack
- Review the custom IntoResponse error types to ensure they never leak internal details back to clients
