Connect Your Own Domain to a Micropage Site
Every Micropage project is live on its own *.micropage.sh host from the moment you publish. But most real sites want their own address — www.example.com, store.example.com, docs.example.com.
Micropage serves your project over HTTPS at any subdomain you own, with a certificate that’s provisioned and renewed for you. This is the practical, step-by-step version. If you want the architecture behind it, see 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 you want, e.g.
www.example.com. - At your DNS provider, create one CNAME record:
| Field | Value |
|---|---|
| Type | CNAME |
| Name | www (or your chosen subdomain) |
| Target | cname.micropage.sh |
That’s it. Within a minute or two, the editor’s status panel walks through Waiting for DNS → Validating → Issuing TLS certificate → Live. Once it’s green, https://www.example.com/ serves your project.
You don’t upload or renew a certificate. It’s issued and rotated for you.
The one target that matters
Point the CNAME at cname.micropage.sh — not at your project’s own something.micropage.sh host.
This is the most common mistake. Your project host routes into Micropage’s static hosting directly; CNAMEing your custom domain to it will not work. The custom-domain entry point is always cname.micropage.sh.
If the status is stuck on Waiting for DNS past five minutes, confirm the record with:
dig CNAME www.example.com
It should resolve to cname.micropage.sh. If it doesn’t, or your provider set a long TTL, propagation just needs more time.
If you’re on Cloudflare DNS: turn the cloud gray
This is the second thing that catches people. If your DNS is hosted on Cloudflare and the subdomain’s record is proxied (orange cloud), validation fails — often silently.
Switch that record to DNS-only (gray cloud) for the subdomain you’re attaching, then click Retry validation in the editor. Micropage already sits behind Cloudflare on our side; you don’t need Cloudflare’s proxy in front of it too.
Apex domains need a redirect
Micropage attaches subdomains — www.example.com, not the bare example.com. The editor rejects apex domains with a message.
If you want the bare domain to work, set up a redirect at your DNS provider: point example.com at https://www.example.com. Most providers offer this under “URL forwarding” or “redirect rules.” The apex then bounces visitors to your live subdomain.
Removing a domain
Removing the domain in the editor cleans everything up immediately, and the certificate for the unused hostname is deprovisioned automatically. Nothing to unwind by hand.
Notes
- Custom domains are available on paid plans.
- Any subdomain you own works — including multi-level ones like
app.api.example.com. - CNAME-flattening providers (Cloudflare, Route 53, DNSimple, and others) all work the same way.
Next steps
- Custom Domains reference — full setup and troubleshooting
- Deploy a static site to Cloudflare Pages
- How Micropage serves thousands of custom domains — the architecture