Read every line.
Then run all of it.
Sitebin is open source the boring, dependable way: one Go binary, one Caddy, one volume, zero databases. The hosted service and your self-hosted instance are the same code.
# the whole setup — point DNS at your box, then:
docker run -d --name sitebin \
-p 80:80 -p 443:443 -p 443:443/udp \
-v sitebin-data:/data \
-e SITEBIN_BASE_DOMAIN=sitebin.example.com \
-e SITEBIN_DNS_PROVIDER=cloudflare \
-e SITEBIN_DNS_TOKEN=<your-dns-api-token> \
-e SITEBIN_ACME_EMAIL=you@example.com \
--restart unless-stopped \
sitebin:latest
Open your domain, drop files. Wildcard TLS, subdomains and cleanup are handled for you — full quickstart.
The filesystem is the database
Most platforms hide your content inside a database you can't touch. Sitebin refuses: what you see on disk is what's served.
One folder per site
A site is a directory of your files plus a meta.json.
Lookups are symlink indexes. You can inspect, rsync or grep your whole
platform with coreutils.
Backup = copy a path
Everything durable — sites, indexes, accounts, certificates — lives in
/data. sitebin backup streams a tarball;
restoring it on a fresh box restores the platform.
One image, two processes
Caddy terminates TLS and routes; a single Go binary does everything else — API, WebDAV, FTP, viewer, cleanup. No queues, no cache layers, no migrations.
Isolation by origin
Every site is served on its own random subdomain, never on the main domain — each gets its own browser origin, so hosted HTML can't touch your instance UI.
No build step, anywhere
The web UI is hand-written HTML/CSS/JS embedded in the binary, viewer
libraries vendored. Clone, go build, done — no Node
required, ever.
Tested like a product
Unit and handler tests run inside the image build; a full end-to-end suite drives the real container over HTTP, WebDAV and FTP. If the image built, the tests passed.
Open core without the fine-print games
Core — MIT
Everything documented in the README: publishing, viewer, editor, WebDAV, FTP, API, deploy tooling. Use it commercially, fork it, ship it. It never converts, never expires, never gets features moved out from under it.
Enterprise — source-available
Accounts, tiers, OAuth, SMTP, billing and custom domains live in an
ee/ directory under the Elastic License 2.0 — published in
the same repo for audit and self-hosting, but not for resale as a
hosted service. The community image contains none of it, compiled out,
so the MIT binary stays pure.
Why this split? Hosting bills and development time are paid by Enterprise licenses — not by rugging the community edition later. The boundary is public, explicit and in the repository for you to check.
Issues, PRs and hard questions welcome
Found a bug, want a viewer for another format, or think our security model has a hole? The tracker is where Sitebin gets better.
Sibling project: the MIT-licensed IT-Trail SaaS Stack — auth, subscriptions and credit billing for your own SaaS apps. Sitebin Enterprise plugs into it natively.