Most infrastructure teams do not pay for a web server in isolation. They pay for everything accumulated around it: excess compute reserved for peak traffic, separate security services, telemetry agents, configuration automation, and the engineering time required to keep those pieces consistent.
That makes the web server an infrastructure cost decision. A faster binary is useful. A smaller, more controllable production system is the real business outcome.
Throughput matters when it changes the capacity plan
Webship is built in Rust for high-load static delivery and reverse proxying across HTTP/1.1, HTTP/2, and HTTP/3. In the current verified Debian direct-serving matrix, four Webship workers sustained a median 1,041,848 requests per second over h2c and 307,727 encrypted requests per second over HTTP/3.
A separate, contemporaneous same-host comparison provides the competitor context. In that run, Webship delivered 1,015,870 requests per second over h2c versus 192,324 for Nginx. Over HTTP/3 TLS, Webship delivered 317,138 requests per second versus 35,207 for Envoy. Every published result is the median of five accepted samples with isolated CPU sets and zero-error correctness gates.
These measurements are evidence, not a universal capacity promise. Application behavior, response size, TLS configuration, cache hit rate, network conditions, and upstream latency will change the result. The responsible question is not whether a headline number transfers unchanged. It is whether Webship lets your workload meet its service objectives with fewer nodes or more headroom per node.
Review the complete methodology and every competitor result on the Webship benchmark page.
Consolidation is where the economics become real
A conventional edge can involve a web server, reverse proxy, TLS terminator, cache, WAF, rate limiter, metrics endpoint, and a separate operational API. Each component can be excellent, yet the combined system creates more configuration surfaces, network transitions, upgrades, failure modes, and invoices.
Webship brings static files, application proxying, TLS 1.3, HTTP/3, WebTransport, caching, WAF, DDoS controls, API Shield, response security headers, observability, and operational control into one deployable binary.
For workloads that fit that boundary, consolidation can reduce more than CPU demand. It can reduce the number of services an engineer must provision, monitor, secure, and reconcile during an incident. Webship does not claim to replace a global CDN, upstream scrubbing network, or every specialist security product. It gives teams a strong self-hosted baseline before another service becomes necessary.
AI-native should mean controlled operations
Adding a chat interface to infrastructure is not operational automation. An AI-native web server needs a bounded control surface, explicit policy, validation, auditability, and rollback.
Webship exposes authenticated Model Context Protocol operations for reading and validating configuration, explaining request policy, comparing shadow changes, running traffic scenarios, inspecting bounded diagnostics, managing cache entries, checking TLS state, and applying or rolling back approved runtime-safe changes.
The control listener is isolated from the public traffic path and should remain on loopback or a private network behind TLS and a strong bearer token. Runtime-safe patches can be applied without interrupting traffic. Listener, TLS, and authentication changes still require a deliberate restart. That distinction keeps automation useful without pretending every production change is risk-free.
See the AI agent quick start for the operating model.
Security belongs in the first configuration
Webship starts with a security baseline: WAF inspection, per-client DDoS controls, bot challenge, API endpoint and content-type validation, response security headers, and dot-file protection. The controls run in the data plane instead of adding another default network hop.
Built in does not mean finished. Operators still own firewall policy, secrets, origin security, updates, application security, and workload-specific rule tuning. The advantage is that the first deployment already has a coherent place to enforce and inspect those decisions.
Build the business case on your own traffic
A credible evaluation should answer four questions:
- Does Webship preserve request correctness across your static, proxy, WebSocket, and modern protocol paths?
- What happens to sustained throughput, tail latency, CPU, and memory under representative traffic?
- How many edge components can be consolidated without losing a capability your team depends on?
- Can operators and AI agents diagnose, validate, change, and roll back policy within your security model?
Run Webship beside the existing edge, replay production-like traffic, and keep the old listener available for rollback. Convert measured sustainable throughput into a node-count model, then add the operational cost of every component that remains. That produces a defensible infrastructure decision instead of a benchmark-driven guess.
Webship offers a 14-day evaluation path for teams that want to test the economics before committing. Start with the documentation, select a signed build from downloads, and measure it against the system you operate today.