VPS, shared hosting or bare metal: a step-by-step guide to choosing

Hospedagem & VPS · By · Published on · Updated on · 8 min read

Aisle of server racks in a data center with overlaid cloud and infrastructure icons
Server racks with cloud icons, representing hosting and infrastructure options. Photo: bsdrouin / Pixabay

VPS, shared hosting or bare metal: which is right for your website, API or database? This practical guide walks you through comparing options, gathering requirements, sizing CPU/RAM/IO, running benchmarks and deciding safely — no magic promises, just objective, verifiable criteria.

Prerequisites and data you need to collect

Before deciding, gather information about your project. These data points drive sizing and guide tests. If something is missing, run a small pilot to learn.

Focus on four blocks: load, technical requirements, operations and budget. Without them, the choice tends to be based on gut feeling rather than evidence.

For ideas on cloud cost optimization for legacy apps, see: Reducing AWS costs for legacy applications without refactoring.

  • Current and expected traffic: peaks, schedules, and access regions.
  • Usage profiles: CPU-bound, memory, disk IO, network/egress.
  • Technologies and constraints: OS, versions, modules, need for root/privileged access.
  • RTO/RPO and desired SLA: tolerance for downtime and data loss.
  • Operations: who applies patches, monitors, runs backups and responds to alerts.
  • Approximate budget and flexibility to scale as usage grows.

Step 1 — Understand the options and when to use each

Shared hosting: multiple accounts on the same server, no root access. Simple for websites and landing pages with low resource needs and few dependencies.

VPS: a virtual machine with dedicated resources and root access. Good for APIs, web apps, queues and services that need customization and light isolation.

Bare metal (dedicated server): exclusive physical hardware. Recommended for intensive workloads, low-latency needs, demanding databases and specific kernel requirements.

If you use containers, the discussion shifts from “where to run” to “what guarantees the host provides.” See the Docker vs VMs for HA comparison for more context.

When evaluating instance sizes, check processor families and usage profiles from providers. For example, cloud providers document CPU/memory/IO characteristics per instance family.

Option How it works When to use Typical limitations
Shared hosting Multi-tenant server, no root Institutional sites, simple blogs, landing pages Limited control, resource caps, noisy neighbor variability
VPS Dedicated VM with root and virtual networking APIs, web apps, services with custom dependencies Management is your responsibility, virtualization overhead
Baremetal / dedicated Exclusive hardware, deep access Demanding databases, low latency, high predictability Higher cost and maintenance, slower provisioning

Step 2 — Measure what your system actually consumes

Size based on data, not guesses. Collect a baseline during peak hours. Avoid measuring during incidents — those numbers are misleading.

Install tools and run them for a few minutes. In production, monitor carefully to avoid affecting users.

  • CPU: average and spikes per core.
  • Memory: real usage, cache and swap.
  • Disk: IOPS, throughput and latencies.
  • Network: bandwidth and egress per minute.
  • Application: p95/p99 latencies and error rates.
# Debian/Ubuntu
sudo apt update && sudo apt install -y sysstat

# CPU e arquitetura
lscpu

# Memória
free -m

# Disco (IOPS/latência)
iostat -xm 1 5  # requer sysstat

# Espaço em disco
df -h

# (Opcional) métricas por processo
pidstat -durh 1 5

Step 3 — Isolation, security and compliance

Isolation reduces cross-workload impact and simplifies controls. On shared hosting you outsource more layers; on VPS and bare metal, more responsibility falls on your team.

Check kernel dependencies, modules and drivers. If you need specific eBPF programs, DPDK or ZFS, you’ll likely lean toward VPS or bare metal.

For APIs and authentication, review access policies and rate limits. See the guide to secure APIs with OAuth2 and rate limiting for recommended practices.

  • Who applies OS and middleware patches?
  • Is root or specific kernel modules required?
  • Legal requirements (e.g., sensitive data) and audit trails.
  • Keys, secrets and automated rotation.
  • Encrypted backups and periodic restore tests.

Step 4 — Management, automation and daily operations

More control means more tasks. Plan provisioning, deployment, observability, backups and incident response. Automate repetitive work.

If you already use CI/CD, integrate pipelines with provisioning and smoke tests. Monitor from day one.

For deployment maturity, refer to the deployment process audit and remediation plan for frequent production failures, and to the CI/CD with GitHub Actions guide for pipeline examples.

  • Infrastructure as code: standardizes and eases rollbacks.
  • Backups: policy, retention and tested restoration.
  • Observability: metrics, logs and traces from day zero.
  • Scaling: vertical vs horizontal and per-node limits.
  • Routine patching for OS, runtimes and dependencies.

Step 5 — Simple decision matrix (use as a starting point)

There’s no one-size-fits-all choice. Use signals from your context. If you’re undecided, run a quick pilot and compare numbers.

The table summarizes common trends to speed up initial screening.

Scenario Decision signal Tendency
Institutional site/blog with low traffic Low variability and no need for root Shared hosting
API with moderate spikes and custom dependencies Needs root, queues, caching and tuning VPS
Database with heavy writes and low latency needs Predictable performance and intense IO Bare metal
Tight budget and uncertain growth Need fast scale and pay-as-you-go cost VPS
Team without dedicated operations Preference for managed support Shared hosting or managed VPS

Step 6 — Run a pilot and controlled benchmarks

Create a minimal environment and generate synthetic load. Benchmarks impact servers; run them outside critical hours. Compare p95 latency, throughput and stability.

Test realistic scenarios: dynamic pages, critical endpoints and database operations. Record version, configuration and instance size for reproducibility.

  • Set targets: p95 < X ms, errors < Y%, cost within budget.
  • Vary concurrency and test duration.
  • Repeat 3 times and use the median.
  • Isolate warm-cache from cold-cache tests.
# Debian/Ubuntu
sudo apt update && sudo apt install -y wrk hey stress-ng

# HTTP benchmark (troque pela sua URL)
wrk -t2 -c50 -d30s https://seusite.tld/
hey -z 30s -c 50 https://api.seusite.tld/endpoint

# (Opcional) estressar CPU para ver degradação
stress-ng --cpu 2 --timeout 30s

Step 7 — Migration, rollback and post go-live checks

Plan the cutover with a safe window and clear communication. Have a rollback plan ready. Lower DNS TTL days before to speed up propagation.

For data, synchronize and cut over with minimal impact. For critical databases, see the strategy for zero-downtime database migration using CDC.

After launch, verify objective metrics and alerts. If targets aren’t met, roll back or adjust capacity.

  • DNS: low TTL and pre-validation.
  • Tested backups and a snapshot before the cutover.
  • Blue/green or canary deployments to reduce risk.
  • Health checks and logs without abnormal p95/p99 spikes.
  • Daily cost within planned limits; adjust if needed.

Frequently asked questions

When is shared hosting sufficient?

When the site is simple, has low traffic, no special dependencies and no need for root access. It's suitable for blogs, landing pages and institutional sites. Be aware of CPU, memory and IO limits and customization restrictions. If you outgrow it, moving to a VPS is the common next step.

VPS or bare metal for a database?

For intensive workloads with low latency and high IO, bare metal usually delivers more predictable performance. However, many databases perform well on a VPS with fast disks and proper tuning. Test with real data, monitor p95 latency and identify IO bottlenecks before deciding.

How do I estimate costs without surprises?

List the cost drivers: CPU, RAM, disk type, outbound traffic, snapshots and region. Also include backup and monitoring services. Avoid fixed universal numbers; check current provider pricing and run a pilot to validate real consumption.

Is it possible to migrate without downtime?

It depends on your architecture. Use continuous data sync, DNS with low TTL and blue/green or canary strategies. For critical databases, CDC techniques help minimize interruptions. Always have a rollback plan and validate system health before routing full traffic.

Do containers change the choice between VPS and bare metal?

Containers standardize deployment and process isolation, but they still need a host. Running containers on VPS often meets many workloads. For ultra-low latency, specialized drivers or extreme IO needs, bare metal can be advantageous. Compare using metrics and controlled tests.

Want a technical second opinion on your choice?

If you need help sizing, piloting and migrating safely, let's review your requirements and test plan before you invest.

Discuss your infrastructure

See also