A custom domain is a domain name that the developer owns and points at their own service, instead of a subdomain that the platform gives them for free. The free subdomain is your-app.platform.com. The custom domain is your-app.com. The first is on someone else’s domain, the second is on the developer’s own domain. The custom domain is the part of a real product that the developer owns, and the part of a real product that survives a platform change.
The reason “what is a custom domain” is its own question and not just “a domain” is that the term covers the registrar (the place you buy the domain), the DNS (the system that points the domain at your service), the TLS certificate (the part that makes the browser show a green padlock), and the platform’s settings (the part that says “yes, this domain points at this service”). The four pieces are the answer. The four pieces are the part most tutorials skip.
Table of contents
- The short version
- The four pieces a custom domain is actually made of
- The three reasons a custom domain is worth the cost
- The five-step flow to put a custom domain on a service
- The four DNS record types a developer needs to know
- The mistakes that quietly break a custom domain
- FAQ
The short version
A custom domain is a domain the developer buys from a registrar (Namecheap, Cloudflare Registrar, Google Domains, Porkbun, GoDaddy), points at their service using DNS records (A, AAAA, CNAME, ALIAS, or NS), and configures on the platform that hosts the service (so the platform knows which service the domain is for). The flow is “buy, point, configure, verify, ship.” The four steps are the same regardless of the platform, the registrar, or the kind of service.
The four pieces a custom domain is actually made of
The custom domain looks like one thing from the outside — a name in the browser’s address bar — but it is four distinct pieces. The pieces are owned by four different parties, and the developer who has not learned the four pieces is the developer who is going to spend an hour debugging a DNS propagation issue.
The registrar. The registrar is the place the developer buys the domain. The registrar holds the registry record that says “this domain is owned by this person.” The developer can transfer the domain to a different registrar without changing the DNS, the platform, or the service. The major registrars are Namecheap, Cloudflare Registrar, Google Domains (now Squarespace Domains), Porkbun, GoDaddy, and Hover. The cost is on the order of $10–20 per year for a .com, more for premium TLDs.
The DNS. The DNS is the system that maps a domain name to an IP address (or to another domain name). The DNS is run by nameservers, and the nameservers are usually provided by the registrar or by a third-party DNS service (Cloudflare DNS, Route 53, DNSimple, etc.). The DNS records are the actual instructions — “this domain points at this IP” or “this subdomain points at that other domain.” The DNS is the part that the developer configures when they want to point the domain at their service.
The TLS certificate. The TLS certificate is the file that proves the domain is who it says it is, and that enables the browser’s green padlock (or the absence of a red warning). The certificate is issued by a Certificate Authority (Let’s Encrypt, DigiCert, Sectigo, etc.) and is renewed periodically. Most modern platforms issue and renew the certificate automatically, and the developer does not have to manage it directly.
The platform’s domain settings. The platform that hosts the service has a place in the dashboard to declare which custom domains point at the service. The platform uses this declaration to route incoming requests to the right service, and to issue the TLS certificate. The developer has to add the custom domain to the platform’s settings, and the platform has to verify that the developer owns the domain (usually by checking for a DNS record or an HTTP file).
The four pieces are not owned by the same party, and the developer who has not learned the four pieces is the developer who is going to be surprised when “the domain is configured” means four different things on four different consoles.
The three reasons a custom domain is worth the cost
A custom domain costs $10–20 per year, plus the developer’s time to set it up. The cost is small, but the cost is not zero. The three reasons the cost is worth it are:
Brand and trust. A service on your-app.platform.com is a service that looks like a prototype. A service on your-app.com is a service that looks like a product. The difference is the difference between a link a customer is willing to click and a link a customer is going to forward to a friend. The custom domain is the part of the product that says “this is a real company.”
Portability. A service on a free subdomain is a service that breaks when the developer changes platforms. The custom domain is the part that survives the platform change — the developer points the domain at the new platform, and the URL stays the same. The free subdomain is a leash. The custom domain is freedom.
Email and identity. A custom domain is the prerequisite for a custom email address ([email protected]). The custom email is the part of the business that survives the platform change, the team change, and the tool change. The custom domain is the part of the business that the developer owns outright.
The three reasons are not exhaustive. There are also reasons of analytics (the developer’s own tracking, not the platform’s), reasons of SEO (search engines trust custom domains more than free subdomains), reasons of legal compliance (a real business needs a real domain), and reasons of professional appearance (a gmail.com email is a hobby; a custom-domain email is a business). The three are the floor of what the developer should know.
The five-step flow to put a custom domain on a service
The flow to put a custom domain on a service is the same regardless of the platform, the registrar, or the kind of service. The five steps are:
Step 1: buy the domain. Pick a registrar, search for the domain, add it to the cart, and pay. The developer should pick a registrar that has good DNS support (Cloudflare Registrar is free at cost, Namecheap is well-known, Porkbun is fast, Google Domains is now Squarespace Domains). The developer should also turn on auto-renew, so the domain does not expire under the project.
Step 2: add the domain to the platform. In the platform’s dashboard, find the project, find the “Custom domains” or “Domains” section, and add the domain. The platform will tell the developer what DNS records to set. The platform will also start the verification process — the platform will check that the developer owns the domain by looking for a specific DNS record or HTTP file.
Step 3: set the DNS records. In the registrar’s DNS panel, add the records the platform told the developer to add. The records are usually an A record (for the apex domain) or a CNAME record (for subdomains), and sometimes a verification record. The records propagate across the internet in seconds to hours, depending on the TTL.
Step 4: wait for verification. The platform will verify the domain once the DNS records have propagated. The verification is usually automatic, and the developer will see a “Verified” or “Active” status in the platform’s dashboard. If the verification fails, the developer should check the DNS records, the TTL, and the platform’s logs.
Step 5: force HTTPS and ship. Once the platform has issued a TLS certificate (which is usually automatic), the developer should turn on “Force HTTPS” or “Always use HTTPS” in the platform’s settings. The platform will redirect all HTTP traffic to HTTPS, and the green padlock will appear in the browser. The custom domain is live.
The five steps are the same for a static site, a web service, a WordPress install, or a backend API. The DNS records are the only thing that changes, and the developer should know the four record types below.
The four DNS record types a developer needs to know
The DNS is the system that maps a domain to an IP, and the developer has to set at least one record to make the custom domain point at the service. The four record types that show up in real custom-domain setups are:
A record. Maps a domain to an IPv4 address. The format is host: @ (or the subdomain), value: 1.2.3.4 (the IP), TTL: 3600 (1 hour). The A record is the one the developer uses for the apex domain (your-app.com), because CNAMEs are not allowed at the apex by DNS spec.
AAAA record. Maps a domain to an IPv6 address. Same format as A, but the value is an IPv6 address (e.g. 2001:db8::1). Most modern platforms support both, and the developer should add both for full coverage.
CNAME record. Maps a domain to another domain name. The format is host: www (or the subdomain), value: your-app.platform.com (the target), TTL: 3600. The CNAME record is the one the developer uses for subdomains (www.your-app.com, app.your-app.com), because it is easier to change than an A record and the target is usually a load balancer that may have multiple IPs.
ALIAS (or ANAME) record. A non-standard record that behaves like a CNAME at the apex. Cloudflare’s CNAME flattening is the same idea — the apex can be set to point at another domain, and the DNS resolver returns the A record of the target. The ALIAS record is the one the developer uses for the apex domain when the target is a load balancer, because the load balancer’s IP can change.
The four record types are not the only ones — there are also MX (for email), TXT (for verification and SPF), NS (for delegating DNS to another provider), and SRV (for service discovery) — but the four are the ones the developer needs to know to set up a custom domain on a service. The pattern is “use CNAME for subdomains, use A (or ALIAS) for the apex, and use TXT for verification.”
The mistakes that quietly break a custom domain
A short, opinionated list of mistakes that have actually broken real custom domains in production. None of them are dramatic. They are the boring ones.
The DNS record points at the wrong target. A developer who pastes the wrong IP or the wrong CNAME target is a developer who is going to spend an hour debugging a domain that points at a parking page. The fix is to double-check the target against the platform’s instructions, and to use a CNAME for subdomains to avoid hard-coding IPs.
The TTL is set too high. A developer who sets the TTL to 86400 (24 hours) is a developer who is going to wait 24 hours for any DNS change to propagate. The fix is to set the TTL to 300 (5 minutes) during setup, and to raise it to 3600 (1 hour) or higher once the domain is stable.
The verification record is missing. A platform that asks for a TXT record to verify the domain, and the developer forgets to add it, is a platform that is going to refuse to issue the TLS certificate. The fix is to add every record the platform asks for, and to check the platform’s “Verify” or “Check” button after the records have propagated.
The apex and the www are not both configured. A developer who configures your-app.com but forgets www.your-app.com is a developer whose customers will hit a “site not found” page half the time. The fix is to add both, and to redirect the www to the apex (or vice versa) using a 301 redirect.
The TLS certificate is for the wrong domain. A platform that issues a certificate for your-app.com but the developer is also serving www.your-app.com is a platform that is going to show a certificate warning on the www version. The fix is to add both domains to the platform’s settings, and to wait for the platform to reissue the certificate with both names.
The domain is not auto-renewed. A developer who turns off auto-renew is a developer whose domain is going to expire under the project. The fix is auto-renew, and a calendar reminder to check the renewal status every year. A domain that expires is a domain that can be bought by someone else, and the project loses the URL.
How this fits the rest of the stack
A custom domain is rarely the whole project. The custom domain usually points at a service, a static site, a database admin, or a documentation site. The platform that handles the custom domain should make the rest of the stack feel like part of the same conversation.
The services layer is the part of the platform that runs the API the custom domain points at. The database layer is the part that holds the data the API serves. The static layer is the part that hosts the marketing site the custom domain also points at. The environment variables are the part that holds the secrets the platform needs to issue the TLS certificate.
A custom domain on a platform where the service, the database, the storage, the static site, the secrets, and the TLS are all in the same console is a domain the team is going to be able to manage. A custom domain on a platform where each piece is in a different console is a domain the team is going to spend the first hour just opening the right tab.
For a team that wants to see the full cost of the project before it commits, the RunxBuild hosting calculator shows the line items together. The service, the database, the storage, the static site, the domain, the TLS — each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
FAQ
What is a custom domain?
A custom domain is a domain name that the developer owns (bought from a registrar) and points at their own service, instead of a subdomain that the platform gives them for free. The free subdomain is your-app.platform.com. The custom domain is your-app.com. The first is on someone else’s domain, the second is on the developer’s own domain.
How much does a custom domain cost?
A .com is on the order of $10–20 per year. A .io or .co is on the order of $30–50 per year. A .dev is on the order of $15–20 per year. A premium TLD (a single-word .com, a category-killer TLD) is on the order of hundreds to thousands of dollars per year, sometimes with a one-time premium. The cost is recurring, and the developer should turn on auto-renew.
What is the difference between a domain and a subdomain?
A domain is the apex (your-app.com). A subdomain is a child of the apex (www.your-app.com, app.your-app.com, api.your-app.com). The developer can buy one domain and create as many subdomains as they want, and the subdomains are free. The custom-domain setup is the same for both — the developer adds the record, the platform verifies, the TLS certificate is issued.
What is a CNAME record?
A CNAME record maps a domain to another domain name. The format is host: www (or the subdomain), value: your-app.platform.com (the target). The CNAME record is the one the developer uses for subdomains, because it is easier to change than an A record and the target is usually a load balancer that may have multiple IPs.
What is an A record?
An A record maps a domain to an IPv4 address. The format is host: @ (or the subdomain), value: 1.2.3.4 (the IP), TTL: 3600. The A record is the one the developer uses for the apex domain (your-app.com), because CNAMEs are not allowed at the apex by DNS spec. The ALIAS record is a non-standard alternative that behaves like a CNAME at the apex.
How long does it take for a new domain to start working?
The DNS propagation is usually seconds to minutes for a low TTL, or up to 48 hours for a high TTL. The platform’s verification usually takes a few minutes after the DNS has propagated. The TLS certificate is usually issued within minutes of verification, and the green padlock appears in the browser immediately. The full setup is usually done in under an hour, and often in under 10 minutes.
Can I use one domain for multiple services?
Yes. A single domain can have many subdomains, and each subdomain can point at a different service. app.your-app.com can point at the API, www.your-app.com can point at the static site, db.your-app.com can point at the database admin. The pattern is the right answer for a project that has multiple services, and the platform should make the subdomain-to-service mapping easy to set up.