Back to dollama.net

Personal Hosting

Serve a static site straight from your own node at <name>.host.dollama.net — owner-only, shared with a group, or public.

A static site, served from your machine

dollama host publishes a folder of static files (HTML, CSS, JS, images, video) at https://<name>.host.dollama.net. There is no upload and no build server: the files stay on your disk, and the site is served directly from your own node over the same tunnel the network already uses. dollama's relay does not store your site — it matches the viewer's request to your node and passes the response through.

Because it is served from your machine, a hosted site is live only while that machine is running dollama network. Stop the node and the site goes offline; start it again and the site comes back at the same URL. It's meant for personal pages, project docs, demos, and small team sites — not for high-availability production hosting.

Hosting does not depend on inference. Your sites keep working while the node is not running any inference, as long as it is running dollama network.

Set up and publish your first site

1

Log in and start your node

Hosting binds a site to one of your own nodes, so you need a relay account and a running node.

dollama login          # link your GitHub identity
dollama network        # run your node (serves inference + your sites)
2

Register the directory

Point host add at the folder that holds your index.html, then pick a name and one scope.

dollama host add ./public --name my-blog --private    # owner-only

Output:

Hosting "my-blog" → /home/you/public
  URL:   https://my-blog.host.dollama.net
  Scope: private
  The site is served while your node runs `dollama network`.
3

Open the URL

Visit https://my-blog.host.dollama.net. An owner-only or group site shows a one-time GitHub login before it lets you in; a public site loads straight away.

tip

Edits are live

Files under the folder are read per request, so saving a file updates an owner-only or group site as soon as you reload the page. A public site is cached for 5 minutes, so an edit can take up to 5 minutes to appear for visitors. You only re-run host add to change the name or access.

The dollama host command group

dollama host add <dir>

Register a static directory as a hosted site and bind it to the node you're on now. <dir> becomes the site root (put an index.html there); the path is resolved to an absolute path and remembered in your config so the node re-serves it across restarts. Provide exactly one scope.

FlagTypeDefaultDescription
--namestringrequiredDNS label for the site; becomes <name>.host.dollama.net. Lowercase letters, digits, hyphens. A short reserved-word list (e.g. api, www, admin) is rejected.
--privateboolfalseOwner-only: you must be logged in as the owner to view. (The flag is called --private; it has nothing to do with Private mode for inference.)
--groupstring""Share with this group (by name). Any member can view.
--publicboolfalseAnyone with the link can view — no login.
dollama host add ./public --name blog       --private
dollama host add ./site   --name team-wiki  --group acme
dollama host add ./dist   --name demo       --public
dollama host list

List every hosted site you own, with its scope, the node it's bound to, and whether that node is currently online. A site whose node shows offline is registered but unreachable until you start dollama network on that machine.

NAME       SCOPE    NODE             STATUS
blog       private  6b1e…node-uuid   online
team-wiki  group    6b1e…node-uuid   online
demo       public   a24c…node-uuid   offline
dollama host rm <name>

Revoke a hosted site: remove it from the relay and drop the local binding so your node stops serving it on the next reconnect. This deletes the registration, not the files on disk. Safe to run even if the site was already revoked elsewhere.

dollama host rm blog

Every command supports --help for the same reference inline, e.g. dollama host add --help. You can also create and manage sites from the web dashboard (dollama app → Hosting), which can change a site's scope in place without a revoke and re-register.

Who can see your site

These settings answer one question: who can view the site. They do not change where inference runs or whose requests your machine serves.

Owner-only --private

  • Only you. You, signed in with the GitHub account that owns the site.
  • A one-time login interstitial runs before the first view.
  • Use for drafts, personal dashboards, anything you don't want shared.

Group

  • Members of one group. Anyone in the named group can view after login.
  • Membership is re-checked on every request, server-side.
  • Use for team wikis, internal docs, shared demos.

Public

  • Anyone with the link. No login, no account.
  • Loads straight to the content.
  • Cached at the edge for 5 minutes, so repeat visitors don't touch your machine — an update can take that long to appear.
  • Use for landing pages, open project docs, public demos.

The scope is enforced fail-closed: the hosting edge asks the relay to authorize each viewer on each request, and any error — unknown site, revoked, non-member, relay unreachable — results in a denial, never an accidental allow. Owner-only and group sites use the relay's existing GitHub device-OAuth flow; the login page is minimal and self-contained.

Caching follows the scope. Only a public site's pages are cacheable — they carry Cache-Control: public, max-age=300 plus an ETag, so the edge and the browser can hold them and a refresh costs a small revalidation instead of re-downloading from your node. Owner-only and group content is served private, no-store and is never stored by a shared cache, because a cached copy could otherwise be replayed to someone the ACL would have refused. Switching a site from public to owner-only or group takes up to 5 minutes to clear already-cached copies.

From URL to your disk

How it works, in detail
1

Host → site name

A request to <name>.host.dollama.net hits the hosting ingress edge app, which extracts <name>.

2

Viewer auth

The ingress sets its own signed, host-scoped session cookie holding only a viewer id (never a relay token). An unauthenticated viewer of an owner-only or group site gets a login interstitial that runs the relay's GitHub device-OAuth flow.

3

Per-request ACL

The ingress asks the relay to resolve <name> into {owner, group, node online, authorized}. The relay computes authorization (owner or group member) next to its membership tables. Any error denies.

4

Forward to your node

The relay proxies the request over your node's standing WebSocket tunnel, stamping the authoritative site name as the Host header so a multi-site node resolves the right root.

5

Your node answers

The node reads the requested file from the site root — traversal-contained, no code execution — and returns it. The ingress adds fixed security headers and hands the bytes back to the viewer. The relay never stores your content; it only routes.

Static files, index.html, and media

  • Directories serve index.html. A request for / or any subdirectory returns that directory's index.html. There are no directory listings.
  • Missing files are a 404. There is no single-page-app rewrite to index.html. An SPA that relies on server-side path rewriting won't deep-link — use hash-based routing, or generate the pages you link to.
  • Traversal is contained. The node serves only files under the registered root; .. and symlinks that escape the root are refused.
  • Large media streams. Video and audio are served with HTTP range requests (206 Partial Content) so they play and seek in the browser. Large non-media downloads stream in chunks.
  • GET/HEAD only. The node reads files; it never executes anything. No server-side code, forms, or databases.

What to know before you rely on it

Enforced for you

  • Fail-closed access checks on every request
  • Fixed security headers on all responses (nosniff, X-Frame-Options: DENY, frame-ancestors 'none', no-referrer)
  • Site cookies are per-subdomain — one site can't read another's
  • Login-CSRF / session-fixation hardening on the device-OAuth flow
  • Per-IP rate limits on login and the proxy path

Know the limits (v1)

  • Availability = your node. The site is down whenever your machine is off or not running dollama network.
  • Not end-to-end encrypted. TLS ends at the ingress, so the ingress and the relay can read hosted files as they pass through. End-to-end encryption over the tunnel is future work.
  • Static only. No server-side code, no databases, no request rewriting.
  • 5 sites per user; one node serves each site.

Good fits

  • Personal pages, portfolios, blogs
  • Project and team documentation
  • Demos and prototypes
  • Small, non-critical shared sites

Don't host anything that needs guaranteed uptime, or content you wouldn't want the ingress and relay to be able to read in transit.

When a site won't load

SymptomLikely cause & fix
host list shows offlineThe bound node isn't running. Start dollama network on that machine.
Browser shows 404No index.html at that path, or the file doesn't exist. Remember there is no SPA rewrite.
Browser shows 403You're logged in but not authorized — not the owner (owner-only) or not a group member (group).
Browser shows 410The site was revoked with host rm. Re-register with host add.
Browser shows 502 / 504The node is offline, slow, or the relay can't reach it. Check dollama network is running and healthy.
hosting requires a relayRun dollama network once first so a relay account and node registration exist.

Still stuck? See the CLI reference for exact flags.