Enterprise setup

Sitebin is open-core: the community edition is complete on its own, and the enterprise edition adds accounts, tiers & quotas, OAuth login, SMTP, and billing through Stripe, Paddle or the SaaS Stack on top — all configured at container startup, like everything else.

Editions

• Community (default) — MIT licensed, built with go build / the default sitebin:latest image. Fully open, no accounts, no feature gates.
• Enterprise — the ee/ tree, governed by the Elastic License 2.0. Compiled in only with the ee build tag (go build -tags ee, image sitebin:latest-ee).

The ee/ source is published in the repository — source-available, so you can read and audit every line before you buy. Both editions build from the same repo, but the community sitebin:latest image contains none of the ee/ code: it is excluded at compile time, so the community binary stays pure MIT.

Building your own Enterprise image

Two build arguments, both easy to miss — and missing them produces a binary that looks fine and then stops creating sites after 90 days with no explanation:

docker build \
  --build-arg EDITION=enterprise \
  --build-arg LICENSE_ROOTS="<base64url ed25519 root public key>[,<another>]" \
  -t sitebin:latest-ee .

• EDITION=enterprise compiles the ee/ tree in. Without it you get a community binary: no accounts, no tiers, no licensing at all.
• LICENSE_ROOTS is the comma-separated list of trusted Ed25519 root public keys, baked into the binary at build time. A build with no roots trusts nothing, so no license can ever verify: the instance runs its 90-day trial and then restricts creation. It says so at startup, at ERROR level on every start, and sitebin version prints trusted license roots: NONE (unlicensable build) — check that line on any artifact before you ship it. There is deliberately no environment override for the roots: anything that could set one could mint itself a license.

The published ghcr.io/ittrail/sitebin.io:latest-ee image gets its roots from the LICENSE_ROOTS repository variable of the product repo, and the release workflow refuses to build the enterprise image while that variable is empty. Verify a pulled image with docker run --rm ghcr.io/ittrail/sitebin.io:latest-ee version.

Account modes

SITEBIN_ACCOUNT_MODE selects how the instance handles users (default: open):

• open — no accounts; anonymous creation, exactly like the community edition.
• accounts — users log in to create sites.
• tiers — accounts plus tiered quotas (and optionally paid plans).

Enterprise environment variables

Tiers

Tiers are defined as JSON, either inline in SITEBIN_TIERS or in a file mounted at SITEBIN_TIERS_FILE:

[
  {
    "id": "free",
    "label": "Free",
    "max_site_bytes": 104857600,
    "max_files": 500,
    "max_sites": 10,
    "webdav": true,
    "custom_domains": 0,
    "max_expiry_days": 7,
    "price": null
  },
  {
    "id": "pro",
    "label": "Pro",
    "max_site_bytes": 1073741824,
    "max_files": 5000,
    "max_sites": 100,
    "webdav": true,
    "custom_domains": 5,
    "max_expiry_days": 0,
    "max_containers": 3,
    "max_forms": 1,
    "trusted": true,
    "price": { "monthly": "6", "annual": "60", "currency": "EUR" }
  },
  {
    "id": "studio",
    "label": "Studio",
    "max_site_bytes": 5368709120,
    "max_files": 10000,
    "max_sites": 500,
    "webdav": true,
    "custom_domains": 25,
    "max_expiry_days": 0,
    "max_containers": 20,
    "max_forms": 10,
    "max_zones": 3,
    "trusted": true,
    "price": { "monthly": "19", "annual": "190", "currency": "EUR" }
  }
]

max_containers caps the container services an account runs across all its sites. 0 or absent means none — like custom_domains, so a tier that forgets the field never gets compute. It only matters with SITEBIN_CONTAINERS=docker.

max_zones is how many zones an account may hold — domains proven once, with unlimited names under them. 0 or absent means none. Names in a zone do not count against custom_domains, but they do count against the license's instance-wide domain ceiling.

max_forms caps each site's forms. 0 or absent means none. It is stamped on a site like its other caps; a smaller plan pauses the newest forms rather than deleting them. It only matters with SITEBIN_FORMS_SMTP_HOST set. A tier with max_forms above 0 must also carry "trusted": true (below), or its sites get no forms.

Two optional flags change behaviour rather than quotas. "trusted": true exempts the tier's sites from the strict content-security headers untrusted uploads get — no host allowlist for scripts, styles, fonts and images, no block on requests to other servers — and from automatic locks: the upload scanner and the CSP tripwire only flag and alert on a trusted site. Grant it to plans whose holders you can hold accountable, and see Operations & security for what the two header levels contain. "admin": true marks a tier whose holders may reach the instance register at /account/admin: every site on the instance, with search, filters, delete and expiry control. Admin needs a second condition — the account's email must also be listed in SITEBIN_ADMIN_ACCOUNTS — so neither the tier source nor the container environment can grant instance-wide access on its own.

A price makes a tier a paid plan the dashboard sells, and it comes in two shapes for the two kinds of backend. monthly, annual and currency are amounts (currency is ISO 4217, default EUR): PayGate is handed these and creates the product in whatever processor the stack uses. stripe and paddle are identifiers for products you created in that provider yourself, and only a direct backend can use them. A tier may carry both; the active backend reads what it needs. display is a human string shown only while no amount is set — an amount always wins, so a shown price cannot disagree with the charged one. Running Stripe or Paddle directly, point the provider's webhooks at POST /account/billing/stripe/webhook and POST /account/billing/paddle/webhook; the hosted service (Drop, Free, Pro €6/€60, Studio €19/€190) bills through PayGate instead.

The account dashboard

The dashboard lives at /account on the main domain. Sites created while signed in are owned by the account and still work over the API with their edit password. Manage opens a site's edit page directly: signed in, its owner needs no edit password there.

It lists each site by its name, its URL and its custom domains — the ones that serve as links, the ones still waiting for their DNS record marked pending DNS. A name is an optional private label of up to 60 characters; it can be given or changed right in the list, without the site's edit password, as well as on the edit page and through the API and MCP.

It also issues API tokens, optionally named. A token creates sites owned by the account without a browser session — which is what makes publishing from CI or an AI agent possible on an instance where sign-in goes through SSO — and stands in for the edit password on every site that account already owns. It is shown once and stored only as a hash, and it acts on sites, never on the account: the dashboard refuses it, so it cannot change a plan or delete the account. See the API page.