A dedicated server is an entire physical machine. All of the processor, all of the memory, all of the disks, and no other tenant on the hardware. That is the whole difference from a VPS, and everything else follows from it.
What single-tenancy actually buys
Predictable performance under load. Nobody else's traffic touches your capacity, and there is no hypervisor scheduling between you and the hardware.
Hardware control. Disk arrangement, RAID level, and specific hardware requirements are yours to choose, which a VPS cannot offer because the disks are shared infrastructure.
Isolation as a documented fact. For some regulatory and contractual requirements this is the point. "No other party's workload runs on this hardware" is a statement you can make about a dedicated server and cannot make about a VPS.
Ahosting's dedicated servers start at $96.75/month.
What it costs beyond the price
The same responsibility a VPS carries, at a larger scale: patching, service configuration, monitoring, and recovery.
Plus one thing a VPS does not have: hardware. A failed disk, a failed power supply or failed memory is a physical event with a replacement window, rather than something a hypervisor migrates around. That is what RAID and remote management exist to handle, and both need setting up deliberately.
When it is genuinely the right tier
You are consistently at the ceiling of a large VPS. Measured, not assumed, and after caching and database work have been done, because those routinely free more capacity than a hardware upgrade.
The workload is sustained rather than bursty. Video encoding, large batch processing, a database that is genuinely busy all day. Virtualisation overhead and noisy-neighbour variance matter most exactly here.
You need specific hardware. A particular disk arrangement, more disks than a VPS offers, or hardware acceleration.
Single-tenancy is a written requirement. Then it is a compliance question instead of a performance one, and no amount of VPS capacity satisfies it.
When it is not
A site that is slow because it has no caching. A database with a missing index. A plugin doing something expensive on every request.
Moving those to a dedicated server makes them cheaper to ignore rather than fixed, and now there is a physical machine to maintain as well. Measure first. Scaling and upgrading your VPS goes over what to check before assuming capacity is the problem.
Managed or unmanaged
Worth settling before ordering, because it changes the ongoing work substantially.
Unmanaged means the provider supplies hardware, network and remote access. The operating system and everything above it is yours.
Managed covers some of that: typically updates, monitoring and a level of support.
An unmaintained dedicated server is worse than shared hosting: more capacity, more attack surface, and nobody patching it. If nobody on your side will own the maintenance, buy the managed option or stay on a lower tier.
What to set up in the first day
- Remote management access, tested. You need it before you need it.
- SSH keys, password logins disabled, a normal user with sudo.
- A default-deny firewall, allowing SSH first.
- Automatic security updates.
- RAID monitoring that actually alerts, and backups that leave the machine.
Provisioning and initial setup explains the order, and the first item is the one people skip until the day they cannot reach the server at all.
Before relying on a quoted uptime figure, Understanding Uptime Guarantees and What They Cover goes over what it excludes.
When a server's job ends, switching it off has an order too. There is more in How to Decommission a Server Safely.
One decision is made before any specification: where the machine will be. How to Choose a Data Centre Location goes over what actually follows from it.
There is a second arrangement that also puts a physical machine in a data centre, with a different answer to who replaces a failed disk. For that, see Colocation Versus Rented Dedicated Hardware.
Confirm the hardware matches the order
A dedicated machine is described in a specification and delivered as hardware, and the two are worth comparing on the first day.
lscpu | grep -E 'Model name|^CPU\(s\)|Thread' free -g | head -2 lsblk -o NAME,SIZE,MODEL,ROTA smartctl -a /dev/sda 2>/dev/null | grep -iE 'power_on_hours|model'
Read the processor model, the memory total and the disk type. A machine sold with fast storage that reports rotational disks is a discrepancy worth raising immediately rather than after months of poor performance.
The power on hours figure tells you whether the drives are new. A large number on a machine sold as new is a question to ask before building anything on it.
Establish the baseline before it carries anything
The only opportunity to know what the machine does when idle is before it has work.
dd if=/dev/zero of=/tmp/t bs=1M count=2048 oflag=direct 2>&1 | tail -1; rm -f /tmp/t
curl -o /dev/null -w 'indirme %{speed_download} B/s\n' -s https://speed.hetzner.de/100MB.bin
uptime
Record the results with the date. They are the comparison for every later complaint that the machine has become slow, and they cannot be taken retrospectively.
Repeat the same tests annually. A disk that has degraded, or a network path that has changed, shows as a difference against your own earlier figures rather than against a general expectation.
Single tenancy does not mean isolated
The machine is yours and several things around it are still shared.
The network is shared with other customers in the facility. The power and cooling are shared. And the provider's own management network reaches the machine, which is how remote access works.
mtr -r -c 20 8.8.8.8 2>/dev/null | tail -5 ip -s link show | head -8
That matters when diagnosing a problem that is not on the machine. Packet loss partway along the path is the provider's to resolve, and establishing that before opening a ticket changes how quickly it is dealt with.