Hosting for Web Apps: Cloud vs. Homelab vs. Hybrid – Which Saves You Money?

Cloud providers love to promise cheap, scalable web app hosting. The reality is often far more complex. Let's cut through the marketing jargon and uncover the true cost of cloud solutions, the potential savings of a homelab, and when a hybrid approach might be your smartest move.

When "Simple" Gets Costly

Building a solid online presence is crucial in today's world, and a strong portfolio website can open doors to new opportunities. That's why I decided to create my own "Mihai @ Let's Talk Dev" portfolio website, opting for a stack using Nuxt.js, Directus CMS, and PostgreSQL. While the development went smoothly, finding the right hosting solution proved far more complicated than I anticipated.

If you'd rather watch than read, check out my video on this topic here:

Vercel: The Maze of Pricing

Initially, Vercel seemed like a great choice for the frontend. Their promises of "unlimited this" and "free that" are enticing... until you try to decipher their pricing structure. Even with experience, I found it overwhelming, and it's easy to imagine how intimidating this would be for newcomers.

One particularly obscure detail was the PostgreSQL compute time limit on their "Hobby" tier. While 60 hours per month sound generous, there's no clear definition of what constitutes a "compute hour." This lack of transparency makes it incredibly difficult to estimate your real-world costs for a web app.

Let's consider two scenarios:

• A Low-Traffic Backend: If your web app powers a small portfolio site or a simple API with infrequent queries, you might stay within the free tier.
• A Real-Time Dashboard: Now, picture a dashboard constantly polling for updates. These frequent requests, even if simple, could blow past those 60 hours in no time, landing you with a bill for each additional hour.

...And here's where I want you to think honestly: Looking at this price table, would you be able, right now, to predict with certainty how quickly your project might outgrow Vercel's free tier? Can you really say for sure which of those limits you'll hit first – the storage, the requests, or that mysterious "compute time"? Or, even, how much will your first month’s invoice be?

The Cost of Convenience: Supabase

Seeking a simpler solution, I considered Supabase. Their free tier looked promising at first. But then I hit a major snag: they sleep inactive databases, and you have to manually wake them up from the dashboard.

Now, my web app wouldn't get a ton of traffic. I could realistically see a week with no visitors. Could I really guarantee at least some activity to keep my database awake? Should I resort to automated scripts as a workaround? That seems like a hack, and suddenly, even basic availability jumps you into paid tiers.

And then there's the storage issue. Their free storage is tiny – maybe enough for a simple portfolio, but a slightly more complex project would easily exceed that limit. It seems like this would be the first hurdle forcing you into a paid tier, even if everything else about your project is small-scale. And then that next tier likely over-provisions the database to something you don't really need – the jump is just too drastic.

This made me question whether these supposedly simpler services are really as straightforward as they seem.

Digital Ocean: Better

Unlike Vercel and Supabase, which are Platform-as-a-Service (PaaS) providers, Digital Ocean takes an Infrastructure-as-a-Service (IaaS) approach. This means they focus on renting you raw resources like virtual machines ("droplets"), instead of pre-packaged web app solutions. This offers more granular control over costs compared to the often opaque tiered pricing of PaaS solutions.

So, at least with platforms like Digital Ocean, the pricing is transparent. However, their managed database options start off affordable but quickly become expensive as you need more resources. Even a modest performance boost can easily double your bill.

It's important to note that 1GB of RAM and 1 CPU core isn't really a performant database setup, especially for anything beyond a small project. And this price is just for a single node, not a cluster. On the plus side, they do include free daily backups for 7 days, which is a nice touch.

I would also need one or two droplets where I could host the Nuxt page itself and the Directus CMS. So you’re looking at upwards of $20 for a simple website like this.

Why Cloud Costs Cause Headaches

Before diving into specific pitfalls, let's understand the root of the problem with cloud hosting for many web apps:

Complexity Overload

Cloud providers offer a dizzying array of services designed for massive enterprises. For most of us, this is overkill. Think of AWS: you start needing a host (EC2), then storage (S3), a database (RDS), maybe a CDN... It's like an onion, layer upon layer of services, each with its own pricing model. This makes accurately budgeting for your web app almost impossible.

Hidden Fees

Data transfer, egress charges... ever tried to calculate the cost of moving your data off a cloud platform? It'll make you question your tech choices (and maybe consider investing in a fast SSD instead!). The nickel-and-diming is rampant, and thankfully, the European Union is taking action. Their new Data Act aims to force transparency around these fees, but it highlights how insidious the problem has become.

Vendor Lock-In

Those shiny, cloud-exclusive tools are tempting. But good luck migrating if your costs suddenly skyrocket! You might end up feeling trapped, with the cloud feeling more like a mortgage than a flexible solution.

Security and Surprise Invoices

As Web Dev Cody showed in his video, cloud security isn't a "set it and forget it" deal. Protection during attacks can get incredibly expensive. Planning is key! If your self-hosted server gets DDoS'ed, downtime is likely. But, if your cloud service gets hit, you might face a shocking bill. The right choice depends on your web app's needs: can you tolerate downtime, or is an unexpected invoice worse?

Pitfalls

Understanding pitfalls like these is crucial for avoiding unexpected costs. Here are five of the most common ones I've encountered:

Pitfall 1: The Illusion of "Per Request" Pricing

• Charges by Rows Fetched: Let's say your shiny cloud database charges per row fetched. Sounds reasonable, right? But one unoptimized query without an index? Suddenly, you're scanning thousands of rows to find that single piece of data you need ...and now your 'cheap' database query just bankrupted you.
• Charges per Requests: Requests are not users. My simple portfolio sees about 1500 requests for 50 unique users. That's because every image, CSS file, and JavaScript snippet that is sent in chunks is a request. And that’s for my simple portfolio, for a more dynamic website, and the bill stacks up fast.
• Unpredictability: Unless you can predict exactly how every user will interact with your site, estimating your true cost at the end of the month is next to impossible.

Pitfall 2: The "Generosity" Trap

• The Bait: Ample free storage, bandwidth, etc., lure you in. But that one crucial feature you really need? Strangely limited...forcing a paid upgrade.
• Overprovisioning: And of course, that upgrade tier forces you into a package with way more resources than you need.
• Read the Fine Print: Try to understand what each item on the pricing page means, before you get hooked!

Pitfall 3: The Cost of Escape

• Data Egress: Extracting your data out of the cloud? You'll often pay steep fees for the privilege, especially at scale.
• Tool Lock-in: Proprietary cloud tools may seem amazing at first, but are designed to make switching a nightmare, potentially costing you a small fortune in development time.

Pitfall 4: Dangerous Ignorance

• Abstraction Blindness: Many devs treat cloud services as magic black boxes. They don't realize the underlying tech (PostgreSQL, Nginx, etc.) and how that impacts cost. Imagine unknowingly deploying a database configuration that costs ten times more than a perfectly suitable alternative!
• The "Just Pay" Mentality: Without understanding the fundamentals, devs easily accept inflated prices, assuming "this is just how the cloud works." But cloud pricing is often arbitrary. Understanding and questioning those costs is important! And this perfectly sets us up for the next pitfall:

Pitfall 5: The "Managed" Illusion

• Managed Doesn't Mean Problem-Free: Managed databases and automatic backups are fantastic tools. However some developers confuse them with a set-it-and-forget-it solution, but they often lure developers into a false sense of security.
• What You Still Need to Do:
  • Performance Tuning: Managed services don't optimize your queries for you. Indexing, database design are still your responsibility. Not understanding this leads to unnecessary costs through inefficient setup or over-reliance on auto-scaling – both of which cloud providers happily profit from.
  • Backup Strategy: Automatic backups are great, but what's your disaster recovery plan? How often do you test restores?
  • Cost Control and Monitoring: Managed services can scale automatically, often without you fully realizing it. You still need to monitor usage. Cloud providers DO offer monitoring tools, but they often come with their own costs or limitations. Don't assume you're getting accurate oversight for free!

Solutions for my portfolio website

So, does this mean cloud computing is evil? Absolutely not! I don’t even think the services I outlined here are bad, they just helped me illustrate some points and misconceptions. But, you need to be armed with knowledge. Here’s what ended up working for my portfolio website:

• Finding the Right Fit: I used Cloudflare Workers for the Nuxt frontend application. It is simple to use and has a generous free tier. Cloudflare also acts as your DNS manager, and offers performance optimizations and DDOS protection for free! This seems like a smart strategy on their part – support smaller projects with potential to grow, and they get word of mouth recommendations, case and point, I’m mentioning their services in this video!
• Homelab Love: For the CMS, my trusty homelab server stepped up. This is where I host Directus and PostgreSQL. To see some more information on how I built my homelab server, check out this video! Yes, electricity costs a bit, but at least my server isn't sending me surprise invoices. It’s a predictable cost and I'm in total control.
• Be Strategic about Self-Hosting: Choose what goes on your servers for example, non mission critical services, staging environments and so on. and what goes in the cloud or on managed services. For example, I self-host multiple services that use the same database instance, sharing the costs. Plus, I can use the same Directus instance to manage content for multiple websites. And for securely exposing the services from my home network, I use Cloudflare Tunnels – a great option for controlled exposure of self-hosted services. This was again, free, if you can believe it! So all in all I am only paying for electricity to host my website.
• Price Conscious Architecting: When I do use the cloud, I scrutinize every component's cost. Open-source tools help break free of vendor lock-in and give me more flexibility in the long run.
• But beyond that, I'm investing time into learning the underlying technologies – things like Kubernetes and cloud-native applications. This means that if I need to, I can move these workloads between cloud providers, or even bring them to my homelab without major headaches.

Take time to understand what you actually NEED and shop smartly. Don’t be afraid to do it yourself, and learn the hard things, trust me it pays off!

Let's keep this conversation going. Drop your cloud pricing horror stories in the comments, and let's learn from each other. Maybe your story will help someone else avoid a nasty cloud invoice.

Or maybe you think my criticism is unfair - write me a comment about that, I read all of them!

And before you go, we’re getting very close to 1000 subscribers!
Please consider subscribing to the Let's Talk Dev YouTube channel:

Here is a video of how I built the UI for the landing page of my portfolio website I talked about in this article: