Static Web Server on Ubuntu 24.04 LTS

Static Web Server, also known as SWS, is a cross platform, high performance and asynchronous web server built in Rust for serving static files. It compiles to a single self contained binary with zero runtime dependencies, which makes it exceptionally fast to start, very light on memory and simple to operate. This image delivers Static Web Server fully installed and hardened on Ubuntu 24.04 LTS as a managed systemd service, so a working, TLS enabled web server is answering requests within minutes of launch.

Static Web Server terminates HTTPS itself, so there is no separate reverse proxy to run or maintain. On the first boot of your instance a one shot service generates a unique self signed TLS certificate for that specific virtual machine, so every deployment gets its own key material and no certificate or private key is ever baked into the image. The same site is served on port 443 over HTTPS and on port 80 over HTTP, and because no host name is written into the image the server answers for whatever address or domain you point at it, from the moment it boots. When you are ready for a browser trusted certificate you can drop in your own certificate and key, and the guide shows you how to turn port 80 into a permanent redirect to HTTPS once your domain is in place.

Secure and lean by default: directory listing is disabled, so the contents of a directory that has no index file are never exposed; hidden dotfiles such as version control metadata and environment files are never served; symbolic links are not followed out of the document root; and Strict Transport Security, X Frame Options, X Content Type Options and a Content Security Policy are sent on every response. The Prometheus metrics endpoint is deliberately switched off, because it is an unauthenticated information disclosure surface on a public web server, and the guide shows you how to enable it safely when you want it. The server runs as a dedicated unprivileged account inside a tightly sandboxed systemd unit whose only remaining privilege is the ability to bind the standard web ports.

Content delivery is tuned out of the box. Responses are compressed on demand with Gzip, Deflate, Brotli or Zstandard according to what the client accepts, precompressed files already on disk are served directly when they exist, cache control headers are applied by file type, and custom 404 and error pages ship with the image. A health endpoint at /health returns a 200 status and produces no log noise, which makes it ideal for load balancer and availability probes. A single page application fallback, virtual hosts, custom headers, redirects, rewrites, CORS and HTTP basic authentication are all available and documented in the guide.

Application stack: Static Web Server runs under systemd as a dedicated unprivileged service account, with one listener on port 443 for HTTPS and one on port 80 for HTTP, both serving the same document root. The whole configuration is plain readable TOML, so your web server configuration lives in version controllable text. There is no database, no administrative web console, no login and no password anywhere in the product, because a static web server has no administrative account, so this image ships with no known or shared bootstrap credential of any kind.

Key capabilities: a single binary web server with zero runtime dependencies and a very small memory footprint; HTTPS terminated by the server itself with a per instance self signed certificate generated at first boot; the same site served over HTTPS and HTTP for any address or domain, with no host name baked into the image; a hardened default posture with directory listing disabled, dotfiles hidden, symbolic links blocked and security headers always sent; on demand and precompressed content compression with cache control headers; custom error pages, a single page application fallback and a quiet health endpoint; and readable TOML configuration for virtual hosts, redirects, rewrites, custom headers, CORS and basic authentication.

Get started: browse to the instance to see the cloudimg landing page, replace the document root with your own site or application build output, adjust the TOML configuration for virtual hosts and headers as described in the guide, then open ports 80 and 443 to your users. cloudimg engineers can help you design your configuration, install a certificate authority issued certificate, enable the permanent HTTPS redirect, tune caching and compression, and put Static Web Server in front of your content after purchase.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.