TL;DR: This article details SaaS founder Simon Høiberg’s strategic shift from AWS to 80% self-hosted infrastructure using bare-metal servers from Hetzner and open-source tools, resulting in lower costs, reduced vendor lock-in, and greater control.
📋 Table of Contents
Jump to any section (17 sections available)
📹 Watch the Complete Video Tutorial
📺 Title: I’m leaving the cloud! (…and why you probably should too)
⏱️ Duration: 859
👤 Channel: Simon Høiberg
🎯 Topic: Leaving Cloud Why
💡 This comprehensive article is based on the tutorial above. Watch the video for visual demonstrations and detailed explanations.
For years, cloud platforms like AWS have been the go-to infrastructure for SaaS founders—offering scalability, managed services, and pay-as-you-go pricing. But what if the cloud is costing you more than it’s worth? What if vendor lock-in is putting your business at risk? And what if self-hosting—on dedicated, bare-metal servers—could actually make your product faster, cheaper, and more resilient?
In this comprehensive guide, we unpack the full journey of Simon Hoyberg, a SaaS founder running a portfolio of five tools used by over 50,000 users and nearing $2 million in annual recurring revenue (ARR). After running entirely on AWS for years, Simon moved 80% of his infrastructure to dedicated bare-metal servers hosted by a small German provider called Hetzner—using open-source software and self-managed infrastructure.
This isn’t just a cost-cutting story. It’s a strategic shift that unlocked new business models, reduced operational risk, and gave Simon true ownership over his stack. Below, we break down every detail from his real-world experiment—why he left the cloud, how he did it, what he kept on AWS, and whether you should follow suit.
Who Is This Guide For?
This guide is essential reading if you:
- Run a SaaS product with growing infrastructure costs
- Offer lifetime deals and worry about rising operational expenses
- Fear vendor lock-in from AWS, Azure, or Google Cloud
- Are curious about self-hosting but think it’s “too complex”
- Want to leverage open-source tools to reduce SaaS overhead
Background: From Fully Cloud-Native to 80% Self-Hosted
Until early 2025, Simon’s entire SaaS portfolio ran on AWS. His stack included:
- ECS and Fargate for container orchestration
- AWS Lambda for serverless functions
- AWS Amplify for frontend hosting
- DynamoDB as the primary database
- Amazon SQS for message queues
- CloudWatch for monitoring and logs
Everything was fully managed. He paid only for what he used—down to the millisecond of compute time or database read.
But by the start of 2025, his monthly AWS bill averaged $7,800—and it was climbing as his user base grew.
Fast-forward to today: 80% of his systems now run on three dedicated bare-metal servers from Hetzner, using open-source software. His new stack includes:
- Docker containers orchestrated by Kubernetes
- PostgreSQL for data storage
- Redis for caching
- BullMQ for message queues
- Prometheus and Grafana (Community Edition) for monitoring
His infrastructure cost? Now under $2,000/month—and projected to drop below $1,000/month once the final 20% migration is complete.
Why Leave the Cloud? The Top 3 Reasons
Simon identifies three compelling reasons for his move away from AWS. These aren’t just technical—they’re strategic, financial, and existential for SaaS businesses.
1. Dramatic and Scalable Cost Reduction
While $7,800/month may seem manageable for a business generating over $100,000/month in revenue, the problem lies in the unbounded cost curve. With AWS, costs rise linearly (or worse) with user growth. Every new customer adds marginal infrastructure expense.
In contrast, dedicated servers offer a fixed monthly cost. Simon pays around $200/month to Hetzner for three powerful bare-metal machines. The rest of his current $2,000 bill comes from the 20% of services still on AWS.
Yes, there was an upfront time investment—learning Kubernetes, Docker, and system administration—but Simon emphasizes: “The upfront cost is fixed. The savings are unlimited.”
After an initial spike in infrastructure work, his maintenance time returned to pre-migration levels—thanks partly to AI tools that helped accelerate his learning curve.
2. Escaping Vendor Lock-In (The #1 Business Risk)
This is Simon’s most urgent concern. AWS services like DynamoDB, Lambda, and Fargate are proprietary. They don’t exist outside AWS. If AWS:
- Raises prices dramatically
- Changes terms of service
- Decides to terminate your account
…your entire business could go offline overnight.
Migrating off AWS in an emergency isn’t feasible—it requires months of planning. As Simon puts it: “Your whole business goes in the dumpster.”
With his new open-source stack, he’s no longer locked in. His software can run anywhere—on any VPS, dedicated server, or even (as a proof of concept) on Raspberry Pis.
He actually ran one of his smaller products for two full days on three Raspberry Pis in his office. While not ideal (due to memory limits and slow internet), his users didn’t notice. This experiment proved his architecture is truly portable.
3. Enabling Lifetime Deals with Fixed Operational Costs
Simon sells access to his SaaS suite via lifetime deals—a one-time payment for perpetual access. This creates a critical problem: ongoing cloud costs rise with user growth, but revenue is fixed.
If each new lifetime customer increases AWS bills, the deal becomes financially unsustainable at scale.
By moving to fixed-cost dedicated servers, Simon can:
- Accurately forecast lifetime deal profitability
- Offer stronger guarantees to customers
- Build a path toward full self-hostability
In fact, he’s now working to make all his products fully self-hostable. If his business ever shuts down, lifetime customers can install the software on their own servers—ensuring “lifetime access” truly means lifetime access.
Simon’s Self-Hosted Infrastructure: Full Technical Breakdown
Here’s exactly how Simon’s new stack is configured:
| Function | Old (AWS) | New (Self-Hosted) | Cost Model |
|---|---|---|---|
| Compute | ECS, Fargate, Lambda | Docker + Kubernetes | Open-source (free) |
| Database | DynamoDB | PostgreSQL | Open-source (free) |
| Caching | ElastiCache (implied) | Redis | Open-source (free) |
| Message Queues | Amazon SQS | BullMQ | Open-source (free) |
| Monitoring & Logs | CloudWatch | Prometheus + Grafana (Community) | Open-source (free) |
| Hosting Provider | AWS Regions | Hetzner (Germany) | Fixed monthly fee (~$200) |
All software components are open-source and free. The only recurring cost is the three dedicated servers from Hetzner.
What’s Still on AWS? The 20% He Couldn’t (Yet) Migrate
Despite his progress, Simon still relies on AWS for four critical services. Here’s why—and what he tried:
1. File Storage (Amazon S3)
Challenge: S3 is cheap, but it’s proprietary. Alternatives like Hetzner Storage Boxes or Cloudflare R2 are S3-compatible but still vendor-locked.
Solution Attempted: Simon tried MinIO—an open-source, S3-compatible object store he could self-host. He attached a 15TB HDD to his main Hetzner server and deployed MinIO.
Why It Failed:
- MinIO is designed for distributed systems (multiple nodes with replicated storage)
- Backups became complex and unreliable
- Stability issues arose (possibly due to “skill gap,” as Simon admits)
He reverted to S3—for now.
2. User Authentication (Amazon Cognito)
Challenge: Authentication is security-critical. A mistake here could compromise all user accounts.
Solution Attempted: Simon tested Keycloak—the leading open-source identity provider.
Why It Failed:
- Poor developer and user experience
- Complex Java-based architecture
- Too risky for a core security component
He returned to Cognito, prioritizing reliability over cost.
3. Edge Delivery & Security (CloudFront)
Simon uses AWS CloudFront as the public entry point for all traffic. Requests hit CloudFront first, then proxy to his Hetzner servers.
Why He Keeps It:
- CloudFront provides DDoS protection, WAF, TLS termination, and global caching
- He lacks expertise to self-host equivalent security infrastructure
4. AI Services (OpenAI, Replicate, Vast.ai)
His products use third-party AI APIs for inference. He’s exploring self-hosted AI on dedicated GPU instances but notes: “Standalone servers don’t yet have the GPU power for reliable, production-grade AI inference.”
Is Self-Hosting Right for You? The Decision Framework
Simon offers a clear framework to decide if leaving the cloud makes sense for your business:
| Your Situation | Recommendation | Reason |
|---|---|---|
| Hobby project with no growth expectations | Stay on the cloud | Use Vercel, Netlify, or Render for zero-ops deployment |
| Large-scale, mission-critical SaaS (e.g., healthcare, finance) | Stay on hyperscalers (AWS/Azure/GCP) | You need enterprise-grade SLAs, compliance, and auto-scaling |
| Mid-sized SaaS ($10K–$200K/month revenue) | Strongly consider self-hosting | Best balance of cost savings, control, and manageable complexity |
If you’re in the “middle” category, Simon insists: “It is absolutely doable to manage your infrastructure yourself. And there is serious money to be saved.”
The Hidden Bonus: Internal Tooling Savings
Beyond production infrastructure, self-hosting unlocks savings on internal business tools. Simon replaced expensive SaaS tools with self-hosted open-source alternatives—saving an additional $10,000/year.
While he references a separate video for details, this highlights a second layer of value: your self-hosted infrastructure can power not just your product, but your entire business operations.
Performance Gains: Speed and Deployment Velocity
Cost and control aren’t the only wins. Simon reports two unexpected benefits:
- Products run faster on bare-metal servers (no virtualization overhead)
- His team deploys new features faster—likely due to simplified debugging and full-stack visibility
Remaining Dependencies: Stripe and OpenAI
Even after leaving AWS, Simon acknowledges two major third-party dependencies:
- Stripe for payments
- OpenAI for AI features
He’s actively mitigating these:
- Exploring Coinbase Commerce as a Stripe alternative
- Experimenting with dedicated GPU instances from independent vendors for self-hosted AI
Lessons Learned: The Real Cost of Migration
Simon is transparent about the trade-offs:
- Time investment spiked initially—learning Kubernetes, networking, backups
- Not all open-source tools are production-ready (e.g., MinIO, Keycloak)
- Some AWS services are hard to replace without compromising security or reliability
But crucially, he stresses: “The effort doesn’t stay high forever. After the learning curve, maintenance time normalizes.”
Future Roadmap: Pushing Beyond 80%
Simon is still working to migrate the final 20%. He invites the community to share solutions for:
- Self-hosted, production-grade object storage
- Simple, secure, open-source authentication
- Affordable, self-hosted AI inference
He’s particularly interested in whether GPU-equipped dedicated servers will soon make AI self-hosting viable.
Key Takeaways: Should You Leave the Cloud?
✅ Do consider self-hosting if:
- You’re a mid-sized SaaS with predictable scale
- You offer lifetime deals or fixed-price plans
- You want to eliminate vendor lock-in risk
- You’re willing to invest 2–3 months in learning infrastructure
❌ Avoid self-hosting if:
- You’re a solo founder with zero sysadmin experience (yet)
- Your product requires massive, unpredictable scaling
- You can’t afford any downtime during migration
Action Plan: How to Start Your Migration
- Audit your AWS bill—identify top cost drivers (compute, DB, storage)
- Map AWS services to open-source equivalents (e.g., DynamoDB → PostgreSQL)
- Start with non-critical services (e.g., background workers, internal tools)
- Choose a bare-metal provider (Hetzner, OVH, Leaseweb)
- Deploy Kubernetes using k3s or kubeadm for simplicity
- Migrate in phases—keep AWS as fallback during transition
- Accept that some services (auth, edge) may stay on cloud
Final Thought: Ownership Matters
For Simon, the biggest win isn’t cost—it’s ownership. As he says: “There’s just something about that feeling that you own your setup fully.”
In an era of platform risk and unpredictable cloud pricing, self-hosting isn’t just a technical choice—it’s a business strategy. And for many SaaS founders, it might be the smartest move they ever make.
Resources Mentioned
- Hosting Provider: Hetzner
- Object Storage: MinIO
- Identity Provider: Keycloak
- Message Queue: BullMQ
- Monitoring: Prometheus + Grafana
- Alternatives: Cloudflare R2, Coinbase Commerce, Vast.ai
Over to You
Have you migrated off the cloud? Tried MinIO or Keycloak? Found a great self-hosted auth solution? Share your experience in the comments—Simon (and thousands of SaaS founders) are eager to learn from your journey.
