How do you connect a domain to a VPS?
You add one DNS record, called an A record, at wherever your domain's DNS is managed, and you point it at your VPS's IP address. That single change is what tells the internet "this name lives here." Everything else in this guide is detail around that one step: getting the right IP, covering the www version too, and confirming the change actually spread before you assume something is broken.
If you have not read our broader piece on how domains, DNS, and hosting fit together, it is worth a look first, since it covers the concepts this post assumes you already have straight. Here we are focused purely on the mechanical steps for a VPS specifically.
What is an A record, and what do you actually enter?
An A record has two parts that matter to you: a name, which is the part of the domain the record applies to, and a value, which is the numeric IP address it points at. For your bare domain, the name is usually left blank or set to @, and the value is your VPS's IP address, which you will find in your hosting provider's dashboard, usually right on the server's overview page.
Go find your VPS's IP address before you touch DNS at all. It is easy to guess wrong or copy an old address, and every problem later in this process traces back to that one value being correct.
Should you point www too?
Yes, almost always. People type both yoursite.com and www.yoursite.com out of habit, and if only one works, you will get confused messages from visitors and possibly broken links from anywhere that assumed the other version. Add a second A record with the name set to www, pointing at the same IP address, or add a CNAME record that aliases www to the bare domain instead. Both approaches work, and most hosting setup guides tell you which one they expect for whatever software you are about to install.
Where do you actually make this change, registrar or host?
Wherever your domain's nameservers currently point, which is not always where you bought the domain. If you bought the domain and are using its default DNS management, you edit records at the registrar. If you have pointed the domain's nameservers at a different provider, you edit records there instead, and the registrar's own DNS page will show nothing useful.
This trips people up constantly. If you make a change and nothing happens no matter how long you wait, the first thing to check is not the record itself, it is whether you edited DNS in the place your domain is actually listening to.
How long does propagation actually take?
DNS answers get cached at points all over the internet, and those caches expire on their own schedule, so a change you make does not appear everywhere instantly. Often it is minutes. Sometimes, particularly for a domain that has not changed in a long time, it takes a few hours. Genuinely long delays, a full day or more, are rare but not impossible, and usually trace back to a very high TTL value set on the record before you touched it.
The first time I pointed a domain at my own VPS, I refreshed my browser about fifteen times in ten minutes convinced I had broken something, when the change simply had not spread yet. Patience saves a lot of unnecessary troubleshooting here.
How do you check that it actually worked?
Do not trust your own browser as the first check, since it caches DNS answers locally and can keep showing you the old result even after the rest of the internet has updated. Instead, use a site like whatsmydns.net, which checks your domain from many locations at once and shows you exactly what each one currently sees.
If you are comfortable with a terminal, running dig yoursite.com gives you the same answer directly, showing the IP address currently returned for your domain. Compare that number to your VPS's actual IP address. If they match, your DNS is correct and any remaining issue is on the server side, not the domain side.
What mistakes should you watch for?
Beyond forgetting www and editing DNS in the wrong place, the other common one is confusing DNS working with your site working. A correct A record only gets a visitor's browser to your server. If nothing is actually listening there yet, no web server installed, no site deployed, they will still see an error, just a different kind. Confirm your web server or app is actually running on the VPS separately from checking DNS, since debugging both at once tends to waste time chasing the wrong problem.
It also helps to lower your DNS record's TTL a day before a planned change, if you can, so future edits propagate faster. It is a small step that pays off the next time you need to move something quickly.
What about subdomains, like an app or staging site?
The same A record pattern extends to subdomains, and this is where a VPS starts to feel more flexible than shared hosting. Want app.yoursite.com to point at a different service running on the same server, or a different server entirely? Add another A record with that subdomain as the name and whichever IP address you want it to reach. Each subdomain is just another entry in the same phone book, pointing wherever you tell it to.
This is genuinely useful once you are running more than one thing. On my own VPS I use subdomains to separate a couple of small tools from the main site, each one just a different A record and a bit of routing on the server side. You do not need to plan all of this out up front, you can add subdomains one at a time as projects come up.
What should you expect the first time you do this?
Expect it to feel anticlimactic. You add one or two records, wait, and then a browser eventually shows your site instead of an error. There is no dramatic confirmation step, no email telling you it worked, just the quiet moment where a lookup tool agrees your domain now points where you wanted. That is normal, and it is exactly what success looks like here.
If it has been well over a few hours and a lookup tool still shows the old value everywhere, stop and re-check the basics first: the correct IP address, the correct place you are editing DNS, and whether you saved the change at all. Nine times out of ten the fix is one of those three, not a deeper propagation problem.
Next step: once your domain is pointed correctly, the next question is usually what to actually put on that server. Our learn AI hub has more beginner guides on hosting, DNS, and getting a first project running.
