MicroApps

Appearance

Custom domains & SSL ​

Bring your own domain, point it at a pod, and turn on SSL. No certificate files to manage, no renewal cron jobs, no proxy config to hand-edit.

The journey is four steps, in this order: add the domain, prove you own it, map it to a pod, turn on SSL. Every click is named below.

What you need first ​

  • The domain, already registered.
  • Access to wherever its DNS is managed - your registrar, Cloudflare, Route 53, whoever answers for the name. You will be adding records there, and nobody else can do that part for you.
  • A pod, but only from step 3 onwards. Steps 1 and 2 work on their own.

1. Add the domain ​

  1. Open Domains in the console, or click Domains in the side panel.
  2. Click New, at the top right of the domains table. You land on the Create Domain page.
  3. Type the name into Domain Name - example.com for a root domain, app.example.com for a subdomain. That is the whole form.
  4. Click Create Domain.

You come back to the domains table with the domain in it. Click its name to open it. You land on the domain's Overview tab, and that is where the rest of this guide happens.

We work out the rest from the name: whether it is a root domain or a subdomain, and which DNS records you need. They are waiting on the DNS tab.

2. Prove you own it ​

Until you verify, the domain sits on your account unlocked, and anyone else who proves ownership can take it. So do this now.

  1. On the domain page, click the DNS tab.
  2. Find the row named microapps-verify, marked with an Ownership chip.
  3. At your DNS provider, create a TXT record:
    • Name (your provider may call it Host or Record name): microapps-verify
    • Value (or Content, or Data): the value in the Content column. Click the copy icon next to it rather than retyping - it is a long token and one wrong character means it never verifies.
    • TTL: the value shown, or your provider's default. Either is fine.
  4. Save the record at your provider, and give it a few minutes to propagate.
  5. Back on the DNS tab, click Verify ownership on that row. Recheck DNS, at the top right, rechecks every record at once.

The row's Status goes from Pending to Verified. The domain is now locked to your account for good.

If someone else added your domain first

Publishing your TXT record opens a 48-hour claim on it. First to verify wins. If they already verified it, it is locked to their account and you would need them to remove it.

3. Map the domain to a pod ​

Mapping tells us which pod serves the domain. Publishing the pointing record tells the internet to send visitors to us.

  1. On the domain's Overview tab, find the Pod mapping card. It says "No pod mapped".
  2. Click Map a pod.
  3. Fill in the dialog, in the order it presents them:
    • Pod - the pod that serves this domain. Only compatible pods are listed, so database pods are not offered: you cannot map a domain to one.
    • Pod port number - the port your app listens on inside the pod, such as 3000.
    • Traffic Type - HTTP or HTTPS. This is what your app speaks inside the pod, not what your visitors use. Most apps here are HTTP, and we still take HTTPS from visitors once you turn SSL on.
  4. Click Save Mapping. The card now shows the pod name and its internal endpoint.
  5. Click the DNS tab. There is a new row marked with a Web chip, named @.
  6. At your DNS provider, create that record:
    • For a subdomain like app.example.com, it is a CNAME. Name: the subdomain part (app), or @ if your provider scopes the zone to the full name. Value: the target in the Content column.
    • For a root domain like example.com, it is an ALIAS. See the section below, because not every provider has these.
  7. Click Recheck DNS. When the Web row reads Verified, visitors are reaching your pod.

Root domains and ALIAS records ​

A CNAME cannot sit at the root of a zone next to the SOA, NS, MX and TXT records that live there. So for a root domain we show an ALIAS record instead, pointing at the same target.

Your DNS provider may call it ANAME or CNAME flattening. Cloudflare, Route 53, DNSimple, Namecheap and Porkbun all offer one of these, and it verifies exactly like a CNAME.

If your provider has none of them, use www instead:

  1. Add www.example.com as its own domain, following step 1 above.
  2. Map it to the same pod, following step 3. As a subdomain it takes an ordinary CNAME, which every provider supports.
  3. It is covered by the root domain's SSL certificate, so there is nothing extra to issue.
  4. At your provider, redirect the root domain to www using its URL forwarding feature. Check that https://example.com forwards and not only http://, because some forwarders only handle the unencrypted one.

Or move your DNS to a provider with ALIAS support. Cloudflare's free plan has it.

4. Turn on SSL ​

Certificates are issued and renewed through one delegation record. Publish it once and renewals take care of themselves, forever.

  1. On the domain's DNS tab, find the row named _acme-challenge, marked with an SSL chip. It is a CNAME.
  2. At your DNS provider, create it:
    • Name: _acme-challenge
    • Value: the target in the Content column, copied with the copy icon.
  3. Give it a few minutes, then click Recheck DNS. The row should read Verified.
  4. Go to the Overview tab and find the SSL certificate card. It says "Not enabled", and tells you whether that delegation record has verified yet.
  5. Click Enable SSL, then confirm.

We provision the certificate and set it to renew before it expires, automatically, for as long as the domain exists. The card switches to "Enabled" and names what the certificate covers: your domain and all of its subdomains.

Your site is now reachable at https://your-domain.com.

Leave the _acme-challenge record in place

Renewal runs through it too. Delete it and the certificate you have keeps serving until it expires, then quietly fails to renew.

Enabling SSL does not require the mapping to be in place first, so steps 3 and 4 work in either order.

If a record never verifies: check DNSSEC ​

Sometimes a record stays Pending in the console even though your DNS host shows it, and the domain's page shows a red DNSSEC is broken notice at the top. That notice means the public resolvers we check with refuse every name under your domain, and so do the resolvers your visitors use, so the site is unreachable for most people too.

The cause is a mismatch at the registry. When DNSSEC is switched on, your registrar publishes a DS record for the domain at the registry, and your DNS host signs the zone with a matching key. If the two stop matching, most often because the domain moved to a different DNS host without DNSSEC being switched off first, resolvers that validate DNSSEC (Cloudflare 1.1.1.1, Google 8.8.8.8 and most ISPs) treat the whole domain as forged and answer SERVFAIL.

To confirm it yourself:

sh
dig @1.1.1.1 TXT microapps-verify.example.com
dig @1.1.1.1 TXT microapps-verify.example.com +cdflag

If the first query fails with SERVFAIL and the second one answers, DNSSEC is the problem. The +cdflag option asks the resolver to skip validation, which is why the record appears only then.

To fix it:

  1. Sign in at your registrar (where you bought the domain) and open the domain's DNSSEC settings.
  2. If your DNS host does not sign the zone, switch DNSSEC off. This removes the DS record from the registry.
  3. If your DNS host does sign the zone, replace the DS record with the one your DNS host shows you.
  4. Wait for the old DS record to expire from caches. Its TTL is usually 15 minutes to an hour.
  5. Open Domains, click the domain, open the DNS tab and click Recheck DNS, at the top right. The notice disappears once resolvers accept the domain again, and the records verify on that check.

Unmapping ​

Moving a domain off a pod:

  1. Open the domain and stay on the Overview tab.
  2. On the Pod mapping card, click the unlink icon next to Change pod.
  3. Confirm.

The mapping clears and the web pointing record drops off the DNS checklist. It comes back, pointed at the new pod's target, when you map again. The SSL certificate is kept, so re-mapping later does not mean re-issuing anything.

Multiple domains, one pod ​

You can map several domains to the same pod, each with its own certificate. Handy for vanity domains, marketing pages, or staging aliases. Repeat steps 1 to 4 for each one.

API ​

The same flow is available via the domains API.

Built for the long tail.

© 2026 MicroApps