Static Web Server

A cross-platform, async web server for static files, honestly reviewed. No marketing fluff — just what you get when you self-host it.

TL;DR

• What it is: A tiny, production-ready static file server written in Rust — Apache 2.0 licensed, single binary, cross-platform, and built for speed without the configuration weight of nginx or Apache [1][2].
• Who it’s for: Developers and ops-minded founders who want to serve a static site, SPA, or assets without installing a full web server stack. Also useful inside Docker containers where binary size and RAM overhead matter [1][2].
• Cost savings: Managed static hosting (Netlify, Vercel, Cloudflare Pages) is cheap or free at low scale but adds per-seat, per-build, or bandwidth costs at scale. SWS on a $5/mo VPS gives you unlimited bandwidth and full control [2].
• Key strength: Single 4MB static binary with no runtime dependencies. HTTP/2, TLS, Brotli/Zstd compression, virtual hosting, CORS, basic auth, URL rewrites — all baked in. Runs on Linux, macOS, Windows, FreeBSD, Android, and even WebAssembly via Wasmer [1][2].
• Key weakness: No dynamic content, no scripting, no plugin system. The feature set is deliberately narrow — it does one thing (static files) and stops there. For anything beyond serving files, you’ll need a reverse proxy in front of it [1].

---

What is Static Web Server

Static Web Server (abbreviated SWS) is a production-ready web server written in Rust, built exclusively for serving static files. It describes itself as “tiny and fast” and “focused on lightness and easy-to-use principles” — which is a rare case of software actually matching its own tagline [1][2].

It’s built on top of Hyper and Tokio, the same async runtime stack that powers a large chunk of Rust’s networking ecosystem. What that means in practice: concurrent, non-blocking request handling without the memory cost of thread-per-request architectures [1].

The project sits at 2,169 GitHub stars with an Apache-2.0 license — permissive, commercially safe, no “fair code” caveats [merged profile]. The single binary weighs 4MB uncompressed (statically linked against Musl libc on Linux), meaning you can drop it into a scratch Docker container with no dependencies and ship it anywhere [1].

Cross-platform is not marketing here: Linux, macOS, Windows, FreeBSD, NetBSD, Android (x86, ARM), and WebAssembly via Wasmer are all listed as supported targets with pre-compiled binaries available [2]. The Windows Service support is a detail that separates it from most Unix-first tools — it actually integrates with the Windows service manager [2].

The project also ships as a Rust library crate with opt-in features, meaning you can embed it in another Rust application rather than running it standalone [1].

---

Why people choose it

The third-party review landscape for SWS is thin — the tool occupies a functional rather than fashionable niche, and search results return almost nothing beyond the official documentation [primary sources only]. What the tool’s feature list and positioning tell you directly:

Against nginx. nginx is the default answer for static file serving, but its configuration DSL has a learning curve that’s punishing for non-specialists. A correctly secured nginx config for an SPA with proper cache headers, CORS, and HTTPS redirect involves at minimum a 30-50 line config file. SWS ships sane defaults for all of those — security headers for HTTP/2 are on by default, CORS has preflight support, HTTP-to-HTTPS redirect is a single flag [1][2]. For someone who just wants files served correctly without reading the nginx documentation on try_files, SWS is a faster path.

Against Caddy. Caddy is the modern alternative to nginx — automatic HTTPS via Let’s Encrypt, clean config format. But it’s a general-purpose reverse proxy with a plugin system and a larger footprint. SWS is smaller, more constrained, and arguably better suited for pure static serving inside containers where you already have TLS termination handled upstream by a load balancer or ingress controller [2].

Against serve (npm) and similar dev-server tools. The npm serve package and Python’s http.server are fine for local development but aren’t production candidates. SWS ships with Brotli and Zstd compression, proper cache-control headers, graceful shutdown, health check endpoints, and HTTP/2 support — features that matter when you’re serving real users, not localhost [1].

The Rust angle. The “memory-safe and significantly reduced CPU and RAM overhead” claim isn’t empty [1]. Rust’s ownership model eliminates entire classes of memory bugs at compile time. For a long-running server process, memory safety without garbage collection pauses is a real operational property, not a benchmark exercise.

---

Features

Based on the README and official documentation [1][2]:

Protocol and transport:

• HTTP/1 and HTTP/2 support
• TLS support (HTTPS)
• Built-in HTTP-to-HTTPS redirect
• HEAD and OPTIONS responses
• Partial Content Delivery (byte-serving for large files)

Compression:

• GZip, Deflate, Brotli, Zstandard (zstd) — text-based files only
• Compression on-demand via Accept-Encoding header negotiation
• Support for serving pre-compressed files directly from disk (avoids re-compressing on each request)

Caching and headers:

• Optional Cache-Control headers for assets
• Customizable HTTP response headers for specific file types via glob patterns
• Security headers for HTTP/2 by default

Routing and content:

• Custom URL rewrites and redirects via glob patterns with replacements
• Virtual hosting support (multiple domains per instance)
• Multiple index files
• Fallback pages for 404 errors — explicitly useful for SPAs that need to return index.html for all routes [2]
• Markdown content negotiation via Accept header for serving .md files
• Trailing slash redirect

Operations:

• Health check endpoint (GET/HEAD)
• Maintenance Mode functionality
• Graceful shutdown with configurable grace period
• Termination signal handling
• Configurable via CLI arguments, environment variables, or a TOML config file
• Default and custom error pages
• Directory listing with sorting and JSON output format support
• Lightweight logging via Rust’s tracing crate

Authentication:

• Basic HTTP Authentication

Security:

• CORS with preflight requests support
• Ability to disable symlinks

Platform integrations:

• First-class Docker support: Scratch, Alpine Linux, and Debian images
• Kubernetes-ready
• Windows Service support
• File descriptor socket passing for systemd integration and on-demand applications
• WebAssembly target via Wasmer

Deployment options:

• Single static binary (no runtime dependencies)
• Library crate with opt-in features for embedding in Rust applications
• Pre-compiled binaries for all major architectures

---

Pricing: SaaS vs self-hosted math

SWS is Apache 2.0 — free to use, fork, embed, and ship commercially with no fees [merged profile].

The cost comparison isn’t SWS vs. a paid competitor; it’s SWS vs. managed static hosting services:

Netlify:

• Free: 100GB bandwidth/mo, 300 build minutes
• Pro: $19/mo per member, 1TB bandwidth, 25,000 build minutes
• Business: $99/mo per member

Vercel:

• Hobby: free with soft bandwidth limits (100GB)
• Pro: $20/mo per member
• Enterprise: custom pricing

Cloudflare Pages:

• Free tier is genuinely generous (unlimited bandwidth on Cloudflare’s network)
• Paid plans add CI/CD concurrency, team seats

S3 + CloudFront (AWS):

• S3: ~$0.023/GB storage + $0.09/GB transfer
• CloudFront: $0.0085/GB for first 10TB/month
• At 1TB/month transfer: roughly $90-100/mo depending on region

SWS self-hosted:

• Software: $0 (Apache 2.0)
• VPS on Hetzner (2GB RAM, 40GB SSD): ~$4.51/mo
• Bandwidth: typically unmetered or very generous (Hetzner gives 20TB/mo at that tier)
• Your time: one-time setup ~30 minutes if you know what you’re doing

For a founder serving a static marketing site or docs portal, the Netlify Pro bill at $19+/mo per team member adds up fast. SWS on a small VPS with a Caddy reverse proxy handling HTTPS is under $5/mo with no per-seat pricing and no build minute caps.

The math is clear for high-bandwidth use cases (large media files, asset CDN replacement). For ultra-low-traffic sites where Netlify’s free tier fits, the calculus is different — managed hosting removes operational overhead, and free is hard to beat.

---

Deployment reality check

The install path is straightforward for someone comfortable with Linux:

Option 1 — Binary: Download the pre-compiled binary for your platform from GitHub releases, make it executable, point it at a directory, run it. The --port, --root, --tls-cert, and --tls-key flags cover the most common cases without touching a config file [1][2].

Option 2 — Docker:

docker run -d -p 8080:80 -v /my/files:/public joseluisq/static-web-server:2

The Scratch image is genuinely minimal — nothing in the container except the binary and your files [1].

Option 3 — TOML config: For more complex setups (virtual hosting, custom headers per path, URL rewrites), the TOML config file is clean and well-documented [2].

What you actually need for a production setup:

• A Linux VPS (1GB RAM is sufficient; SWS is memory-efficient)
• A reverse proxy in front for HTTPS if you’re not using SWS’s built-in TLS (Caddy makes this trivial)
• OR configure SWS’s built-in TLS directly with a cert from Let’s Encrypt
• A domain pointing at your VPS

What can go sideways:

• SWS handles static files — it has no concept of server-side rendering, API proxying, or dynamic content. If your “static site” actually needs any runtime logic, you’ll need a separate process and a proper reverse proxy routing between them.
• The metrics feature is listed in the canonical features [merged profile], but the documentation depth on Prometheus integration isn’t obvious from the homepage — worth checking the docs before assuming it drops into your observability stack cleanly [2].
• 2,169 GitHub stars puts this in “actively maintained but not dominant” territory. nginx has decades of production hardening and a massive knowledge base. If something breaks on SWS in an unusual configuration, you’re working from documentation and source code rather than a decade of Stack Overflow answers.
• No SSO, no web UI, no management console. Configuration is files and flags only. That’s the right call for a lean server, but it means there’s no dashboard to hand to a non-technical team member.

Realistic setup time: 15–30 minutes for a technical user deploying a static site. For a non-technical founder following a guide: budget 2–4 hours including domain setup, SSL cert, and reverse proxy configuration.

---

Pros and Cons

Pros

• Genuinely tiny footprint. 4MB static binary, no runtime dependencies, runs in a scratch container [1]. If you care about image size and RAM overhead in production containers, this is a real advantage.
• Apache 2.0 license. Commercially permissive — embed it in your product, ship it to clients, use it in internal tooling without license concerns [merged profile].
• Baked-in features that nginx needs plugins for. Brotli compression, Zstd compression, pre-compressed file serving, virtual hosting, URL rewrites, maintenance mode — all in one binary with no module installation [1][2].
• Cross-platform with real Windows support. Windows Service integration isn’t an afterthought [2]. Most Unix-first tools treat Windows as a second-class citizen.
• SPA-ready out of the box. The 404 fallback to index.html is a named feature, not a workaround [2]. This is the most common static hosting requirement for modern frontend frameworks.
• Configurable three ways. CLI flags, environment variables, or TOML file [1]. This is the right API for a server tool — works in Docker Compose, Kubernetes pods, shell scripts, and config management equally well.
• Library crate option. If you’re building a Rust application that needs to serve static assets, you can embed SWS instead of running a separate process [1].
• Markdown content negotiation. Niche but genuinely useful: serve .md files as plain text or rendered HTML based on the Accept header [1].

Cons

• Static files only. This is by design but worth stating plainly. No proxying, no dynamic content, no WebSocket upgrade, no CGI. If your architecture needs any of those, SWS is not a standalone solution — you need it behind a real reverse proxy [1].
• 2,169 stars is modest. Caddy has 60K+, nginx has a half-century of production history. The community is smaller, which means fewer real-world troubleshooting resources, slower plugin/extension growth, and more risk if the primary maintainer steps back.
• No web UI or management console. Configuration is entirely file/flag based [1][2]. Fine for technical users; a non-starter for anyone who needs to hand off operations to a non-technical team member.
• Third-party review coverage is essentially nonexistent. This makes it harder to validate performance claims and find real-world gotchas before you’re in production.
• Benchmark data is hosted in a separate repository and the actual numbers aren’t reproduced in the main documentation [2]. The benchmarks exist, but you have to find them — which makes the “blazing fast” claim harder to evaluate quickly.
• Basic HTTP Authentication only. No OAuth, no OIDC, no anything beyond username/password [2]. If you need to gate access properly, handle that at the reverse proxy or load balancer layer.

---

Who should use this / who shouldn’t

Use Static Web Server if:

• You’re deploying a static site, SPA, or documentation portal and want a minimal, production-ready server without nginx’s configuration complexity.
• You’re running containers and care about image size — the Scratch-based Docker image is as lean as it gets.
• You want Brotli/Zstd compression, HTTP/2, and security headers without plugin management.
• You’re writing Rust and want to embed a static file server in your application as a library crate.
• You need cross-platform binaries and want the same server running on Linux, Windows, and macOS without behavior differences.

Skip it (use Caddy instead) if:

• You want automatic HTTPS via Let’s Encrypt with zero configuration. Caddy handles certificate renewal automatically; SWS requires you to manage certs yourself or put it behind a proxy [2].
• You need a reverse proxy that also serves static files. Caddy does both; SWS does one.

Skip it (use nginx instead) if:

• Your team already knows nginx and has existing configs. The operational familiarity is worth more than binary size.
• You need a massive community knowledge base for edge cases and unusual configurations.
• You need advanced load balancing, rate limiting, or complex proxy logic alongside static file serving.

Skip it (use managed hosting) if:

• You want zero ops overhead and a CDN included. Cloudflare Pages free tier is hard to argue with for a low-traffic site, and Netlify’s DX for static deployments is genuinely better than managing your own server.
• You don’t have a VPS already and the prospect of setting one up is the blocker — the managed platforms are the right call.

---

Alternatives worth considering

• nginx — the standard for production static file serving. More complex configuration, but an enormous knowledge base, proven at massive scale, and every hosting guide ever written assumes you know it.
• Caddy — the modern upgrade path from nginx for most use cases. Automatic HTTPS, clean config syntax, built-in reverse proxy. Larger binary and footprint than SWS but far more capable as a full server.
• Apache httpd — the legacy option. Don’t choose this for new deployments unless you have a specific reason.
• miniserve — another Rust-based static file server with a focus on simplicity. Even more minimal than SWS, no TLS built in, better suited for LAN sharing or development than production.
• Lighttpd — small, fast, C-based. Similar niche to SWS but older, less maintained.
• Netlify / Vercel / Cloudflare Pages — managed static hosting with CI/CD, CDN, and DX tooling. No ops overhead, but vendor lock-in and per-seat pricing at scale.
• S3 + CloudFront — the AWS answer. Scales to anything, metered pricing that can surprise you at volume.

For the self-hosted path specifically, the realistic comparison for a non-technical founder is SWS vs Caddy. Caddy wins on automatic HTTPS and zero-config simplicity. SWS wins on binary size and container footprint. If you’re unsure, Caddy is the safer default.

---

Bottom line

Static Web Server does exactly one thing and does it without apology: serve static files, fast, with the features that actually matter in production — HTTP/2, compression, TLS, CORS, virtual hosting, SPA routing, and a health endpoint — packed into a 4MB binary you can drop anywhere. It’s not trying to replace nginx for general-purpose reverse proxying, and it’s not trying to be Caddy with automatic certificate management. It’s the answer to “I have a directory of files and I need them served correctly without installing a web server that’s bigger than my site.” The Apache 2.0 license means you can embed it, ship it, and build on it commercially without a license conversation. At 2,169 stars it’s not a household name, which means you’re relying on the documentation rather than a decade of Stack Overflow answers when something goes sideways — but for a tool this focused in scope, the surface area for things to go sideways is genuinely small.

---

Sources

1. Static Web Server — GitHub Repository and README (Apache 2.0, 2,169 stars). https://github.com/static-web-server/static-web-server
2. Static Web Server — Official Documentation and Website. https://static-web-server.net/
3. Static Web Server — Features Documentation. https://static-web-server.net/features/http1/

Note: No substantive third-party reviews of Static Web Server were found during research. All claims in this article are sourced from the official repository, documentation, and website.