Custom Domains: Add a CNAME, We Handle the Rest
Every EnvHaven workspace gets a preview URL: preview-myapp-alice.envhaven.app. It works, but showing a client preview-demoapp-sarah.envhaven.app in a browser tab isn't a great look. You want demo.sarahcodes.com.
Custom domain mapping is now available on all tiers. Add a CNAME record at your DNS provider, and we take care of SSL, verification, and routing. No special account needed. No nameserver changes.
How it works
The setup is one DNS record:
demo CNAME domains.envhaven.app
That's it. Once the CNAME is in place, we detect it, issue a TLS certificate automatically, and begin routing traffic to your workspace. The whole process typically takes under five minutes.
The dashboard shows you where things stand. "Pending DNS" means we're waiting for your CNAME. "Issuing certificate" means TLS is being provisioned. "Active" means traffic is flowing. If something goes wrong, you see the specific reason and what to do about it.
Domains are independent of workspaces
This was an intentional design choice. A domain is yours; a workspace is a thing you might create, delete, and recreate. Coupling them together means deleting a workspace also deletes your verified domain and its certificate. That's wasteful.
Instead, domains and workspaces are managed separately. You can register a domain before you even have a workspace. You can point it at a workspace, re-point it at a different one, or unpoint it entirely. Deleting a workspace unpoints the domain automatically, but the domain stays verified with a valid cert.
The practical benefit: spin up a new workspace, point your existing domain at it, and traffic routes within seconds. No CNAME changes. No certificate re-issuance. No waiting.
Re-pointing is instant
Changing which workspace a domain points to propagates in seconds, not minutes. Your DNS records stay the same. Your certificate stays the same.
This matters for workflows where you're iterating on different versions of something. Point staging.yourcompany.com at workspace A, test it, then re-point it at workspace B. The domain follows wherever you tell it to go.
Port changes are transparent
If your workspace exposes port 3000 and you switch it to 8080, the custom domain keeps working. The port change is picked up automatically. No domain reconfiguration needed on your end.
Apex domains
Using myapp.com (no subdomain) requires your DNS provider to support CNAME flattening. Some do, some don't. The dashboard detects apex domains and shows relevant guidance.
If your provider doesn't support it, use www.myapp.com instead, then set up a redirect from the naked domain using your provider's URL forwarding. This is standard DNS provider functionality; the specifics depend on your provider's docs, not ours.
One domain per workspace
For now, each workspace can have one custom domain, and each domain can point to one workspace. You can have multiple domains across different workspaces. Sarah can point portfolio.sarahcodes.com at her portfolio workspace and demo.sarahcodes.com at her demo workspace, each with its own certificate.
The one-to-one constraint keeps things simple. If demand for multiple domains per workspace is strong enough, loosening it later is straightforward.
Domain limits
Your domain cap is twice your total workspace count across all subscriptions. One workspace gives you two domains. Five workspaces give you ten. This scales with your usage and prevents squatting without imposing an arbitrary hard limit.
If you hit the cap, remove an unused domain or add a workspace.
What happens when things go wrong
Domains can fail for a few reasons, and the dashboard tells you which one:
CAA records: If your domain has Certificate Authority Authorization records that restrict which CAs can issue certificates, our certificate authorities may be blocked. The dashboard shows which CAA records to add.
CNAME removed: If you delete the CNAME after the domain is active, we detect it within minutes. The domain transitions to failed with instructions to re-add the record.
Workspace down: If your workspace isn't running, the domain is still "active" in the sense that DNS and TLS are valid, but visitors see a 502. The dashboard shows a warning alongside the domain status.
In all cases, there's a Retry button. It restarts the verification process from scratch. If the underlying issue is resolved, the domain re-activates.
What we're not building (yet)
This release is BYOD: bring your own domain. You register and manage the domain at your existing DNS provider. We just handle the mapping.
Managed domains, where you purchase a domain directly through EnvHaven, are planned for a future release. Different problem, different complexity. Registrar integration, renewal billing, transfer policies. We'd rather ship the simple thing now and do the complex thing right later.
The honest tradeoffs
One domain per workspace. If you need multiple domains pointing to the same workspace, this doesn't support that today.
Verification delay. We check domain status every two minutes. In the worst case, there's a two-minute delay between your domain verifying and the dashboard reflecting it. Usually it's faster.
No wildcard domains. Wildcards (*.example.com) require TXT-based domain control validation, which conflicts with the CNAME-only setup. Use specific subdomains.
Apex domain friction. If your DNS provider doesn't support CNAME flattening, apex domains won't work. This is a DNS limitation, not ours, but it still means some users need to use www instead.
Free, but BYOD. You're not paying us for the domain feature, but you're paying your DNS registrar for the domain itself. The mapping, SSL, and routing are free on all tiers.
The source is on GitHub. Try managed hosting or self-host. Either way, it's yours.
Related Articles
Three Tiers, Docker, and What Changed
Existing subscriptions are now Hobby. Plus and Pro add more resources and Docker access inside workspaces. Here's what changed and why.
Your Tools, Your Keys, Your Models
Twelve AI coding tools built-in. Authenticate with your own API keys and talk directly to the providers. Nothing is proprietary.
Who Owns Your Dev Environment?
Cloud dev environments are convenient until the vendor changes their mind. Owning your environment means your workflow survives regardless.