Skip to content
Loom Documentation
Open the app

Publishing

The build

Publishing queues one job. It:

  1. Reads the pinned revision, not the live file set — an edit mid-build can never ship something nobody reviewed.
  2. Runs the build driver.
  3. Injects meta tags, JSON-LD, robots.txt, sitemap.xml and llms.txt.
  4. Writes the artifact to a per-deployment directory.
  5. Flips the site pointer — only once every byte is on disk.

A failed build cannot take down what is already live, and a rollback is a pointer move rather than a rebuild.

Drivers

Bundled shells out to esbuild for a real production bundle. Framework code stays external and resolves through the import map, so every site shares one cached copy of React rather than inlining its own.

Runtime ships source inside the document shell and transpiles in the visitor's browser. No Node required on the host. If a bundled build fails, the pipeline falls back to this and says so in the log — a bundler problem should not leave a user unpublished.

Serving

Published sites resolve by Host. A middleware short-circuits before any application route runs, so a site request never falls through to the app.

SiteController exists so a buyer on shared hosting has a working publish flow with no extra infrastructure. On a real deployment, put the artifact disk behind a CDN and this never runs.

HTML is revalidated on every request so a republish is visible immediately; fingerprinted assets are cached hard and immutable.

Keeping a site private

A published site can sit behind a shared password — the usual case is a client review before launch. Publish → Access turns it on.

The gate runs ahead of the session, so the unlock is an encrypted cookie bound to the current password hash rather than a session entry. Changing the password therefore signs out everyone already in, and a published site never shares the application's session store.

Protected sites are served with noindex, so a pre-launch review cannot end up in a search index.

Custom domains

  1. The user adds a hostname.
  2. They publish two DNS records — a TXT proving control, and a CNAME pointing at your target.
  3. Verification checks the TXT record before anything is served on that host.

Without the check, anyone could attach a domain they do not own and have your install answer for it.

Set LOOM_DNS_TARGET to whatever you want users to point at.

Answer-engine files

Generated from project settings, not remembered by hand:

  • schema.org JSON-LD — WebSite, plus the organization and any FAQ
  • llms.txt — a plain-language brief, with the page outline derived from the headings actually written
  • sitemap.xml, robots.txt, canonical, Open Graph, Twitter

Toggle individually under config('loom.aeo').