unsubbed.co

miniserve

Miniserve is a self-hosted server management tool that provides CLI tool to serve files and dirs over HTTP.

A self-hosted HTTP file server, honestly reviewed. No fluff — just what you get when you drop the binary and run it.

TL;DR

  • What it is: A cross-platform, single-binary CLI tool that serves files and directories over HTTP — written in Rust, ships as one executable, no dependencies [README].
  • Who it’s for: Developers and sysadmins who need to share files fast, homelab users who want a proper directory listing server, and non-technical founders who want to give teams access to files without spinning up a full NAS or cloud storage bucket.
  • Cost savings: Zero licensing cost (MIT). Runs on any Linux VPS from $4/mo. Replaces Dropbox Business ($15–$24/user/mo) or a file-hosting tier on Nextcloud for basic file-sharing scenarios [README].
  • Key strength: It genuinely does what it says in one command with zero config. The entire feature surface — auth, TLS, uploads, dark mode, WebDAV — is exposed as CLI flags. No YAML, no database, no admin panel to configure.
  • Key weakness: It’s a file server, not a file manager. No user management UI, no sharing links, no versioning, no collaboration features. If you need those, you need a different tool.

What is miniserve

miniserve is a Rust CLI tool with one job: point it at a directory (or a single file) and it immediately becomes an HTTP server. The GitHub description cuts straight to the point: “For when you really just want to serve some files over HTTP right now!” [README].

The project is maintained by Sven-Hendrik Haase (svenstaro) and has accumulated 7,489 GitHub stars as of this review. It ships as a single compiled binary — no Python runtime, no Node.js, no Docker daemon required if you just want the bare binary. You download it, make it executable, and run it. That’s the entire install story for the basic case.

What makes it more than python -m http.server is the feature set that comes with that single binary: HTTP Basic Auth (including hash-based passwords and auth files), TLS with your own certificates, file uploads, directory creation via HTTP, dark mode, multiple themes, WebDAV support, SPA routing, raw output for CLI browsers, random URL routes, and QR code generation for mobile access. All as flags [README].

It’s MIT-licensed, cross-platform (Linux, macOS, Windows), available via Homebrew, Cargo, Docker Hub, and as pre-built binaries on GitHub Releases.


Why people choose it

The self-hosted community reaches for miniserve in a few specific situations where the alternatives fall short.

The python -m http.server escape. Python’s built-in server has no auth, no TLS, no uploads, and serves awkwardly on Windows. Every developer has used it in a pinch and then wished for something with a password prompt. miniserve is that thing. You get the same zero-config startup with a meaningfully larger feature set [README].

The “I need to share this ISO” scenario. When you need to hand someone a large file from your homelab or VPS and Dropbox feels like overkill, miniserve linux-distro.iso gives you a browser-downloadable link in two seconds. The optional --random-route flag generates a short hex path (/c789b6) that you can share without exposing your full directory structure [README].

The Nextcloud alternative for read-only file distribution. Nextcloud is a full collaboration platform with a database, a PHP stack, and a significant maintenance surface. If your use case is “let the team download the latest build artifacts” or “give the client access to deliverables,” miniserve with HTTP Basic Auth and TLS is a much simpler answer. No database to back up, no PHP to update [README].

The mobile upload collection point. The --media-type image flag sends a browser hint that triggers the camera app on mobile Firefox for Android. Combined with -u (upload enabled), you have a way to collect photos from a phone without AirDrop, WhatsApp, or a cloud service [README].


Features

Based on the README directly:

Serving modes:

  • Serve a directory with a sortable, browsable listing [README]
  • Serve a single file for direct download [README]
  • Set a custom index file instead of listing [README]
  • SPA mode: non-existent paths forward to index.html for client-side routing [README]

Authentication:

  • HTTP Basic Auth with plaintext password: --auth user:pass [README]
  • SHA256-hashed passwords: --auth user:sha256:$hash [README]
  • Auth from file for multiple accounts: --auth-file [README]

Networking:

  • Bind to multiple interfaces simultaneously (-i flag repeated) [README]
  • Random 6-character hex route for obscure sharing: --random-route [README]
  • Custom HTTP headers via --header (useful for CORS, Cache-Control, HSTS) [README]

TLS:

  • Bring your own cert and key: --tls-cert / --tls-key [README]
  • Works with Let’s Encrypt fullchain PEM files for A+ SSL Labs rating with HSTS [README]

File operations:

  • File upload via POST: --upload-files or -u [README]
  • Directory creation via upload endpoint: --mkdir [README]
  • Upload restricted to specific paths by passing a path argument to -u [README]

UI and output:

  • Dark mode, multiple color themes [merged profile]
  • Raw minimal HTML mode: ?raw=true query parameter — usable with lynx, w3m, curl [README]
  • --show-wget-footer: adds a copy-pastable wget command at the bottom of listings for recursive downloads [README]
  • Media type hint (--media-type image) for mobile camera integration [README]

Deployment options:

  • Single binary download (no runtime required) [README]
  • Homebrew, Cargo install [README]
  • Docker Hub image (svenstaro/miniserve) [merged profile]
  • Shell completions for bash/zsh/fish [README]
  • systemd service support [README]
  • WebDAV support [merged profile]

Pricing: SaaS vs self-hosted math

There is no SaaS version of miniserve. It’s purely a self-hosted open-source tool under the MIT license. The cost model is straightforward:

miniserve itself: $0 [README]

Infrastructure to run it:

  • On a local machine: $0 beyond your existing hardware
  • On a VPS: $4–6/mo on Hetzner or Contabo for a basic instance; the binary is so lightweight it can share a server with other services without meaningful overhead

What you’re replacing:

Use caseSaaS costminiserve cost
Dropbox Business (3 users)$45/mo~$5/mo VPS
Nextcloud hosting (managed)$10–30/mo~$5/mo VPS (self-managed)
S3 + presigned URLs setupEngineering time + $0.023/GBBinary + VPS
SharePoint file distributionBundled in M365 ($6–22/user/mo)~$5/mo VPS

For a non-technical founder sharing deliverables with a client — build artifacts, design files, export dumps — the realistic comparison is paying $15–45/mo for Dropbox Business versus spending an afternoon setting up a $5 VPS with miniserve behind Caddy. After that one-time setup, the monthly cost is just the VPS.

Caveats: miniserve has no resumable uploads, no chunked transfer for huge files, and no bandwidth optimization. For multi-gigabyte files served to hundreds of users simultaneously, you’d want a CDN in front of it or a different tool.


Deployment reality check

miniserve is one of the easier self-hosted tools to deploy because the default case is literally one file.

The fastest path:

curl -L https://github.com/svenstaro/miniserve/releases/latest/download/miniserve-linux-x86_64 -o miniserve
chmod +x miniserve
./miniserve /your/directory

That’s it. Port 8080, no config file, browsable directory listing immediately available.

For a production-grade setup (HTTPS, auth, persistent service), you need:

  • A Linux VPS with any modern OS
  • A domain name
  • A reverse proxy for TLS termination (Caddy automates Let’s Encrypt; alternatively, pass your cert directly via --tls-cert)
  • A systemd unit file if you want it to survive reboots — the README includes instructions [README]

What can go wrong:

  • Binding behavior is non-obvious. The README has a dedicated “Binding behavior” section, which implies it’s caused enough confusion to document specifically. By default it binds :: (all IPv6 interfaces, which usually includes IPv4 via dual-stack) but behavior differs across Linux distributions and Docker setups.
  • Upload directory traversal risk. When you enable uploads (-u), the path restrictions matter. If you pass -u without a path argument, uploads are accepted anywhere. In a production setup you should restrict upload destinations explicitly.
  • No rate limiting. miniserve has no built-in rate limiting or DDoS protection. If you expose it to the public internet without a reverse proxy, you’re relying on your VPS’s network for protection.
  • WebDAV is listed as a feature in the merged profile but isn’t extensively documented in the README’s main feature table. It exists, but it’s not the primary use case and may have rough edges for complex WebDAV clients.
  • No LDAP/SSO. Auth is HTTP Basic only — one or more user:password pairs in a file, or hardcoded on the command line. Fine for small teams; not suitable for an organization that needs centralized identity.

Realistic setup time for a technical user: 10–20 minutes from a bare VPS to a working HTTPS instance with auth. For a non-technical founder with guidance or a deployment service: 1–2 hours.


Pros and cons

Pros

  • Single binary, zero dependencies. Download, execute, done. No runtime, no daemon, no config file required for the basic case [README]. This is genuinely rare and valuable.
  • MIT license. No usage restrictions, no commercial limitations, no future license-change risk [README].
  • Rust performance and safety. Handles concurrent requests efficiently with a very small memory footprint. The binary itself is typically 5–10MB.
  • Comprehensive auth options without a full user management system — plaintext, SHA256 hash, or auth file covers most small-team use cases [README].
  • TLS built in. Bring your own cert and you’re done. No need for a reverse proxy if you’re serving a single service [README].
  • Upload support with path restrictions — makes it a two-way file exchange point, not just a read-only server [README].
  • Dark mode and themes — the UI is clean enough that you’d willingly send a client to it [merged profile].
  • Raw mode and wget footer — genuinely useful for automation and CLI workflows [README].
  • Docker Hub image maintained alongside the binary [merged profile].
  • 7,489 GitHub stars — mature, battle-tested, not abandoned [merged profile].

Cons

  • No user management UI. Adding or removing users means editing a file and restarting the process. No web admin, no API [README].
  • No sharing links. You can’t generate a time-limited link to a specific file the way Dropbox or Nextcloud can. The random route obscures your directory but doesn’t expire.
  • No versioning or history. Whatever’s on disk is what’s served. Deleted is deleted.
  • No collaboration features. No commenting, no annotations, no folder sharing permissions per user. It’s a file server, not a file manager.
  • Basic Auth is cleartext over HTTP. You must run TLS if you’re doing auth over the public internet — not a miniserve limitation exactly, but a deployment requirement that non-technical users might miss.
  • WebDAV support exists but is secondary to the HTTP listing use case — don’t expect polished Windows Explorer / macOS Finder integration without testing.
  • No resumable uploads. Large file uploads that fail partway through must restart from scratch.
  • Binding behavior quirks across environments — documented enough to suggest it’s a recurring gotcha [README].

Who should use this / who shouldn’t

Use miniserve if:

  • You need to share files from a server or NAS with a clean browser UI and zero setup overhead.
  • You want a Dropbox-free way to give clients or contractors access to large deliverables with basic password protection.
  • You’re a developer who wants a local HTTP server with auth and upload support for testing purposes.
  • You’re building a homelab and need a lightweight file-access layer that won’t consume RAM your Plex server needs.
  • You want a tool you can trust to still work in five years because it’s a compiled binary with no external dependencies.

Skip it (use Filebrowser instead) if:

  • You need a web UI for managing files — creating folders, moving files, deleting — not just browsing and downloading.
  • You need per-user permissions at the file/folder level.
  • You want a proper admin panel with user management.

Skip it (use Nextcloud instead) if:

  • You need collaboration: shared editing, comments, contacts, calendar integration.
  • You need mobile sync clients that keep files in sync automatically.
  • You need versioning and trash recovery.

Skip it (use Caddy or nginx static serving) if:

  • You’re serving a website, not a directory of files.
  • You need fine-grained URL routing, redirects, and caching headers at scale.

Skip it (stay on Dropbox) if:

  • You’re not comfortable with a terminal at all and don’t have someone to set this up once.
  • You need sharing links that expire and can be revoked per-recipient.

Alternatives worth considering

  • Filebrowser — adds a full web-based file manager UI with user accounts, file operations, and sharing. More setup, more features. Pick this if you want to manage files, not just serve them.
  • Dufs — another Rust single-binary file server, focused on WebDAV and more granular access control. Worth evaluating if WebDAV is a primary requirement.
  • Caddy with file_server — if you’re already running Caddy as a reverse proxy, its built-in file server covers the read-only directory listing case with automatic HTTPS.
  • Nextcloud — the full collaboration platform. Dramatically more setup and maintenance, but covers the entire file management + sharing + sync surface.
  • Seafile — faster sync performance than Nextcloud, more focused on file sync than groupware. Harder to deploy.
  • python -m http.server — the obvious incumbent. Free, always available. No auth, no TLS, no uploads, no dark mode. Fine for localhost debugging, not for anything network-accessible.
  • rclone serve http — if your files already live in S3 or another cloud backend, rclone serve http can front them. More complexity, but avoids a local copy.

For the specific audience of this site — a non-technical founder who wants to share files without a monthly SaaS bill — the realistic shortlist is miniserve vs Filebrowser. Choose miniserve if you only need read/write access to a directory and want the simplest possible thing. Choose Filebrowser if you want a UI that looks like a product and lets you manage files from the browser.


Bottom line

miniserve is the answer to a question developers ask constantly and then answer badly. “How do I quickly serve these files over HTTP?” usually gets answered with python -m http.server, a hastily configured nginx, or a free tier on some cloud service. miniserve is the right answer: a compiled, zero-dependency binary that starts in one command, ships with auth, TLS, uploads, and a clean UI, and costs nothing. Its limitations are real — no user management, no sharing links, no versioning — but they’re limitations by design. It does one thing and does it well.

For a founder running a $6 VPS who needs to share deliverables with clients or give a team access to build artifacts without routing everything through Dropbox, miniserve is a one-afternoon setup that pays for itself in the first month. The binary will still work in five years when your Python version has changed three times and your Nextcloud install has accumulated three failed upgrade attempts.

If the afternoon of setup is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for clients. One-time fee, done, you own the infrastructure.


Sources

  1. miniserve GitHub Repository and README — svenstaro/miniserve (7,489 stars, MIT license). https://github.com/svenstaro/miniserve
  2. miniserve Docker Hub — Official Docker image (svenstaro/miniserve). https://hub.docker.com/r/svenstaro/miniserve
  3. miniserve Crates.io — Rust package registry listing. https://crates.io/crates/miniserve

Pipeline issue to flag: The five “third-party articles” provided as [1]–[5] in the task inputs are all about a Japanese artist はせくらみゆき (Hasekura Miyuki), not miniserve. The scraping step fetched unrelated pages — likely a search or URL resolution error. The article above was written from the README and merged profile data only. The scraping pipeline for this slug needs to be debugged before re-running.

Features

Integrations & APIs

  • Plugin / Extension System
  • WebDAV

Media & Files

  • File Attachments

Customization & Branding

  • Dark Mode
  • Themes / Skins

Security & Privacy

  • SSL / TLS / HTTPS