How to Use a Custom Domain for a Private Page

You can serve a page on a domain you own without it becoming a public page. A custom domain for a private page is a change of address and nothing else: you point the domain at SnapHost, bind it to the site, and the people you named still verify their email before anything loads, except now the address bar says reports.acme.com instead of ours.

That is the short answer. The rest of this post is the order to do it in, the two shapes a domain can take, and the handful of things that take a working domain back down, which is the part nobody warns you about.

How to use a custom domain for a private page

1. Publish the page and make sure it has a live link. A domain binds to a published, shared site, not to a draft: adding one to a site that is not published yet is refused with exactly that message.
2. Add the domain in the site's Custom domain panel, say reports.acme.com. Your assistant can do this instead, over the SnapHost connector, and it gets handed the same records you would have seen.
3. Add those records at your registrar. An apex domain takes an A record; a subdomain takes a CNAME to the same address.
4. Wait. The panel re-checks on its own roughly every twelve seconds, and the status moves from Awaiting DNS to Verifying to Live.

There is no fifth step. The HTTPS certificate is issued and renewed for you, and the allowlist, password and expiry already on the site carry over as they are. If the automatic checking gives up (it stops after twenty tries, about four minutes, so a misconfigured record does not poll forever), fix the record and press Check now.

One site, or your whole workspace

A domain binds in one of two shapes, and picking the wrong one is the most common way to end up redoing this.

A site binding serves exactly one page. The host exposes nothing else: every other path on it folds into that site's viewer, so a stray URL does not reach a different site of yours and does not reach anyone else's. deck.acme.com for one pitch deck is this shape.

A workspace binding makes the domain a full alias of your workspace's own subdomain. Slugs resolve on every path, so share.acme.com/q3-review and share.acme.com/clients/acme/q3-review both answer, with one DNS record for all of it. This is the shape for a team that keeps putting things in front of people and wants them all on one address.

A workspace alias is a workspace-level asset, so an owner or an admin sets it up, and a workspace gets one. A site domain follows the site: whoever can edit that site can manage its domain, which is not the same as being a workspace admin.

What you actually add at your registrar

SnapHost shows you the records rather than making you work them out. For an apex domain like acme.com that is an A record on the root. For a subdomain it is a CNAME pointing at the same address. There may also be a TXT record, which is the ownership proof: it is how the domain is confirmed to be yours and not someone else's typo.

If editing DNS is not something you want to do at all, the other route is to hand the domain's nameservers over, and then the apex, the www name and the certificate are all handled for you. That is more delegation than most people want for a domain they also use for email, so read it as the option it is, not the recommendation.

DNS is the slow part and it is not ours. A few minutes is normal. An hour happens. The status badge tells you which side the hold-up is on: Awaiting DNS and Verifying mean the records are still settling, Needs attention means something has to change before it will come up.

Your own address does not change who can open the page

This is the point of the whole exercise, so it is worth being explicit. Access control lives on the site, not on the hostname. The verification step, the allowlist, a view password, a link expiry: all of them behave on your domain the way they behave on the share link. The password screen and the emailed verification link address themselves on your host too, so a viewer never gets bounced back to a snaphost.ai URL partway through.

The flip side is that a custom domain is not itself a security control. It is branding and routing. A page that is public stays public on your domain, and a domain that looks internal (internal.acme.com) does not make its contents internal. If you want the page restricted, that is still a visibility setting, and the levers for taking access away are the same ones.

What quietly takes a working domain back down

A custom domain is not a permanent redirect you set once. It keeps checking whether it should still be serving, and it fails closed when the answer is no. Three things end it:

• The site stops being published. Take the page offline and its domain is suspended within moments, not on some overnight sweep. Publish it again and the domain revives and re-points itself at the current link.
• The plan lapses. Custom domains come with Pro, and a billing change is re-checked straight away. A downgrade suspends the domain; going back up revives it.
• DNS or the certificate lapses at your registrar. Nothing of ours notices this as it happens, so a scheduled pass over active domains is what catches it, and the status turns to Needs attention.

In each case the domain is marked and stops serving rather than serving something stale or, worse, something else. That is the behaviour you want. It does mean that "the client says the link is dead" is sometimes a plan problem or a republish problem rather than a DNS problem, and the status badge is where you find out which.

The bare address, and what answers at the root

A workspace domain has one extra decision: what share.acme.com itself serves. You can name a root site for it, and that page answers at the bare address while everything else resolves by slug. Without a root chosen, the root 404s the way an unknown slug does, which surprises people who expected a listing page. There is no index of your sites at that address, by design.

The root site has to be published and shared when you pick it. If it later goes offline, it drops out of the domain quietly and the rest of the addresses keep working, so the failure is a 404 at the root rather than a dead domain. Renaming your workspace handle is safe too: the alias re-points itself.

How many domains you get, and what this costs

Custom domains are a Pro feature. Pro is 19 euros a month for each member who can publish, and the people reading are free, however many of them there are. You get three domains for every paid member, shared across the workspace, so a workspace of one gets three. The current list of what sits on which plan is on pricing.

Free has no custom domains. Pages on Free live at sites.snaphost.ai with a small SnapHost mark in the corner, up to three at a time, each one public or private to up to three named people. That is a real constraint and not a nudge: if the address matters to you, this is the feature you are upgrading for.

Worth knowing before you buy a domain for it: a Pro workspace also gets its own subdomain, like acme.snaphost.ai, and slugs resolve on it the same way they do on a workspace alias. For internal work that is often enough, and it needs no DNS at all. Personal space, workspaces and folders covers how that addressing works.

Removing a domain, and reusing one

Removing a domain detaches it, clears it from the routing map and stops it serving immediately, so do not use remove as a way to pause something. The site is untouched and keeps its original share link. You can add the same domain again later, including one you removed, and a domain already in use somewhere on SnapHost is refused rather than silently stolen.

Moving a domain from one site to another is a remove and an add, which means a gap. For a client-facing address you are updating regularly, the better pattern is to keep the domain bound to one site and update that site in place, which is what keeps the address stable in the first place.

When this is not worth the twenty minutes

One page for one client, once: the share link is fine, and the domain is twenty minutes you could spend on the page. A standing address people will return to, a deliverable your client's legal team will look at twice, anything going in a proposal: that is where your own domain earns the setup.

And if you do not control DNS for the domain, none of this works, which in practice is the real blocker more often than any of the above. You need to be able to add a record at the registrar, or to ask someone who can. The custom domains doc is the short version to send them.