One Big Server Is Probably Enough: Why You Don't Need the Cloud for Most Things

In the world of software engineering, there’s an unspoken assumption that scaling means going distributed. That growth requires Kubernetes clusters spanning multiple regions. That "production-ready" means a fleet of microservices orchestrated by expensive cloud infrastructure.

But here’s the thing: most of us don’t need any of that.

The servers available today are so powerful, so reliable, and so affordable that a single well-configured machine can handle workloads that would have required an entire data center just 15 years ago. Yet we’ve been conditioned by cloud marketing and industry trends to over-engineer our infrastructure from day one.

Let’s talk about why one big server is probably enough for your application - and how you can save thousands of dollars while ke…

But here’s the thing: most of us don’t need any of that.

Let’s talk about why one big server is probably enough for your application - and how you can save thousands of dollars while keeping things simple.

Modern Servers Are Absolute Beasts

The server hardware available today is nothing short of remarkable. A single modern server can deliver:

128+ physical cores (256+ threads) with AMD EPYC or Intel Xeon processors
512 GB to 2 TB of RAM in standard configurations
100+ Gbps network throughput
Millions of IOPS with NVMe SSDs
Petabytes of storage capacity

To put this in perspective: a single server today would have topped the TOP500 supercomputer list in the early 2000s. Each CPU core is substantially more powerful than what was state-of-the-art a decade ago, with wider computation pipelines, larger caches, and better memory bandwidth.

What Can One Server Actually Handle?

The benchmarks speak for themselves:

Workload	One Server Capability
HTTP requests (nginx)	500,000+ requests/second
PostgreSQL queries	70,000+ IOPS
NoSQL database (ScyllaDB)	1,000,000+ IOPS
Video streaming	400-800 Gbps
Video encoding (x264)	75 FPS at 4K
Linux kernel compilation	Under 20 seconds

For most web applications serving under 10,000 queries per second, one server is more than enough. For simpler services, you could push that to millions of QPS. Very few web services get traffic at that scale - and if you have one, you already know it.

The Reliability Revolution

Here’s something that’s often overlooked: modern servers are incredibly reliable.

Hardware Reliability

Enterprise-grade servers today come with:

ECC memory that automatically corrects bit errors
Hot-swappable components for drives, power supplies, and fans
Redundant power supplies as standard
RAID configurations for disk redundancy
IPMI/iDRAC/iLO for out-of-band management
Hardware monitoring that predicts failures before they happen

The Mean Time Between Failures (MTBF) for modern enterprise hardware is measured in years, not months. With proper monitoring (which you’re doing with OneUptime, right?), you’ll typically know about issues before they cause downtime.

Software Reliability

Linux has become rock solid. Uptime of 2-3 years without reboots is not uncommon. Tools like:

systemd for service management and automatic restarts
Docker for container isolation and easy rollbacks
Kubernetes (even single-node) for self-healing workloads
ZFS or Btrfs for data integrity and snapshots

These make it easier than ever to run reliable services on a single machine.

Docker Compose: 99.99% of What You Need

For most applications, Docker Compose provides everything you need:

version: '3.8'
services:
app:
image: your-app:latest
restart: always
deploy:
resources:
limits:
cpus: '32'
memory: 64G
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 30s
timeout: 10s
retries: 3

postgres:
image: postgres:16
restart: always
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password

redis:
image: redis:7-alpine
restart: always
command: redis-server --appendonly yes

volumes:
postgres_data:

With Docker Compose, you get:

Service orchestration with dependency management
Automatic restarts when services crash
Health checks to ensure services are actually working
Resource limits to prevent runaway processes
Easy updates with zero-downtime deployments
Consistent environments across development and production

This is simpler to understand, debug, and maintain than any Kubernetes cluster. And for most workloads, it’s just as capable.

Single-Node Kubernetes: When You Want More

If you need more orchestration capabilities - like rolling updates, better secrets management, or you’re planning to scale horizontally someday - a single-node Kubernetes setup is remarkably effective.

MicroK8s or K3s

Both MicroK8s and K3s run perfectly on a single node:

# MicroK8s installation
sudo snap install microk8s --classic
microk8s enable dns storage ingress

# K3s installation
curl -sfL https://get.k3s.io | sh -

You get all the benefits of Kubernetes - declarative configuration, rolling updates, service discovery, secrets management - without the complexity of managing a multi-node cluster.

What Single-Node K8s Gives You

Self-healing workloads that restart automatically
Declarative configuration with version control
Easy horizontal scaling when (if) you need it later
Ingress controllers for sophisticated routing
Helm charts for easy deployment of complex applications
Future-proofing if you ever need to scale out

The key insight is that Kubernetes was designed to manage distributed systems, but it works perfectly well on a single node. You can run OneUptime’s entire stack - Postgres, Redis, Clickhouse, and all our services - on a single MicroK8s node.

The Real Cost of Cloud

Let’s talk numbers. Cloud providers don’t want you to do this math, but we will.

AWS vs. Renting a Server

Configuration	AWS (m6a.metal)	Hetzner Dedicated	OVHCloud HGR-HCI-6
CPU Cores	96 physical	32 physical	128 physical
RAM	768 GB	128 GB	512 GB
Network	50 Gbps	1 Gbps	50 Gbps
Monthly Cost	~$6,055	€140 ($150)	~$1,318

That’s a 40x price difference between AWS and Hetzner for a capable server. Even the beefier OVHCloud option is 4.5x cheaper than AWS.

AWS vs. Colocation (Owning Your Hardware)

Renting dedicated servers is one option, but colocation—where you buy your own hardware and pay a facility to rack and power it—can be even more economical for long-term deployments.

Cost Factor	AWS (m6a.metal)	Colocation
Hardware (128 cores, 512GB RAM)	Included	~$40,000 one-time
Monthly Infrastructure	~$6,055	~$500-800 (power, cooling, bandwidth)
Year 1 Total	~$72,660	~$46,000-49,600
Year 2 Total	~$145,320	~$52,000-59,200
Year 3 Total	~$217,980	~$58,000-68,800
5-Year Total	~$363,300	~$70,000-88,000

The math is stark:

Break-even vs. AWS: About 8 months
5-year savings: $275,000-$293,000 per server
Break-even vs. renting: About 30 months (but you own the hardware)

Yes, buying servers has drawbacks:

Upfront capital expenditure
Responsibility for hardware failures
Need to plan capacity ahead of time
Hardware depreciation

But for stable, predictable workloads, the savings are enormous. At OneUptime, we moved to colocation and saved over $230,000 per year—and that’s with a conservative calculation.

The Cloud Premium

Cloud providers charge a premium for:

Convenience - Easy provisioning and scaling
Managed services - Databases, load balancers, etc.
Global presence - Multiple regions and availability zones
Their profit margins - Cloud is a business, after all

For most startups and small-to-medium businesses, you’re paying for features you don’t need. How many companies actually need:

Multi-region deployment?
Auto-scaling to handle 100x traffic spikes?
99.999% SLA (vs. 99.99%)?

The honest answer: very few.

Serverless: The Most Expensive Option

Serverless computing seems attractive - pay only for what you use! But the math doesn’t work out:

AWS Lambda pricing: $0.20 per 1M requests + $0.0000166667 per GB-second

For a workload that could run on a $150/month server:

If you’re at 20% utilization, serverless is already more expensive
At full utilization, serverless can be 5-30x more expensive

Serverless makes sense for truly bursty, unpredictable workloads. For steady-state web applications? It’s burning money.

What About High Availability?

The main argument against single-server deployment is availability. What happens when your server goes down?

The Reality of Downtime

Here’s the thing: a single well-maintained server has pretty good uptime. With:

Redundant power supplies
RAID storage
Hot-swappable components
Proactive monitoring

You can reasonably expect 99.9%+ uptime. That’s about 8.7 hours of downtime per year.

The Primary + Backup Pattern

For most applications, a simple primary + backup configuration is enough:

Primary server handles all traffic
Backup server stays synced and ready
DNS failover or simple health-check-based routing

This gives you:

Planned maintenance without downtime
Quick recovery from hardware failures
No cloud lock-in
Costs that are still 10x less than cloud

The 2x2 Pattern for the Paranoid

If you really need high availability:

2 servers in primary datacenter/provider
2 servers in backup datacenter/provider

This handles:

Individual server failures
Datacenter-wide outages
Provider-specific issues
Correlated hardware failures (use different server models)

Even with 4 dedicated servers, you’re likely still cheaper than a single cloud region.

When Should You Use the Cloud?

To be fair, cloud infrastructure has legitimate use cases:

Good Reasons to Use Cloud

Truly global applications - If you need presence in 20+ regions
Extremely bursty workloads - ML training, batch processing
Rapid prototyping - Getting to market fast
Compliance requirements - Some industries mandate specific certifications
You don’t have ops expertise - And don’t want to hire it

Bad Reasons to Use Cloud

"That’s what everyone does" - Fashion isn’t a strategy
"We might need to scale" - Cross that bridge when you get there
"It’s more reliable" - Not necessarily true
"We don’t want to manage servers" - You’ll manage complexity either way

Common Objections Answered

"But I don’t want to hire sysadmins"

You’re going to hire them anyway - they’re just called "Cloud Ops" or "DevOps" now, and they’re more expensive. Modern servers require far less maintenance than you think, and colocation facilities handle most hardware issues.

"Cloud is more secure"

Is it though? You’re sharing infrastructure with unknown neighbors. Your data passes through systems you don’t control. With your own server, you know exactly what’s running and who has access.

"What about DDoS protection?"

Services like Cloudflare work just as well in front of dedicated servers as they do in front of cloud instances. CDNs, DDoS protection, and WAFs are all available regardless of where your origin server lives.

"We need to be able to scale instantly"

Do you? Really? How often does your traffic 10x overnight? If you’re expecting rapid growth, have a plan for adding a second server. If you’re getting genuinely massive traffic, congratulations - you have a good problem, and you can solve it then.

Conclusion

The cloud has been revolutionary for software development. It democratized access to infrastructure and enabled countless startups to launch without upfront hardware costs.

But we’ve over-rotated. We’ve accepted complexity as the price of scale, and monthly bills that dwarf what we actually need.

For most applications, one big server is enough.

Modern servers are incredibly powerful
They’re more reliable than ever
Docker Compose or single-node K8s handle orchestration
You’ll save 10-40x compared to cloud
You’ll have a simpler, more understandable system

Start simple. Scale when you need to. Don’t let the cloud hype convince you that you need 47 microservices running across 3 regions on day one.

One big server. Docker Compose. A good monitoring setup. That’s 99.99% of what most companies need.

Related Reading: