Hosted apps

Domino can host the app your members use, such as your quest page or rewards hub, so you can launch without servers of your own. While you build, your team shares a private staging app that runs on test data. When you're ready, a promotion puts the same app live at <your-project>.domino.page, or at your own address such as quests.example.com.

Hosting is optional: if you already have a website or app, it can keep its own code, login and hosting and add Domino to it. See connect your app.

What Domino hosts

Your app goes through a few stages, each at its own address:

• One repository per project. Creating a project from a starter gives it a working app to start from.
• Previews are for working. A preview shows the app while your developer or Playground works on it, and goes offline when they stop. See Develop and share a preview.
• Staging is for sharing. Each time your developer stages a version, the staging address serves it, for your team to try. See Stage and share.
• Live is for your members. Approving a promotion that carries a version puts it live. See How test and live hosting relate.
• A custom domain serves live under your name. See Custom domains.

Changing the address

The project name is only a label; renaming it doesn't change any address. The addresses come from the project's slug, which organization admins can change from Console's danger zone. See project settings.

• Staging moves without a rebuild. Domino registers the new address before switching. If that fails, the old address keeps working and you can retry.
• Live moves within about a minute. The old live address stops serving, with no redirect, so links containing the old slug stop working and members sign in again at the new address.
• Your custom domain is unaffected. A custom domain belongs to the project, not the slug.
• Old slugs stay yours. Previous and prepared slugs stay reserved to the project until it is purged. Secrets and hosted storage keep their permanent internal identity.

Static sites and Worker apps

An app is either a plain website, or one with its own server code that can, for example, award points when something happens on your site.

What a Worker app receives

An app with server code gets what it needs to talk to Domino and keep its own data, with separate keys and storage for test and live, and no passwords stored in the code.

Staged and live Worker apps get these through their environment. Each environment supplies its own values:

Scheduled jobs

An app can run jobs on a schedule, such as a nightly sync of your shop's orders.

How test and live hosting relate

Previews and staging run in the project's test environment, on test data with real member sign-in. The live app runs in live, on live data. A version reaches live only through a promotion that a person approves in Console.

1. Stage a build. Your developer puts a version on staging, with test's key, secrets, stores, and schedules.
2. Promote. A promotion carries the version serving staging. Its preview warns about app secrets set in test and missing in live.
3. Approve. Once approval commits, Domino deploys the same version again with live's own key, secrets, stores, and schedule signing key. Live stores that do not exist yet are created, and SQL migrations run against live's databases before the switch. Then the live app serves the new version, typically a couple of minutes after approval. Until then, the version live already serves keeps serving.

• See where it stands. The Live app card in Deployments, shown in both environments, gives the address, <project-slug>.domino.page (it redirects to the custom domain while one is active), and its state: Nothing live yet, Deploying, Live, or Deployment failed with the reason. Choose Open live app to open it.
• Public. The live app has no staging sign-in, no staging banner, and search engines may index it.
• Member sign-in selects live. Sign-in from the live app's address uses the project's live members and live sign-in settings. Staging and previews stay on test.
• Your app can ask which one it is. Every hosted address tells the app whether it serves test or live; see Tell test from live.
• Nothing live yet. Before the first approved promotion that carries a build, and for a deleted project, <project-slug>.domino.page answers 404 with a page titled Nothing is live here yet. The page does not say whether a project exists.
• Offline without a plan. Where plans apply, a project whose live trial and its 7-day grace ended without a plan goes offline: <project-slug>.domino.page and its custom domain answer 503 with a page titled This app is offline, and participant requests to live are refused with live-offline. A plan brings the same build back within about a minute. See Going live needs a plan.
• Failed deployments keep the previous build. If the live deployment fails, or does not finish within an hour, the previous live build keeps serving. The next promotion shows the app build as changed again; approve it to retry.
• Rollback. A rollback promotion carries the earlier promotion's build. Approving it deploys that build to live the same way.

Your app and its quests travel together through a promotion, which carries both test's definitions and the version serving staging. Staging a version also publishes that commit's quests and catalog to test. Live refuses code sent to it directly (domino deploy --environment live), so a promotion is the only way either reaches live. See Publish behavior.

Custom domains

A custom domain, such as quests.example.com, puts your live app at an address you own. You add it in Console, then whoever manages your domain adds two DNS records. It is a setting of the live environment: it serves only the live app, a promotion never copies or changes it, and staging keeps <project-slug>--staging.domino.page. Set it up in Console Settings → Domains; Use your own domain has the steps.

• Two DNS records. A CNAME from your hostname to cname.domino.page, which sends its traffic to Domino, and a TXT record at _domino.<hostname> with a value unique to this attachment, which proves you control the domain's DNS today. Domino does nothing at Cloudflare until it finds the TXT record, so typing someone else's domain takes nothing from them.
• What Domino saw, not a summary. The domain shows each record next to what public DNS returned, Cloudflare's hostname and certificate statuses and its validation errors word for word, when Domino last checked and checks next, and when the certificate expires. Domino checks often while a domain is set up and daily once it is active.
• Subdomains only. Root domains such as example.com cannot be attached. Attach www.example.com or another subdomain, and redirect the root to it at your DNS provider. Wildcards, IP addresses and Domino's own domains are refused too.
• Growth and up. Where plans apply, adding a custom domain needs the project on Growth, Scale or Enterprise; on Free or Launch it fails with plan-required. A project that moves to a smaller plan through Domino billing keeps its domains until the period it paid for ends; when the smaller plan starts, its domains are detached and the app is served on its domino.page address again. A plan Domino support set keeps the domains. Organizations whose domain limits Domino support raised can add domains on any plan. When the project's plan doesn't include a domain, Console's Domains settings say so and link to Settings → Plan & usage.
• One per project. By default a project has one custom domain, and an organization at most 10. Contact Domino support to raise either limit.
• The domino.page address redirects. While the domain is active, page loads (GET and HEAD) on <project-slug>.domino.page answer with a temporary redirect to it, keeping the path and query. Members signed in at the old address sign in again at the new one. Other requests keep working at both addresses.
• Before the first live build, the domain answers as <project-slug>.domino.page does: Nothing is live here yet.
• Moving a site. HTTPS fails between pointing the CNAME at cname.domino.page and the certificate's issue, usually a few minutes. If the domain has CAA records, they must allow letsencrypt.org and pki.goog.
• Moving the domain to another project. Add it to the other project and publish that attachment's TXT record. Once Domino finds it, the domain stops serving the first project, then serves the new one within a couple of minutes; the first project's domain shows Needs attention.
• Removing it stops serving within about a minute. Attaching it again, to any project, needs a new TXT record. Subdomains of one domain, such as a.example.com and b.example.com in two organizations, can set cookies for each other; that is the domain owner's to manage.

Who can open it

Staging is never public, and neither is its participant API: calls that name the staging address answer only for browsers signed in to staging, through the staging address, and anything else is refused with staging-access-required. By default, visitors sign in with Domino Console and need access to the project in test. A person with publish can switch staging access to a password for reviewers outside Console. A preview is reachable by anyone with its address while it runs; member sign-in still controls what members can do. The live app is public.

Traffic from one address

A conference venue, school or office often puts every visitor behind one shared internet address. Domino sets no limit on how many requests a hosted app takes from one address, on staging, live or a custom domain, so a crowd on one Wi-Fi network is served like a crowd on many. Sign-in is separate: it limits attempts per address to slow down abuse, so a crowd signing in at the same moment on one network can reach those limits. Member sign-in has its own limits (see Add Domino participant sign-in), and a staging password takes 10 attempts per address in 5 minutes.

When a project is deleted or moved

See Delete or move a project.

Where next