While most startups spend hundreds or even thousands on cloud computing, we took a different approach with WorkHub.so. Our location discovery platform for remote workers and students runs on just $2 per month. Here’s how we did it, and why you might want to consider this approach for your next project.
The Cloud Conundrum
Cloud hosting has become the default choice for startups. Services like AWS, Google Cloud, and Vercel promise effortless scalability, global infrastructure, and minimal operational overhead. With just a few clicks, you can deploy an app to users worldwide without worrying about hardware maintenance.
But convenience comes at a cost.
While free tiers make it easy to get started, hosting expenses can quickly spiral out of control as your app grows. A modest $20/month bill can balloon into hundreds as you add features and users. For bootstrapped projects, this creates a technical challenge: how do you scale affordably while maintaining performance?
WorkHub.so faced this exact problem. We needed a platform that could:
- • Handle user-generated content and location data
- • Process GIS queries and server-side rendering efficiently
- • Scale gradually without incurring significant costs
- • Maintain reasonable latency for initial users
Instead of accepting standard cloud infrastructure costs, we took an unconventional approach: self-hosting on a used $250 M1 Mac Mini.
Real-World Performance
The results have far surpassed expectations. A couple weeks after the initial launch the app went viral on r/selfhosted, with a post garnering 350k views in just 48 hours. This surge stress-tested the application significantly but never pushed CPU utilization beyond 50%.
However, the viral traffic exposed scaling challenges that required attention over subsequent months. Key issues included the rising costs of third-party APIs like Google Maps, the lack of ARM support for the postGIS docker image, and the absence of a robust monitoring infrastructure. All of these (and others) were known about, but were not part of the initial MVP plan. These lessons shaped ongoing improvements to ensure better scalability and cost management moving forward. For example, we placed google maps functionality behind authentication, created our own arm64 postGIS docker image, added Redis caching and improved the performance of Postgres queries, and implemented a robust (self-hosted monitoring infrastructure stack).
After performance optimizations were completed, k6 load testing revealed the M1 Mac Mini could handle 1,500 - 2,000 queries per second for server-side rendering (SSR) and common API endpoints before resource limits became a bottleneck.
So How Did We Build This?
Building a self-hosted platform like WorkHub.so required piecing together a lean yet robust tech stack, tailored for low-cost scalability. Here’s how we approached it:
Operating System
Initially, the server ran MacOS, however we migrated to running native Linux, which freed up a ton of system resources that had been hogged by MacOS. For example, running headless Linux nearly doubled the available RAM which allowed us to horizontally scale our services across multiple instances and standup a monitoring stack. The migration process involved installing Fedora Asahi Linux, a distribution specifically designed for Apple Silicon, which provided better resource efficiency and compatibility with server tooling (step-by-step guide here).
Cloudflare Zero Trust Tunnel
Security was another critical focus. To expose the server securely to the public internet without opening router ports directly, we set up a Cloudflare Zero Trust Tunnel. This approach not only protects against malicious traffic but also simplifies remote access management (learn how to do that here).
Monitoring and Observability
For monitoring and observability, we implemented a self-hosted monitoring stack using Grafana, Prometheus, and Loki. This setup provides real-time insights into resource usage, traffic patterns, logs, and system health, helping us stay ahead of potential issues (step-by-step guide here).
Keeping Options Open
For containerization, we used Docker, ensuring efficient resource utilization and options for future scalability. Each service runs in its own container, ARM-optimized for lightweight performance. If we ever need to migrate to the cloud, that process should be straightforward. (detailed tech stack here).
Each component of this stack was chosen to balance cost efficiency with reliability while leaving room for future scaling if needed. If you’re curious about specific implementation details or want to replicate parts of this setup, check out the linked guides for deeper dives into each area.
Challenges and Trade-offs
While self-hosting offers significant cost savings, it comes with trade-offs that fall into three main categories:
Operational Overhead
- Manual Configuration: Setting up and maintaining the server requires more time and effort compared to cloud platforms, which handle much of this automatically.
- Backup and Recovery: You’re responsible for implementing custom backup solutions to safeguard data and ensure recoverability.
- Security Management: Managing the OS, network, SSL certificates, and firewall configurations is entirely your responsibility.
Scalability and Resource Constraints
- Fixed Hardware Limits: With only 8GB of RAM, careful optimization is needed to ensure smooth performance under load. Scaling beyond this requires additional hardware or migration to a cloud provider. Viral traffic that exceeds the resources of the server would cause disruption to the service.
- Single Point of Failure: Without redundancy, downtime is inevitable during server restarts or hardware issues. For example, the power went out on our street for a few hours: our server was down till the power came back on.
- Latency for Global Users: Without a global CDN or edge computing, geographically distant users may experience higher latency.
Suitability for Growth
- Limited Scalability: While sufficient for small projects or MVPs, this setup may not suit production-grade applications requiring rapid scaling or high availability.
- Higher Risk Tolerance Required: The lack of built-in failover mechanisms means stability could be compromised in the event of unexpected issues.
These trade-offs are manageable for small projects or MVPs but may not suit every application. For WorkHub.so, the limitations are acceptable given the project’s current scale and cost-saving goals. However, self-hosting might not be ideal for projects requiring strict uptime guarantees or large-scale user bases.
The Low Cost Growth Strategy
However, instead of rushing to scale, this ultra-lean approach allows for patient growth:
- Focus on product quality without cost pressure
- Let SEO naturally build over time
- Iterate based on real user feedback
- Nurture organic growth through word-of-mouth
- Reduce pressure to monetize or raise money till product-market fit is found
- Consider cloud migration only when user growth justifies the cost
The True Cost Breakdown
| Cost Category | Cloud Hosting | Self-Hosted M1 Mini |
|---|---|---|
| Compute | $20-30/month | $250 (one-time) |
| Database | $15-20/month | Free |
| Storage | $5-10/month | Free |
| Data Transfer | Variable* | Free |
| Electricity | Free | $1-5/month |
| Monthly Total | $40-60+ | $3-ish |
| Yearly Total | $480-720+ | $24 + $250 (first year) |
When to Consider This Approach
Self-hosting might be right for your project if:
- You’re building an MVP and not yet focused on getting users
- You’re building something that needs time to find product-market fit
- Your business model requires scale to monetize, and you don’t yet have that scale.
- You’re comfortable with basic server administration
- You’re building multiple side projects and are price sensitive
- You want to focus on product development without cost pressure
When this might not be the best approach
To be clear, I am not advocating for everyone to self-host their application. This approach is not for everyone and is not without its trade-offs. This might not be the best approach for you if:
- You need to scale quickly
- You need to support a large number of users
- Stability is of a higher priority than cost
- You have revenue that can cover cloud costs
Looking Forward
This low-cost setup allows us to keep WorkHub.so online indefinitely while experimenting with new features without financial strain. If WorkHub.so gains significant traction, the containerized architecture makes it straightforward to migrate to cloud services. By then, the revenue model should support the increased infrastructure costs.
And if the project doesn’t reach the scale we hope for? With just $2 in monthly operating costs, there’s no pressure to shut it down. This minimal overhead means we can maintain the service for years, allowing for long-term experimentation and gradual organic growth without the anxiety of mounting cloud bills.
Have you tried self-hosting your projects? I’d love to hear about your experiences or answer any questions about our setup here.
