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…
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 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: