🌐 Custom domains & organizations

Run events on your own web address, showing only your organization's events.

One installation can serve several organizations, each on its own web address. Point events.mitoydna.org here and it becomes mitoYDNA's events site: their name at the top, their events in the directory, and nobody else's event reachable on it.

🧭 How it decides

Every request carries the address the visitor typed. The platform matches that against the hostnames registered for each organization, and scopes what it shows:

Visitor arrives on	They see
An organization's own domain	Only that organization's published events, under its name, tagline and logo. Another organization's event address returns not found rather than rendering on the wrong brand.
The platform's own domain	Every published event, whoever owns it. This is the view the main site keeps.
An address nobody has registered	The platform view — the safe default, so a misconfigured DNS record shows a working site rather than an empty one.

ℹ️ Note

Events not yet assigned to an organization behave like platform events: visible on the main domain, and on no tenant domain. Adding organizations therefore can't make an existing event disappear.

🏢 Setting up an organization

🌐 Organizations in the console (platform admins only) is where these live. Create one with a name, then fill in what its events page should say:

Name	Shown as the heading on their events directory.
Tagline	The line underneath. Replaces the platform's own blurb.
Logo URL	A link to their logo, shown instead of the platform mark.
Primary color	Accent for their name in the heading.
Website URL + label	Becomes the footer attribution on their pages.

Then assign their events: open each event's hub and set 🌐 Organization.

🔗 Pointing a domain at us

⚠️ Heads up

Registering the hostname in the console is only one of three steps. DNS has to reach us, and the TLS certificate has to cover the name — a browser refuses the connection otherwise, and it will refuse it before any of our code runs. All three, or the domain doesn't work.

Register the hostname. On the organization in 🌐 Organizations, add e.g. events.mitoydna.org. The first hostname added becomes the primary, which is the address used in links that outlive the visit — ticket emails, QR codes, claim links.
Request the certificate. Press Request certificate in the 🔐 TLS panel. It asks for one covering the platform domain and every hostname registered here, then shows a validation record per domain.
Send each owner their two records. The validation CNAME from that table, plus a CNAME from their subdomain to the CloudFront distribution. (An apex like mitoydna.org needs an ALIAS/ANAME instead — most registrars support one, but a subdomain is simpler and worth asking for.)
Wait for issued, then deploy. The panel shows each domain going green as its record lands. Once the certificate reads issued, run a plain npx sst deploy — it picks up the certificate and the hostname list on its own, with nothing to pass.
Check it. Load the address. You should get their branding and only their events — and another organization's event path should return not found.

ℹ️ Note

Why the deploy step survives the automation. The console can request certificates, but attaching one means changing the CloudFront distribution — and that is managed by the deployment tool. Changing it from the app would be reverted, or collide, the next time anyone deploys. So the console publishes the decision and the deploy carries it out.

⚠️ Heads up

Nothing attaches until the certificate is issued — deliberately. Attaching a pending certificate would take the whole site down, not just the new domain, and CloudFront rejects an address the certificate doesn't cover. So a half-finished domain is inert rather than dangerous, and it's safe to deploy at any point in this process.

💡 Tip

Every added hostname means a new certificate — ACM certificates are immutable, so there is no expanding one. That's fine, but it does mean a redeploy per onboarding, so it's worth batching customers who are ready at the same time.

🩺 When a domain isn't working

Symptom	Almost always
Certificate warning in the browser	The certificate doesn't cover this hostname. Check the 🔐 TLS panel lists it, re-request if not, then redeploy once it reads issued.
CloudFront error before reaching the site	The distribution isn't accepting the name yet — the certificate hasn't issued, or it issued but nobody has deployed since. Check the panel, then deploy.
A validation record has been added but stays pending	Check for a wildcard DNS record shadowing it — an exact record wins, but only if it actually exists at the exact name ACM printed, including the `_` prefix. A stray NS delegation on the subdomain will also send lookups somewhere that doesn't have the record.
Loads, but shows the platform's events	DNS and TLS are fine; the hostname just isn't registered to an organization — or it's registered with a typo. Check the spelling in 🌐 Organizations.
Loads their brand, but an event is missing	That event isn't assigned to the organization, or isn't published. Check both on the event's hub.
Ticket emails link to the wrong domain	The organization has no primary hostname, or the wrong one is primary. Set it in 🌐 Organizations.

🔀 What is and isn't split by domain

Scoped to the domain	The events directory, its branding and footer, and which events are reachable at all.
Shared across domains	Accounts and sign-in — one account works everywhere, so an attendee at two organizations' events doesn't need two logins. The organizer console is also reachable from any of them, and already shows people only the events they organize.