App sites
An app site serves one or more of your published apps
standalone — on their own URL, outside the main Hutly workspace. Every site
is reachable at <slug>.apps.hutly.com, and you can also connect your own
custom domain (e.g. app.yourcompany.com).
You manage app sites under Organization → App sites (owners/admins), from the
hutly app-sites CLI, or by asking Sammy (the managing-app-sites skill).
Pricing
App sites are billed monthly from your org’s credit balance:
- $0.50 / month per slug site (every slug site).
- $5.00 / month per active custom domain (charged only while the domain is live; a domain that’s still verifying or has been removed isn’t billed).
Fees are charged once per calendar month per site/domain and appear on your usage like any other credit consumption. As with all credit usage, if your balance runs low, auto-top-up (if enabled) covers it.
What’s on a site
- A slug — the label in
<slug>.apps.hutly.com. Lowercase letters, numbers, and hyphens, 2–63 characters, globally unique. It can’t be changed after creation (create a new site to change the URL). - Apps at paths — mount several apps on one site at different paths (
/,/admin, …). Each app points at an approved version of a published app artifact. - Site navigation — when on, apps that opt in (
Show in nav) appear in a shared nav bar linking between them. Turn it off to serve each app standalone. - Custom domains — serve the site on your own domain in addition to the slug.
Public vs. private apps
An app served on a site is public — reachable without signing in — only if
its approved manifest is marked public: true. A manifest can only be marked
public when its declared scope is empty (no workflows, tables, or agents),
since an anonymous visitor can’t be granted access to your org’s data — so an
empty scope is required, but you must still set the flag. Any app that isn’t
marked public requires the visitor to be signed in to your organization; a
private app’s path returns not found to anonymous visitors (so its existence
isn’t disclosed).
Adding an app
You can only add an app at a version whose manifest has been approved (the same approval gate as pinning an app in the workspace). If the app isn’t approved yet, approve it first — see building apps. Then, in App sites → your site → Apps, choose the app, set its path and title, and optionally show it in the nav.
Connecting a custom domain
Custom domains use a two-record DNS handshake:
- Add the domain (App sites → your site → Custom domains → Add domain). Hutly returns a first DNS record — a CNAME proving you own the domain.
- Create that record at your DNS provider, then click Verify now (Hutly also checks periodically).
- Once ownership is verified and the certificate is issued, a second record appears — the one that points your domain at Hutly.
- Create the routing record, verify again, and the domain goes Active.
Each record is shown as Type · Host/Name · Value · TTL with copy buttons and a live status (Pending → Verified).
DNS notes
- Subdomains (
app.yourcompany.com) use a CNAME for both records — the simplest path. - Root/apex domains (
yourcompany.com) need an ALIAS/ANAME record for the routing step (a plain CNAME can’t live at a root domain). This is supported by Route 53, Cloudflare, DNSimple, and most managed DNS providers; if yours only supports CNAME records, use a subdomain instead. - Cloudflare: set the record’s proxy status to DNS only (grey cloud). A proxied (orange-cloud) record breaks certificate validation and routing.
- DNS changes can take minutes to propagate. If verification stalls, double-check the record’s Name and Value match exactly.
Bundled into a module
An app site can also be named as a root in a module — a registry entry that packages it (and/or a workflow) into a single catalogue product.
From the CLI
hutly app-sites list
hutly app-sites create --slug acme --name "Acme Portal"
hutly app-sites apps add <siteId> --path / --artifact-id <id> --version-id <id> --title "Home"
hutly app-sites apps reorder <siteId> <appId1> <appId2>
hutly app-sites domains add <siteId> app.acme.com # returns the DNS records to create
hutly app-sites domains verify <siteId> <domainId> # re-checks; safe to repeatSee the CLI reference for the full command set.