At some point, shared hosting stops being an option. Maybe your site slows to a crawl every time another tenant on the same box gets a traffic spike. Maybe a client just signed off on a project that needs real horsepower and a level of control cPanel-on-shared-hosting was never going to give you. Either way, you’ve landed on a dedicated server, and now you’re staring at a blank Ubuntu install wondering where to even start.
This guide is that starting point. We’ll go from bare metal to a live, secured, HTTPS-protected site, in the order you’d actually do it, not the order that reads nicely in a table of contents.
What Is a Dedicated Server, and Why Choose One Over VPS or Cloud Hosting?
A dedicated server is one physical machine, and it’s yours. Not a slice of one, not a virtual instance sharing a host with a dozen strangers. Every CPU cycle, every gigabyte of RAM, every bit of disk I/O belongs to you and nobody else.
That isolation is the whole point. Anyone who’s run a site on a cheap VPS knows the feeling of watching response times crawl for no reason you can find in your own logs, and then realizing it’s someone else’s workload hammering the same host. That doesn’t happen here. You also get full root access, so kernel tuning, custom software, unusual workloads, whatever your project needs, is fair game.
| Hosting Type | Resource Sharing | Root Access | Best For | Typical Cost |
|---|---|---|---|---|
| Shared Hosting | Shared with hundreds of sites | No | Small blogs, brochure sites | $3–$15/mo |
| VPS | Virtualized slice of a shared server | Yes (within VM) | Growing sites, dev environments | $10–$80/mo |
| Dedicated Server | Entire physical machine, exclusive | Yes (full hardware) | High-traffic sites, agencies, SaaS, ecommerce | $80–$500+/mo |
| Cloud (IaaS) | On-demand virtual instances | Yes (within instance) | Variable or bursty workloads | Usage-based |
So when does it actually make sense? A few common triggers: an ecommerce store doing enough transaction volume that downtime costs real money, a SaaS product whose growth curve is genuinely unpredictable, a database that’s outgrown a shared MySQL instance, or an agency stacking a few dozen client sites on one box instead of paying for a dozen separate accounts. If none of that describes you yet, a VPS will probably do the job for less. AROIP’s dedicated server plans are aimed squarely at the point where it doesn’t anymore.
One more decision hides inside “dedicated server,” and it’s worth making consciously: managed or unmanaged. Unmanaged means you get the bare machine, and patching, hardening, and 2am troubleshooting are on you. It’s cheaper, and it’s the right call if someone on your team already knows their way around Linux. Managed costs more, but the provider handles OS updates, security, and hardware issues, which is what agencies who’d rather spend their hours on client work usually want. This guide walks through the unmanaged path, since that’s where there’s actual configuration to do, but if you go managed, most of these same steps just happen behind the scenes on your behalf.
What You’ll Need Before You Start
- A dedicated server from a provider (or hardware racked in a data center you control), with IPMI or a remote KVM console for out-of-band access
- A registered domain name with access to its DNS settings
- An SSH client (Terminal on macOS/Linux, or PuTTY/Windows Terminal on Windows)
- Basic comfort with the Linux command line. You don’t need to be an expert, just able to navigate directories and edit a file without panicking
- A rough idea of what you’re hosting. One WordPress site and a dozen client sites call for different stack decisions later on
Step 1: Choose the Right Hardware and Provider
This is the part that’s easy to rush past, but the specs you pick here set your ceiling for everything that follows.
CPU. Look at the Intel Xeon or AMD EPYC lines. For a web server, core count beats clock speed almost every time, because most requests get handled by a lightweight worker process, and more workers running in parallel matters more than any one of them being blazing fast.
RAM. 8GB gets you through a handful of low-traffic sites and not much more. 16 to 32GB is a more honest starting point if you’re running an active agency or ecommerce store. And if you’re planning to install a full control panel like cPanel on top, budget extra headroom, because the panel itself eats memory before your sites even load a page.
Storage. Pay for NVMe if you can. The latency difference versus SATA SSD is real, and it shows up fastest on database-driven sites under load. SATA SSD is a perfectly reasonable fallback for lighter workloads. Spinning HDDs still have a place, just not for anything serving live traffic; keep them for backups and cold storage.
Bandwidth. Most hosting plans run fine on a shared 1Gbps uplink with unmetered transfer. You only need to chase a guaranteed dedicated port if you’re streaming video or pushing large files at volume.
Redundancy. RAID 1 is worth having on a production box. It’s not a substitute for backups, don’t let anyone tell you otherwise, but it does mean a single failed drive doesn’t take your site down with it.
When you’re comparing providers, ask directly about IPMI or KVM access (you’ll need it the day the server won’t boot on its own), where the data center actually sits relative to your visitors, what DDoS protection is included versus bolted on as an upsell, and how fast support actually responds when hardware fails, not what the SLA says on paper. AROIP’s dedicated server lineup runs from small single-site builds up through multi-core, NVMe-backed configurations built for agencies running dozens of client sites off one box.
Step 2: Choose an Operating System
Your OS decides a lot more than it looks like at first glance: which control panels you can run, how patching works, and whether the tutorial you find at 2am when something breaks actually matches what’s on your screen.
Ubuntu Server 24.04 LTS is the safe pick for most web hosting builds right now. It’s supported into 2029, it has by far the largest community of any Linux distro, and almost every hosting tutorial on the internet assumes you’re running it. Ubuntu 26.04 LTS came out in April 2026, and yes, it’s tempting to grab the newest thing, but Canonical itself is telling production users to hold off until the first point release settles it down. Unless you have a specific reason to be on the bleeding edge, 24.04 is the one to install.
AlmaLinux or Rocky Linux make more sense if your team came up on CentOS, or if you’re running software built with a RHEL-family environment in mind. cPanel, for one, has deep roots there.
Debian trades some package freshness for rock-solid stability, which is exactly why some admins reach for it on servers they’d rather not babysit.
If this is your first time doing any of this, just go with Ubuntu 24.04 LTS. It has the gentlest learning curve of the bunch, and when you inevitably hit something confusing, the fix is usually one search away.
Step 3: Install the OS and Get Initial Access
Most providers give you two ways to get the OS on the box:
- Provider-managed installation. You pick an OS from a menu when you order, and the provider images the server before handing it over. Fastest path, and the one most beginners should take.
- Self-managed installation via IPMI/KVM. You mount an ISO through the remote console yourself, boot from it, and click through the installer: language, timezone, keyboard layout, disk partitioning, hostname, initial user.
Whichever route you take, confirm OpenSSH got installed along the way. Once the server reboots without a monitor attached, that’s your only door back in.
First login:
ssh root@your-server-ip
You’ll need the root password your provider handed you, or whatever you set during install. Once you’re in, don’t go configuring anything yet, update the system first:
apt update && apt upgrade -y
Whatever vulnerabilities were baked into the base image, this closes them before you build anything on top.
Step 4: Secure the Server Before Anything Else
This is the step people skip because they’re excited to get a site live, and it’s the one that actually matters most. Whatever configuration your provider handed you, treat it as a starting point, not a finished job.
Create a non-root user with sudo privileges. Stop working as root day to day. A typo under a limited account is annoying. The same typo as root can take down the whole machine.
adduser yourusername
usermod -aG sudo yourusername
Switch to SSH key authentication and turn off password logins. Passwords get brute-forced, eventually, by bots that don’t care whose server they’re hitting. An SSH key pair, a public half on the server and a private half that never leaves your laptop, is a different category of secure.
If you don’t already have a key pair, generate one locally:
ssh-keygen -t ed25519 -C “your-email@example.com”
Push the public key up to the server:
ssh-copy-id yourusername@your-server-ip
Then open /etc/ssh/sshd_config and set:
PasswordAuthentication no
PermitRootLogin no
Restart SSH with sudo systemctl restart ssh. Before you close your current session, open a second terminal window and confirm the key-based login actually works. If you skip this check and something’s wrong, you’ll lock yourself out with no way back in except a support ticket.
Turn on a firewall. ufw is the simplest option on Ubuntu:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
That’s SSH, HTTP, and HTTPS open, everything else closed. It’s all a typical web server actually needs.
Install fail2ban. It watches for repeated failed logins and bans the offending IP for a while. Doesn’t stop a determined attacker, but it kills most of the automated noise hitting your server every day.
sudo apt install fail2ban -y
Turn on automatic security updates, so critical patches land whether or not you remember to check:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure –priority=low unattended-upgrades
Skip any of this and you’re putting a publicly reachable machine on the internet with the doors half open. Don’t.
Step 5: Set the Hostname, Timezone, and Confirm Updates
A couple of small things that save you real confusion later:
sudo hostnamectl set-hostname yourserver.aroip.com
sudo timedatectl set-timezone America/New_York
Set the timezone to wherever your team or your audience actually is. It sounds trivial until you’re trying to correlate a log entry with a support ticket at 3am and everything’s in UTC.
Step 6: Install a Web Server Stack
From here you’re choosing between building a stack yourself (LEMP or LAMP) or letting a control panel do most of the heavy lifting.
| Stack Component | LEMP (Nginx) | LAMP (Apache) |
|---|---|---|
| Web Server | Nginx | Apache |
| Concurrency Model | Event-driven, handles high traffic with lower memory use | Process/thread-based, very mature module ecosystem |
| .htaccess Support | No (config lives in server blocks) | Yes |
| Best For | High-traffic sites, static content, reverse proxying | Sites relying on .htaccess overrides, legacy applications |
For a new build, Nginx is usually the better default. It handles a lot of simultaneous connections without eating memory the way Apache’s process model tends to, and that adds up once you’re running several sites on the same box.
Installing a LEMP stack on Ubuntu 24.04:
sudo apt install nginx mariadb-server php8.3-fpm php8.3-mysql -y
sudo systemctl enable nginx mariadb php8.3-fpm
Then run MariaDB’s security script, which strips out the default test databases and sets a real root password:
sudo mysql_secure_installation
Would rather not touch the command line for every single site? A control panel is worth the license fee, especially once you’re managing more than a couple of client accounts. cPanel/WHM is still the industry standard, with the widest ecosystem of compatible software out there. Plesk covers similar ground with a different interface and generally better Windows support.
CyberPanel, free and built on OpenLiteSpeed, has picked up a real following for what it offers at zero cost. Whatever you pick, install it before you touch Nginx or Apache manually. Panels expect to own that configuration, and they will happily overwrite whatever you set up by hand.
Step 7: Review Firewall and Network Ports
Running a control panel? It’ll want a few extra ports opened, 2083 for cPanel, 8443 for Plesk, that kind of thing. Check your panel’s docs for the full list and add each one with ufw allow <port>. Adding a mail server down the road means opening the standard mail ports too (25, 465, 587, 993, 995). The general rule: only open what you’re actually using. Every open port is one more thing somebody has to secure, and that somebody is you.
Step 8: Point Your Domain to the Server
The server’s ready. DNS just doesn’t know that yet. Log into your registrar or DNS provider and update the A record:
- Type: A
- Name: @ (or your subdomain, like www)
- Value: Your server’s public IP address
- TTL: 3600 (or your provider’s default)
Got an IPv6 address on the server? Add a matching AAAA record while you’re in there. Propagation can take anywhere from a few minutes to 48 hours depending on your registrar and the TTL that was previously set, so if the domain isn’t resolving five minutes later, that’s normal, not broken.
Step 9: Install a Free SSL Certificate
There’s genuinely no reason to serve a site over plain HTTP in 2026. Let’s Encrypt, through Certbot, gets you a valid certificate in about five minutes, for free.
sudo apt install certbot python3-certbot-nginx -y
sudo certbot –nginx -d yourdomain.com -d www.yourdomain.com
Certbot reads your existing Nginx config, provisions the certificate, and rewrites your server block to redirect HTTP to HTTPS automatically. Certificates expire every 90 days, but Certbot sets up its own renewal job during install, so in practice you never have to think about it again. Worth double-checking that renewal is actually wired up correctly, though:
sudo certbot renew –dry-run
Step 10: Deploy Your First Website
Stack’s running, SSL’s in place. Time to actually put a site on this thing. For Nginx, that starts with a server block:
sudo nano /etc/nginx/sites-available/yourdomain.com
A minimal version looks something like this:
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
root /var/www/yourdomain.com/html;
index index.php index.html;
location / {
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
}
Enable it and reload Nginx:
sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
Get your files onto /var/www/yourdomain.com/html, whether that’s an SFTP upload or a git pull if that’s how your team deploys. Load the domain in a browser, confirm it renders, and check that padlock icon actually shows a valid certificate before you call this step done.
A Few Basic Performance Tweaks Worth Making Early
A stock LEMP install works fine out of the box, but a handful of small tweaks pay off quickly once real traffic starts showing up.
PHP-FPM process management. Check pm.max_children in /etc/php/8.3/fpm/pool.d/www.conf. It’s usually left too conservative on a box with real headroom to spare, or too generous on a smaller one, which is how you end up with memory exhaustion under load. Rough starting point: available RAM divided by roughly 30 to 80MB per PHP process, depending on your application, minus whatever MySQL and the OS itself need.
MariaDB tuning. The default innodb_buffer_pool_size is almost always smaller than it should be on a dedicated box. Start around 60 to 70 percent of available RAM if the server’s mainly running one database-heavy application, then adjust based on what you actually observe. It lives in /etc/mysql/mariadb.conf.d/50-server.cnf, and you’ll need to restart the service after editing it.
Make sure OPcache is on. It caches compiled PHP bytecode so the server isn’t recompiling the same files on every request. Usually ships enabled with PHP-FPM already; run php -v and look for a mention of Zend OPcache to confirm, and bump opcache.memory_consumption in php.ini if you’re running something larger than a brochure site.
Add a caching layer once traffic justifies it. Redis or Memcached in front of the database, or a full-page cache plugin if you’re on WordPress, cuts real load once you’re past a few thousand visitors a day. Not something to worry about on day one, but worth having a plan for before traffic forces the issue on you.
None of this is urgent for a brand-new site with a trickle of visitors. It starts to matter once real concurrent users show up, so bookmark this section and come back to it after your first month live, once your monitoring actually has something to tell you.
Step 11: Set Up Automated Backups
On a dedicated server, backups are entirely your responsibility. There’s no shared infrastructure quietly handling this in the background the way there might be on managed shared hosting. At minimum, get a nightly cron job dumping your databases and archiving your web files somewhere off the physical box, an object storage bucket, a second server, whatever your provider offers. Something like:
mysqldump -u root -p yourdatabase > /backups/yourdatabase-$(date +%F).sql
tar -czf /backups/website-$(date +%F).tar.gz /var/www/yourdomain.com
Wire that into cron, and actually push the resulting files off the server. A backup sitting on the same drive as the data it’s protecting isn’t a backup. It’s just a second copy of the thing that’s about to fail with it.
Step 12: Monitor Performance and Uptime
Once you’re live, you want to hear about problems before your users start emailing you about them. Netdata or Prometheus paired with Grafana give you real-time visibility into CPU, memory, and disk on the box itself. Pair that with an external uptime check, UptimeRobot or Better Uptime both work fine, pinging your site from outside your network. That catches things internal monitoring can miss entirely, like a DNS problem or an upstream network outage that has nothing to do with the server being healthy or not.
Common Mistakes to Avoid
- Skipping the firewall setup because “I’ll do it after launch.” The server starts getting scanned the moment it’s online, launch day or not.
- Leaving root SSH login enabled indefinitely, instead of switching it off the moment the sudo user is confirmed working.
- Running everything as root out of convenience. It works right up until a small mistake becomes an expensive one.
- Never actually testing a backup restore. A backup you’ve never restored from is a theory, not a safety net.
- Installing a control panel and then also hand-editing Nginx or Apache configs. The panel will overwrite your changes the next time it runs.
How Long Does It Take to Set Up a Dedicated Server?
Following this guide with a provider-managed OS install, figure two to four hours from ordering to a live, secured, SSL-protected site, and most of that is waiting on DNS to propagate rather than active work on your end. Add a control panel, multiple sites, or an application with unusual dependencies, and that can stretch into a full day. Either way, leave yourself time to actually test things before real traffic starts hitting the box.
Frequently Asked Questions
Is a dedicated server better than a VPS for web hosting?
Depends on your traffic and your budget, honestly. A dedicated server gives you the whole machine with nothing else competing for CPU or I/O, which is the right call once you’ve got consistent high traffic, a resource-hungry application, or a bunch of client sites stacked on one box. If your workload is smaller or unpredictable, a VPS usually gets you better value for the money.
Do I need a control panel like cPanel to run a dedicated server?
No. It makes day-to-day management easier, especially once you’re juggling multiple sites, but plenty of production servers run entirely from the command line on a hand-configured LEMP or LAMP stack.
How much RAM do I need for a dedicated web hosting server?
8GB will get a handful of low-traffic sites through the day. Most active agency or ecommerce setups sit comfortably at 16 to 32GB, and anything database-heavy, or running a full control panel, wants more headroom on top of that.
Is Ubuntu or a RHEL-based distro (AlmaLinux, Rocky Linux) better for hosting?
Both work well. Ubuntu 24.04 LTS has the bigger community and the gentler learning curve, which is why it’s the practical default for most new builds. AlmaLinux or Rocky Linux make more sense if your stack, cPanel being the obvious example, is built around a RHEL-family environment, or your team’s background is in CentOS.
How do I secure a dedicated server after installation?
Non-root sudo user, SSH key authentication, root login and password auth both disabled over SSH, a firewall turned on, fail2ban installed, and automatic security updates enabled. All of that happens before a live site goes up, not after.
Can I host multiple websites on one dedicated server?
Yes, and it’s one of the main reasons agencies choose dedicated hosting in the first place. Each site gets its own server block, its own database, and its own directory. A panel like cPanel/WHM or Plesk makes managing a lot of them easier, but you can absolutely do it by hand with separate config files.
Should I test my configuration before pointing my domain to the new server?
Yes, and it’s easy to do. You can test the web server, SSL, and your application before DNS ever touches the new machine, just by editing your local computer’s hosts file to temporarily point your domain at the server’s IP. Catch your mistakes privately instead of live in front of visitors.
Conclusion
A dedicated server pays back whatever time you put into setting it up right. Get the hardware sized correctly, lock down security before anything’s public, and pick a stack that actually fits your workload instead of whatever tutorial you happened to find first.
After that, the job shifts from setup to upkeep: keeping an eye on your monitoring, making sure backups are current and actually restorable, patching on a schedule instead of when you remember to. If you’d rather skip the hardware sourcing altogether, AROIP’s dedicated server plans arrive pre-racked and ready for the OS install, so you can pick this guide back up at Step 2.
