Your app is deployed. It is live, it is running, and everything works. But the URL is something like yourapp.onrender.com or something.up.railway.app. You want yourapp.com.
Adding a custom domain sounds like a five-minute job. For most developers, it takes longer, not because the process is complex, but because DNS records, SSL provisioning, and propagation delays each have their own gotchas that nobody explains upfront.
This guide walks through what is actually happening under the hood, how to add a custom domain on Kuberns in three steps, and why the same process is more involved on Render, Railway, and Vercel. By the end you will have your domain connected, HTTPS active, and a clear picture of what to do when something does not go as expected.
What Actually Happens When You Add a Custom Domain
Before touching any settings, it helps to understand what you are actually changing. Custom domain setup involves three moving parts: DNS, SSL, and your platform’s routing layer.
How DNS Connects Your Domain Name to Your Server
DNS stands for Domain Name System. It is the system that translates a human-readable domain like yourapp.com into the IP address or hostname where your app is actually running.
When you add a DNS record at your registrar, you are telling the global DNS network: “requests for this domain should go to this destination.” It takes time for that instruction to spread across DNS servers worldwide, which is why there is always a propagation delay after you make a change.
A Record vs CNAME: Which One and When
There are two record types you will encounter:
A record: maps your domain directly to an IP address. Used for apex domains like yourapp.com.
CNAME record: maps your domain to another hostname, which then resolves to an IP. Used for subdomains like www.yourapp.com.
The reason this matters is that some platforms give you an IP to point to, others give you a hostname. The record type you need depends on which one your platform provides and whether you are setting up the root domain or a subdomain.
What SSL Provisioning Means and Why It Takes a Few Minutes
SSL is the certificate that enables HTTPS. Most platforms use Let’s Encrypt to issue free SSL certificates automatically. Once your DNS record propagates and the platform can verify that your domain is pointing to it, it requests a certificate from Let’s Encrypt and installs it.
This is why you will often see “SSL pending” for a few minutes after your domain verifies. The certificate is being issued in the background. You do not need to do anything. You just need to wait.
What You Need Before You Start
Before you open your deployment dashboard, make sure you have:
- A deployed app with a live public URL
- A domain name you own and have access to manage
- Login credentials for your domain registrar
Here is where to find DNS settings on the most common registrars:
How to Add a Custom Domain on Kuberns
Kuberns keeps this as simple as it should be. There are three steps and none of them require you to figure out which record type to use or wait for a manual verification step.
If you have not deployed your app yet, the “the fastest way to get your app live without touching a single config file” is with Kuberns. Once your app is running, adding a custom domain takes under five minutes.
Step 1: Open Your App Settings and Enter Your Domain
Log in to your Kuberns dashboard, open your deployed app, and navigate to the Settings tab. Find the Custom Domain section and type in the domain you want to connect, for example yourapp.com.
Kuberns accepts both root domains and subdomains. You do not need to decide which record type to use before you get here.
Step 2: Copy the CNAME Value Kuberns Gives You
Once you enter your domain, Kuberns immediately generates a CNAME value specific to your app. Copy it. This is what you will paste into your registrar in the next step.
There is no manual IP lookup, no digging through platform documentation to find what record to add. Kuberns gives you the exact value you need.
Step 3: Add the CNAME in Your Registrar and Wait for Verification
Go to your domain registrar’s DNS settings. Add a new CNAME record with:
Name / Host: your domain or subdomain (e.g. www or @ for root)
Value / Points to: the CNAME value Kuberns provided
Save the record. Kuberns polls for the change automatically. Once DNS propagates and the record resolves correctly, Kuberns verifies the domain and provisions your SSL certificate without any extra action from you.
Your app is now live at yourapp.com with HTTPS active. The www redirect and root domain are both handled automatically.
How Other Platforms Handle Custom Domains
The process on Kuberns takes three steps. On other platforms, the same outcome requires more steps, more record types, and more waiting. Here is what that looks like in practice.
Render
On Render, adding a custom domain is a three-step flow: add the domain in the dashboard, configure DNS at your registrar, then return to the dashboard to verify. Render auto-provisions TLS certificates, which is good, but there are a few things that catch developers off guard.
Render’s Hobby plan includes only two custom domains. If you need more, you pay $0.25 per domain per month on top of your plan. Render also warns you to remove any AAAA records from your domain before configuring DNS, because Render uses IPv4 only and AAAA records cause unexpected behaviour.
If you are deploying a Node.js app on Render, the “full Node.js deployment guide that shows exactly where the domain setup falls apart on Render” walks through each step. The domain process works, but it is more manual than it needs to be for a workflow that should take minutes.
Railway
Railway’s custom domain setup requires two DNS records together: a CNAME record and a TXT verification record. Both are required before Railway will verify the domain. Miss either one and verification fails without a clear error.
Traffic on Railway is routed through their edge network, which adds an extra layer to the configuration. If you are evaluating Railway versus other options, the “why most developers eventually look for Railway alternatives” covers where teams typically run into friction.
Vercel
Vercel’s domain configuration splits into two paths depending on what you are connecting. For an apex domain like yourapp.com, you need an A record. For a subdomain like www.yourapp.com, you use a CNAME. If you want a wildcard domain, you have to switch your entire domain to use Vercel’s nameservers, which is a bigger change than most developers expect.
Vercel’s Hobby plan allows one custom domain per project. The record type split between apex and subdomain is a persistent source of confusion for developers deploying a frontend app for the first time. The “what deploying a React app on Netlify actually looks like step by step” covers a similar flow if you want to see how frontend-focused platforms approach this differently.
Why the Process Is Harder Than It Needs to Be
Each of these platforms requires you to know which record type to use, which depends on whether you are setting up an apex domain or a subdomain, which depends on how your registrar handles CNAME flattening at the root level, which most developers have never heard of.
Kuberns removes that decision entirely. You enter your domain. You get one CNAME value. You paste it. That is the whole process.
Common Errors and How to Fix Them
Even when you follow the steps correctly, things can go wrong. Here are the errors developers hit most often and what to do about each one.
Domain Not Verified After Setup
If your domain shows as unverified in the dashboard after 15 minutes, DNS propagation has most likely not completed yet. This is normal.
Check whether your record has propagated using dnschecker.org. Enter your domain and look for green checkmarks across regions. If you see partial propagation, wait another 15 to 30 minutes.
You can also flush the DNS cache in Google’s public DNS at developers.google.com/speed/public-dns/cache and Cloudflare’s at 1.1.1.1/purge-cache to speed things up.
SSL Certificate Pending or “Your Connection Is Not Private”
If your domain is verified but the browser shows an SSL warning, the certificate is still being issued. SSL provisioning through Let’s Encrypt typically takes 2 to 5 minutes after domain verification. Refresh after a few minutes and the warning should clear.
If it persists beyond 15 minutes, check whether your domain is still pointing to a different server. Conflicting DNS records from a previous setup are a common cause of SSL provisioning failures.
App Loads on www but Not on the Root Domain
This usually means you have added a CNAME for www.yourdomain.com but have no record for the root yourdomain.com. Some registrars do not support CNAME records at the root level. You will need to add either an A record pointing to your server’s IP, or an ALIAS or ANAME record if your registrar supports it.
On Kuberns, this is handled automatically. When you add a root domain, both the root and www are configured together.
502 Bad Gateway After Verification
A 502 error immediately after domain verification usually means the platform is still updating its internal routing rules to recognise the new domain. It is not a DNS issue. Your domain is correctly configured. Wait a few minutes before trying again.
DNS Propagation Taking Longer Than Expected
In rare cases, propagation can take up to 48 hours. This usually happens when the TTL on your previous DNS records was set very high, telling DNS servers around the world to cache the old record for a long time before checking for updates.
If you know you will be switching domains, lowering your TTL to 300 seconds the day before making the change significantly reduces propagation time.
**_
If you are also setting up “how to set up automatic deployments from GitHub so every push goes live without manual steps”, doing that before adding your custom domain means your app is in a stable state when the domain goes live.
_**
Conclusion
Adding a custom domain is a short process when the platform gives you what you need upfront: one record value, automatic verification, and SSL that provisions itself.
On Kuberns, that is exactly how it works. You enter your domain, copy a single CNAME value, add it to your registrar, and your app is live at your own domain with HTTPS active. No record type decisions, no plan-based domain limits, no separate SSL configuration step.
On Render, Railway, and Vercel, the same outcome requires more steps. Some need two DNS records. Some split the process based on apex versus subdomain. Some restrict custom domains to paid plans or charge per domain beyond a set limit.
The core process is the same across platforms. The difference is how much of it the platform handles for you.
If your app is not deployed yet, “what one-click deployment actually does under the hood” takes under five minutes before you even reach the custom domain step. Once it is running, you are three steps away from having it on your own domain.
Top comments (0)