- Category
- Developer Tools
- Rank
- No. 1844Tools index
Previous survey · No. 1852 ·
- Pricing
- Open Source
- Type
- TOOL
- Builder
- builders-garden
- Date
About
A Rust reverse proxy that turns any backend into a paid API powered by x402, rate limiting, and async job queues.
What it does
Servex sits in front of one or more services and applies commercial and operational policy before forwarding requests. YAML defines routes, prices, payment networks, limits, timeouts, and background work. Clients can discover configured paid endpoints, submit payment proofs, and poll queued jobs. Backends receive signed requests and return synchronous responses or callback results.
Why it's ranked here
Servex combines several pieces that usually require separate gateway work: payment challenges, proof validation, tenant routing, signed backend traffic, discovery metadata, throttling, and job status handling. The design is concrete and configurable. However, its production-ready label deserves caution because rate-limit inspection remains unfinished and admin access becomes unrestricted when no key is configured.
What's good
Configuration validation catches duplicate services and subdomains, malformed wallet addresses, missing payment networks, empty endpoints, and invalid rate-limit syntax before serving traffic. HMAC signatures cover timestamp, method, path, and body, with freshness checks and constant-time comparison. Paid endpoints can register discovery metadata automatically, while registration failure does not stop the server.
Tradeoffs
Running Servex requires Redis, PostgreSQL, and an x402 facilitator in addition to the backend itself. Backends must verify signatures and implement callbacks for asynchronous work. Multiple services require host-based routing. The admin API has no authentication when its key is absent, and its rate-limit listing endpoint returns a placeholder instead of inspecting Redis.
How to use it well
Use Servex when an existing HTTP service needs per-route USDC charging, tenant routing, request signing, throttling, or polling for long tasks. Start with a test network, define strict service secrets and an admin key, then add discovery metadata selectively. It does not replace backend business logic, callback processing, Redis, PostgreSQL, or operational monitoring.
Technical notes+
Cargo.toml defines an MIT-licensed Rust package using Edition 2024, Tokio, Axum, reqwest, deadpool-redis, sqlx, and several x402 crates pulled directly from a Git repository without a tag or revision. src/lib.rs exposes Config, build_router, and AppState as a library surface. src/main.rs loads configuration, connects to Redis and PostgreSQL, runs migrations, builds the router, starts Axum, and spawns Bazaar registration without blocking startup. src/config/mod.rs applies environment overrides and validates service, wallet, endpoint, payment, and rate-limit settings. src/proxy/hmac.rs signs timestamp, method, path, and body with HMAC-SHA256 and checks freshness. src/jobs/queue.rs stores and queues jobs through RedisStorage. src/admin/api.rs exposes job and rate-limit management, allows unauthenticated admin requests when SERVEX_ADMIN_KEY is unset, and leaves rate-limit inspection as a placeholder.
Observed
- License
- MIT
- Primary language
- Rust
- Packaging
- Cargo package, built and run from source with Cargo
- Interfaces
- HTTP reverse proxy, admin HTTP API, and exported Rust library surface
- Required services
- Redis, PostgreSQL, and an x402 facilitator
- Payment networks
- Base, Base Sepolia, Ethereum, and Polygon using USDC
- Configuration
- YAML configuration with environment-variable overrides
- Frameworks
- Tokio async runtime and Axum web framework
Read from README.md, Cargo.toml, src/lib.rs, src/main.rs, src/jobs/mod.rs, src/x402/mod.rs, src/admin/mod.rs, src/proxy/mod.rs, src/admin/api.rs, src/config/mod.rs, src/server/mod.rs, src/jobs/queue.rs, src/proxy/hmac.rs, src/routing/mod.rs, src/storage/mod.rs.
What it can do
Convert free backend API into paid API
Existing backend service → Monetized API with payment requirements
Process payments using x402 protocol
API requests with payment headers → Payment verification and API access authorization
Apply rate limiting to API endpoints
API requests from clients → Controlled request flow with rate limit enforcement
Proxy requests to backend services
Client HTTP requests → Forwarded requests to target backend with response routing
Queue API requests asynchronously
Incoming API requests → Queued jobs for processing with async execution
Manage API access control
Client requests with authentication data → Authorized or denied API access based on payment status
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.