You built an app. It works. Now you want people to reach it at www.yourthing.com instead of some unreadable string of numbers. This guide walks you through exactly what a URL is, what you need to buy, and how to wire everything together — no engineering degree required.
First, what actually is a URL?
A URL is just an address. The same way a street address tells a delivery driver where to bring your package, a URL tells a browser where to find a specific page on the internet.
Let's break one apart:
https://www.myapp.com/pricingThis has four pieces, each doing a different job:
https:// is the protocol. Think of it as the language the browser and the server agree to speak. https means the conversation is encrypted — nobody can eavesdrop. The older http (no "s") sends everything in plain text. Today, you always want https.
www is a subdomain. It's optional. myapp.com and www.myapp.com can point to the same place, or to different places — it's your call. Companies often use subdomains to organize things: docs.myapp.com for documentation, api.myapp.com for developer access, staging.myapp.com for testing.
myapp.com is the domain name. This is the part you purchase. It's the identity of your site — the human-readable name that maps to a specific computer somewhere in the world.
/pricing is the path. It tells the server which specific page or resource you want. Like asking for a specific department once you've walked into the building.
That's it. A URL is protocol + domain + path. Everything else is a variation on that theme.
The three things you need
Getting your app a URL involves three separate things that work together. People often confuse them because they sometimes buy them from the same company. But they are distinct:
1. A domain name — the address itself (myapp.com)
2. A host — the computer where your app actually runs
3. DNS — the system that connects the first to the second
Here's the analogy that makes it click: imagine opening a shop.
Your domain name is the address you print on your business cards — "123 Main Street." You register it so nobody else can use it. But the address alone isn't a building. You also need to rent actual space — that's hosting. And you need the postal system to know that mail sent to "123 Main Street" should be delivered to your specific building — that's DNS.
Now let's go through each step.
Step 1: Buy a domain name
You buy domain names from companies called registrars. Popular ones include Namecheap, Google Domains (now Squarespace Domains), Cloudflare Registrar, and GoDaddy. They all sell the same product. The differences are mostly about pricing, interface, and what extras they bundle in.
A few practical things to know:
You don't "own" a domain — you lease it. Domain registrations are annual. If you forget to renew, someone else can register it. Set auto-renew on, always.
Price varies by extension. A .com domain might cost $10–15/year. A .io might cost $30–50. Trendy or short domains can cost much more on the aftermarket if someone already registered them.
The extension matters less than you think. .com is still the default people assume, which gives it an edge. But .co, .app, .dev, .io, and dozens of others are perfectly legitimate. Pick what fits your brand and what's available.
Keep your registrar and your host separate (at least conceptually). Many hosting companies will also register your domain for you, which is convenient. Just understand that these are two different services. If you ever want to switch hosts, your domain comes with you — you just update where it points.
Step 2: Point your domain to your app (DNS)
This is the part that intimidates people most, but the concept is simple.
DNS stands for Domain Name System. It is, essentially, the internet's phone book. When someone types myapp.com into their browser, the browser doesn't know where that is. It asks DNS: "Hey, what's the IP address for myapp.com?" DNS answers with a number like 34.102.136.180, and the browser goes there.
Your job is to add the right entry to that phone book. You do this by creating DNS records — usually in a dashboard provided by either your registrar or a DNS provider like Cloudflare.
The two DNS records you'll encounter most:
A Record — Maps a domain to an IP address.
You're telling DNS: "When someone asks for myapp.com, send them to this specific computer at this IP address." You get this IP address from your hosting provider.
CNAME Record — Maps a domain to another domain.
Instead of pointing to a number, you're pointing to a name. "When someone asks for www.myapp.com, send them wherever myapp.com goes." This is also how many hosting platforms work: they give you a hostname like your-app.onrender.com, and you create a CNAME from myapp.com to that hostname.
Here's what it looks like in practice. Say your app is hosted on a platform that gave you the address my-app-xyz.fly.dev. You'd go to your DNS settings and add:
Type: CNAME
Name: @ (this means the root domain, myapp.com)
Value: my-app-xyz.fly.devAnd if you want www.myapp.com to work too:
Type: CNAME
Name: www
Value: my-app-xyz.fly.devThat's it. Once DNS propagates (which can take anywhere from a few minutes to 48 hours, but usually happens in under an hour), typing myapp.com in a browser will reach your app.
Step 3: Set up HTTPS (SSL certificates)
Remember the https:// at the beginning of a URL? The "s" stands for "secure." It means the connection between the user's browser and your server is encrypted. Without it, browsers show a "Not Secure" warning, which will make visitors leave immediately.
To enable HTTPS, your server needs an SSL certificate — a small file that proves your site is who it says it is and enables encryption.
The good news: you almost certainly don't need to deal with this manually. Most modern hosting platforms (Vercel, Netlify, Render, Fly.io, Railway, Cloud Run) issue SSL certificates automatically when you connect a custom domain. It just works.
If you're in a situation where you do need to handle it yourself, Let's Encrypt provides free SSL certificates, and tools like Certbot can automate the renewal process. But again, most platforms handle this for you.
The full sequence, start to finish
Let's put it all together. Here's the complete journey from "I have an app" to "people can visit myapp.com":
1. Choose and register your domain. Go to a registrar. Search for the name you want. Pay for it. Turn on auto-renew.
2. Deploy your app to a hosting platform. Your app needs to be running on a computer connected to the internet. Hosting platforms give you this. Once deployed, they'll give you either an IP address or a platform hostname (like your-app.onrender.com).
3. Add DNS records. Go to your registrar's DNS settings (or your DNS provider, if you use one like Cloudflare). Create an A record or CNAME record pointing your domain to your app's address.
4. Configure your custom domain on the hosting platform. Most hosts have a "Custom Domains" section in their dashboard. Add myapp.com there. This tells the host to accept traffic coming in for that domain and to issue an SSL certificate for it.
5. Wait for propagation, then test. Give it a few minutes (rarely more than an hour). Visit your domain. You should see your app, served over HTTPS, at the address you chose.
Common gotchas
"I added the DNS record but nothing happens." DNS changes take time to propagate. Wait an hour. If it still doesn't work, double-check that you entered the record correctly — typos in hostnames are the most common issue.
"My site works at www.myapp.com but not myapp.com (or vice versa)." You need DNS records for both. The root domain (myapp.com, often represented as @) and the www subdomain are technically different addresses. Set up records for both and configure a redirect from one to the other so users end up in the same place regardless of what they type.
"My hosting platform says my domain isn't verified." The host is checking DNS to confirm you actually control the domain. This usually means either the DNS record hasn't propagated yet, or the record values don't match exactly what the platform expects. Copy the values from their instructions precisely.
"I switched hosting platforms and my site is down." Update your DNS records to point to the new host. The old records are still sending people to the old server. DNS doesn't update automatically when you move — you have to tell it.
That's the whole picture
A URL is just an address. A domain is the name you register. Hosting is the computer your app runs on. DNS is the directory that connects the name to the computer. SSL makes the connection secure.
These are separate systems that you wire together. Once you understand that, the entire process goes from mysterious to mechanical. It's less like "programming" and more like "filling out forms in the right order."
Your app deserves a real address. Now you know how to give it one.