Connect a Custom Domain to Your Micropage Site
Every Micropage project is live on its own *.micropage.sh host from the moment you publish. Most real sites want their own address — www.example.com, app.example.com.
Custom domains are a Pro feature. Micropage serves the project over HTTPS at a subdomain you own, with a certificate provisioned and renewed for you. Architecture write-up: How Micropage serves thousands of custom domains.
The setup
Two steps: tell Micropage the domain, then point your DNS at us.
- In the web editor, open your project → Settings → Custom Domain → enter the subdomain, e.g.
www.example.com. - At your DNS provider, create one CNAME:
| Field | Value |
|---|---|
| Type | CNAME |
| Name | www (or your subdomain) |
| Target | cname.micropage.sh |
Within a minute or two the editor walks through Waiting for DNS → Validating → Issuing TLS certificate → Live. You don’t upload or renew a certificate.
The one target that matters
Point the CNAME at cname.micropage.sh — not at your project’s something.micropage.sh host.
That is the usual mistake. The project host goes straight into static hosting. The custom-domain entry point is always cname.micropage.sh.
If status sits on Waiting for DNS past five minutes:
dig CNAME www.example.com
It should resolve to cname.micropage.sh. Long TTLs just need time.
If you’re on Cloudflare DNS: turn the cloud gray
If the record is proxied (orange cloud), validation fails — often silently.
Switch that record to DNS-only (gray cloud), then Retry validation. Micropage already sits behind Cloudflare on our side.
Apex domains need a redirect
Micropage attaches subdomains, not the bare example.com. Redirect the apex to https://www.example.com at your DNS provider.
Removing a domain
Removing it in the editor deprovisions the certificate. Nothing to unwind by hand.
Notes
- Any subdomain you own works, including
app.api.example.com - CNAME-flattening providers (Cloudflare, Route 53, DNSimple) work the same way