Costs of running a Python webapp for 55k monthly users

It's tough to generalize from things like this because "a webapp for 55k monthly users" can mean drastically different things. A user could be loading a few static pages, or that same user could be opening websocket connections or making requests that require expensive database queries. Your average user could stick around a minute, or an hour. Different apps can easily have per-monthly-user infrastructure costs that are two orders of magnitude different.

For comparison at the other end of the scale:

Facebook said that in the first quarter it spent $3.7 billion on data centers, servers, office buildings and network infrastructure.

https://www.datacenterdynamics.com/en/news/facebook-signific...

That's something like $8 per user per year. If you had that level of expenditure for your 55k-user app, it would cost $400,000 per year, 200x the cost given by this blog post. It isn't that Facebook is wasting the vast majority of their infrastructure, though, it's that the application does a lot more for each user.

It always makes my head dizzle when I read and hear how much people manage to bloat their stack because they think they need to "scale".

I have web applications running that reliably serve 50k users per day and cost me $10/month, running on a single, cheap VPS.

I don’t understand some of the comments quibbling over how this person has a “bloated” stack because it costs more than whatever irrationally frugal setup they’ve created for an app that does X specific thing.

Here’s a bigger point:

If you’ve got 55,000 monthly active users, and $171 per month doesn’t feel like a rounding error to you, then what you made isn’t actually valuable.

Spending any amount of hours to reduce that already small number is a giant waste of time for anybody who has that level of traction.

I'm confused about their thought process on their $95 a month DO servers.

They mention using a blue-green deployment strategy and a managed database service. That implies their web servers are stateless, or at least stateless enough to switch between the servers seamlessly.

But then they go on to say they don't want to downgrade because it means provisioning new servers.

Even in the worst case scenario of not using configuration management tools, aren't we talking a few hours of work here to save yourself let's say $40 a month which is 25% of their monthly bill? That would be the cost savings of downgrading to a lesser server x 2.

With configuration management tools, spinning up a new server would typically be running 1 or 2 commands and waiting 5 to 10 minutes. That's about how long it takes me to spin up a new server on DO to run a Flask application using Ansible and most of that time is because Ansible isn't exactly well known for its speed to execute tasks.

Nice writeup! Always appreciate transparency with these sorts of things, as someone who writes a lot of tiny personal projects and sometimes wonders how much I'd have to invest if they ever actually gained any traction. Congrats on having so many users, and good luck on monetization.

For the server instances, I can't imagine 4 CPUs/8 gigs RAM is really needed 24/7, but can imagine it being needed in bursts, and I assume GCP has various "elastic" auto-scaling products for that. Would love to know if your metrics indicate that this is the smallest box you could comfortably run on, or if it's just a best-guess. Could potentially spin down blue-green environments after some set amount of time (once you know a deploy "succeeded"), as well.

For Metabase, I can't find any "system requirements," but I'm not _super_ shocked by the price tag. I've always liked the idea of hosting my own tools instead of relying on some SaaS's free/trial tiers (particularly for things like analytics, logging, or metrics), but a lot of the open source options out there assume you have a pretty hefty box to throw it at. At the same time, I haven't found any better alternative other than just doing ad-hoc analyzing in SQL (using a GUI like Postico).

It's disappointing (and expensive) that you have no caching strategy. I would bet that 99% of your scoreboards are updated very infrequently, these pages could be re-generated into static html pages via cron job every 30 minutes / 2 hours / once per day, whatever frequency you choose. It's a free service, make people pay to have real-time updates.

My gosh, you are polling each leaderboard for changes every 15 seconds. Again, I would bet perhaps 1 in 1000 mature boards (i.e. online for more than a day) change in any 15 second period. You could severely reduce your server load by utilizing a CDN and statically-generating any board which hasn't changed in say, the past 6 hours.

Back in 2009-2013 or so I ran a quite popular add-on for World of Warcraft which aggregated data from about 200k active users regularly uploading it, maybe 5GB per day, into a common database of 5-10MB that was then downloaded by about 1 million users in varying intervals back into the game (it was some sort of mapping database, telling you where in the world which NPC was, with that info gathered by users using the tool). It came to eat several terabytes of monthly traffic, which was huge back in those days, but I operated that infrastructure by myself for several years on a single dedicated server for about 50€ responsible for the data aggregation work (heavy on I/O and computation) and two virtual server instances for about 15€ each which basically only served the downloads. The included traffic package on those VPSes was large, actually I chose the VPS offering precisely for that reason because I could economically cover all the download traffic that way. The compute power on them sucked, but they were basically a simple CDN setup so that didn't matter much. The total was about 70€, off course domain etc. need to be added, but I never paid more than 100€ for hosting of that app.

It is really disconcerting to see that doing similar "do-it-yourself" hosting activities nowadays appear to cost twice as much (judging by the article) while the "raw msterials" - core backbone traffic, compute power, memory and storage - all have gotten waaaaay cheaper in the last decade. Too many new rent-seeking middlemen, I guess...

> Note: the servers are oversized for the load we’re currently seeing. The reason for that is that we tried to solve a production issue by increasing the server specs. It didn’t solve the problem, and now we can’t down-size the servers without re-provisioning them.

Too late for them, but if you find yourself similarly needing to increase the capacity to solve a produciton issue on DO: you can upgrade CPU/RAM without increasing disk size. This allows you to downgrade later if you end up over-provisioning.

> The webapp runs on two identical DigitalOcean servers... The database is a hosted Postgres instance also on DigitalOcean.

They're only spending $69/mo total at DigitalOcean, and it sounds like their scaling isn't limited by computational power but rather by operational concerns. So, I'm not entirely sure what the backend language has to do with the costs here.

If you're trying to draw a cost comparison between languages, then the take-home from this writeup is that 55k monthly users is small enough that the backend language doesn't make a difference in costs.

Side note, this kind of transparency is always really nice to see!

This is not clear at all - 55k monthly users means nothing, what's the average number of requests per second? 99th percentile? What's the same stats for CPU and memory usage? 3.4k users per day is actually not that large a number, even assuming each user is going to bombard your server with thousands of requests in 20 minutes, it's well within what optimised flask with wsgi can handle with a very mediocre compute instance.

Further,Are you absolutely sure that you have optimised your configuration and code for performance without changing the stack? (Serving static components directly via ngninx, caching responses using flask, caching other resources using memcached, optimizing gunicorn worker counts for the instance type, profiling which endpoints take the most amount of time and trying to optimize them, see if the bottleneck is webserver or the db, considering pypy, and probably 50 other ideas).

Are you also absolutely sure that bluegreen deployments are what you want to use given your cost constraint? Further, if you have bluegreen it should be straightforward to downgrade your instances to smaller ones fairly easily,why not do that first before discussing costs?

We run production webservers on t2.small ec2 instances in elastic beanstalk and (with some assumptions) handle comparable loads during work hours. We have two redundant instances and can easily scale up or down even on schedule with zero extra code. There's not even a need to minimize costs here because our application costs 100x more on data lake costs than the webservers, but it really helps keep the engineers grounded and ensuring they don't write outrageously inefficient code that's covered up by excessive server sizes.

The author says he wants to switch Disqus to Commento but I wouldn't just do that. I didn't have a great experience with Commento. I like the idea and mostly the execution of it (including the OAuth) but I found some major bugs (Firefox just didn't work at the time) and I didn't get any response to reporting those. I asked a few more questions by mail and also no response. After that I'm gone pretty quick.

Not that I'm saying you should use Disqus since they have some privacy issues

Nice, we need more of these "real world expenses" posts on HN. I wonder how much it would cost to run the same app powered with Java. More? or Less?

$30 dedicated from Hetzner can do this reliably enough for a non revenue generating blog, including blue green deploys, postgres, certs, cache, edge caches (Cloudflare I guess) and even Metabase (which admittedly can be a memory hog if you don't set it in the JVM).

I'm not familiar with Python as a web stack but to me it looks that the DO instances are a bit over-scaled for 55k monthly users.

But what caught my eye was DNS Hosting: 5$/Month? Maybe it's a typo, shouldn't be more like 10$ per year to host a domain and its DNS?

Anyway, thanks for sharing, very interesting.

First of all kudos for putting something out there.

That said, are you making the right tradeoffs? Most of your spend is going to 'luxury'. Dual overcapacitated deployments, hosted managed Postgress, hosted Metabase.

It does sound like you could very significantly reduce your spend almost instantly with just a few minor changes, and dramatically if you would do a rethink of your stack.

Cost of servers and DB don't match DO's current pricing.

4 vCPUs, 8GB RAM, 80GB disk costs $40/month now so two servers alone cost $80 which is higher than $69.

Either DO raised pricing or they got some special discount.

5 bucks a month for dns hosting is also quite expensive since most domain hosting offer them for free. Definitely look into autoscaling with AWS for a simple 'poor man's cluster'

I note the author said: "Note: the servers are oversized for the load we’re currently seeing. The reason for that is that we tried to solve a production issue by increasing the server specs. It didn’t solve the problem, and now we can’t down-size the servers without re-provisioning them"

One small advantage I've noticed with Linode over DigitalOcean is that you _can_ perform these down-sizing actions (without some messy rsync scripts or snapshot-and-recreate approach that DigitalOcean suggest). You first need to resize the disk down to the lower Linode's limits, and then you can down-size to a smaller instance.

I wonder how much it would cost for the same app, if developed in Java or dotnet core.

They could save a good chunk of the 69 USD they spend on Digital Ocean servers.

edit : To clarify, What I meant was that to serve 55k users, perhaps using more efficient languages like C# or Java, would allow them to run on lesser spec machines. And as those users scale up, to say a million users a month, perhaps savings would also increase, if using more performant languages.

I hate such titles with a passion. I wonder if people will ever realize that "X monthly users" means absolutely nothing. That's by far the most useless metric people have come up with. This is the exact equivalent of "costs of living healthy":

1. How do you define "healthy". 2. Genetic abilities. 3. Overall health. 4. Eating habits. 5. Your geographical location. 6. Your daily routine ..... X^60000. {Factor number X^60000}

There are an infinite amount of buttons and dials that will determine how much "X monthly users" will set you back. Back in 2011 I used to own a blog that had something along the lines of 25k daily visitors. My annual bill was less than 100 bucks, domain included. And keep in mind that this was way before AWS, GCP and Azure came into the picture and costs were much higher than they are now. But I had spent months investigating the cheapest and most efficient ways to cut down costs. And it's the same with cloud providers - they can be brutally expensive or dirt cheap for the exact same thing if you don't take your time to see which and what is the best solution for your use case.

During the dotcom days, we hosted sites like this on a home dsl connection on a single desktop machine and got people to pay for that.

These are fun to read, but the data is hard to use for anything unless you are building the exact same thing.

(plug) Regarding Disqus, I run a competitor which you might like: https://FastComments.com

I believe that most of the comments complaining about overspecing the runtime mentioned in this article (if at all, I find it reasonable), are extrapolating on their experience and referring to a general problem of overspecing in the industry.

1. Whenever I see a new company's/project's runtime, I have come to expect a massively overcomplicated system that is "built to scale". But ends up costing a lot and taking way too much time from product-development. A real issue with this is that when looking at the project's feasibility to actually do scale, the runtime-cost will be estimated to a multiple of the current runtime cost which will appear larger than if the systems were built to handle the current load.

2. To me, this seems like a failure of cloud computing, which has a very compelling promise of letting you start with small servers, then easily switch up to bigger servers when needed. This was, in fact, hard before cloud.

3. The biggest issue I have with overspeced and overly complex deployments, is that to me it appears like (novice) developers is led to believe that they have to do the job in a complicated way. Look at a typical tutorial from the big and trend-setting players how something should be deployed. The first hit on my favourite search engine for a "Hashicorp Vault deployment" [1] recommends using nine hosts. I know from experience that it runs fine on ONE host of the smallest kind I could find for our non-trivial use-case. Also, in that use-case it doesn't matter that it is not HA, because it has turned out to be more stable than any of our other stuff, and can be restarted in a less than a minute. (I wouldn't mind at all, if the actual motivation for a large deployment was: "it is fun this way" or "we do this for our own training and experience" or "we choose to do it this way because of specific requirements" or anything of the sort.)

4. It seems to me that, what is needed is enough experience and courage to say: let's do our deployment and setup in a simple way that will work, because we know that we are competent to solve scale issues when they appear and we are not building ourselves into a corner. Also, we can afford to take responsibility if scaling problems do occur because we did not follow industry "recommendations" (i.e. trends).

[1] https://learn.hashicorp.com/tutorials/vault/deployment-guide

Edit: - clarified HA needs in point 3

OP, it looks like you can save some money on metabase, one of your larger expenses, if you are able to move to render.com (whom I have no affiliation, but am a customer). They have a metabase add on: https://render.com/docs/deploy-metabase

-- QUOTE -- Note: the servers are oversized for the load we’re currently seeing. The reason for that is that we tried to solve a production issue by increasing the server specs. It didn’t solve the problem, and now we can’t down-size the servers without re-provisioning them ️. -- END QUOTE --

Does anyone know the minimal provisions they could potentially use in this case?

Why does the author want to migrate to google cloud? Simply to be closer to their firebase installation?

I've grown fond of Caprover for this kind of small project. I would probably shove the metabase instance and both of the production instances into a single smaller instance (but I have been known to increase swap and put off upsizing resources in the past because cheapskate)

I get 55k unique users to my personal site, per DAY. I’ve got a number of very popular tools I host for Minecraft and Dev work.

It’s written in PHP/Go/MySQL

I am on a $10 a month Digital Ocean Droplet hosting like 7 other sites as well, and it’s probably overkill.

can we not use unreadable fonts on websites?

I read the top item as 6g aka 6,000 and the next (aws) as $60 and they were like "we can likely cut here".... yo you're spending $6k on the other thing cut there first... reading again yeah true.

This is one of the most difficult things to get when building your startup. At the beginning you have no way of getting accurate costs, and clearly, there's no one-size-fits-all approach for this.

Its just trial and error

"How much does running a webapp in production actually cost? Maybe more than you think. [...] In total that’s around $145 USD per month."

I thought that was going a really different direction than it ended up going.

The FAQ [0] still says it costs 15 EUR per month, you should update it.

[0] https://keepthescore.co/about/

Running my websites costs whatever electricity my server takes, but it also serves me as a filestorage so it'd be on anyway, so I'm going for "the price of the domains"

Almost half of that is an EC2 instance to run a reporting tool. 5$ DO instead? Also, 5$ a month for DNS hosting when DO will do that for free?

The webservers seem very overpowered for 55k monthly... seems like an unnecessary amount of money and could run on much cheaper VMs.

Majority of HN seems very heated about $171/month. My company pays 100x that just for our RDS instance (granted we store a lot of data). If you told me 5 of our users ended up costing us 10k/month in operational costs, I wouldn’t even blink.

55k users is very valuable. If you make a single cent per user per month, you’re in the black operationally (not counting dev time). If you make that into a dollar, you get to quit your job and be upper-middle class indefinitely.

The cost this month will be higher, YC hug

One thing I do not understand—what is the point of paying for DNS instead of using Cloudflare or similar?

I have seen a web app for 1,000 monthly users spend $1000/month for it.

Those were all paid users and the company was profitable with over 70% net margins after all costs including labor and research were factored in.

I’m all for $5/month digital ocean hosting when it makes sense but you also need to be realistic if there are revenues. Hosting should not be a major cost for the business.

That seems like quite an expensive mix. Almost a third of the bill goes towards insights?

Looking forward to the monetization post.

Has the developer thought about using donations instead of ads?

Cost of running it myself on my $30/mo colocation server: $30

oh yeah, and 10$ a year domain fee

$5 a month for DNS?! I MUST be missing something. Why the hell would you need to pay monthly for dns?

Edit: Guys if you down vote at least let me know what I'm clearly missing... Does dnsimple do something google domains can't?

Does it generate revenue?