I built an MVP on a 5 dollar VPS. But I had to recently upgrade to a 12 dollar VPS as some of my analytics process were being stopped because of low memory. Aside from writing better code, I found out that using linux utils/app via system calls is the most effective solution as nothing I can write can ever be even remotely as performant as something like grep.

I am following a similiar path to yours but my stack is a bit complicated.

Python + SQLite on VPS

Vue/Nuxt + Auth on Firebase

The process is extremely hacky and experimental, so it might change. I am not planning to use a proper backend as the Python scripts communicates to the Firebase via its SDK. That is working for me at this moment and eliminates writing boilerplate API code.

I don't know... from what I've used of Python it is pretty memory heavy and doesn't do well left alone unsupervised. I could be wrong but that was my experience trying various Py web frameworks.

My app servers were all $5 VPS with only nginx, PHP/php-fpm, and Memcached. PHP was cached, nginx assets were cached, and data was cached in RAM with Memcached which was updated from remote DB server on cache expire.

I would then stack as many of those behind a load balancer as needed (nginx as reverse proxy basically) and scaled up to serving 100's of terabytes of data monthly and billions of page views.

So while it was "$5 VPS" it was really a small cloud of them behind another $5 vps as a load balancer with a $25 database server supporting the data. Still cheaper than Amazon for equivalent loads.

Have you consideres productize/templatize this stack and selling some kind license/supporting deal? Although a more marketable solution will be a redis + node based stack.

uhhh it's really just a basic install of freebsd and a bunch of shell scripts! As far as I'm concerned anyone with a bit of time could google fu themselves in to production.

I am always happy to, and have, contracted to build similar setups for other people for CDN delivery, etc, but that was just another day in the life of a sysadmin basically.

Email in profile if you have any other questions.

Over the years I have played with sqlite and postgress. I keep coming back to Mariadb for my web apps.

I can't say it's had very much production load testing, but using the site myself it seems to work fine.

https://wcedmisten.fyi/post/stateful-webapp-on-7-68-budget/

https://github.com/wcedmisten/python-nextjs-template

I use mainly flask and restful flask. However restful flask has been deprecated, so I was really interested in FastAPI. Then someone pointed out the number of open issues on the FastAPI project, so I got spooked. Flask maybe has quite a few frameworks for implementing rest API. Not sure what the future holds for Flask.

As you pointed out

> A backend comes with all sorts of baggage: databases, managing user data, authentication, backups, and increased server load.

With Flask being a microframework and barebones, going through this list becomes a chore unless you have built dozens of webapp and have some kind of template.

So I kinda gave up on web-backend entirely and moved towards firebase. Most of the complicated stuff will happen on the VPS side of things and will be communicated to firebase via the SDK.

However, I believe (based on vague memories) that there used to be a ton of issues on the fastapi repo that were basically support requests. Going throw some closed issues, it seems that these were closed and/or converted to discussions.

Probably a trade-off with cost I'm guessing. For my project I was trying to get the cost as low as possible, since it's just a side project for me.

Interesting point about the open issues, I didn't notice that, but does seem like it could be an issue for the longevity of the project.

On the VM:

- Nodejs + React SSR

- Nginx

- Certbot to manage my SSL cert

- Integrated with Grafana's cloud service (free tier)

Outside of the VM:

- Managed MongoDB cluster

- API health check's every 3 min with email alerts (I use multiple uptime services to check from different regions) - DB backup cron jobs, backups are stored in 2 cloud providers

- Service desk for customer's to send queries/raise issues

- Alerts if CPU/RAM usage is too high (never got an alert for the past 2 years)

I also nuke the VM once a year and re-provision otherwise you have to maintain the OS, do cleanup etc.

Future work:

- Find way to backup my DNS records

- Probably need to monitor the SSL cert expiration in case certbot breaks

- CI/CD

> nuke the VM once a year and re-provision otherwise you have to maintain the OS, do cleanup etc

That is really interesting. What are you using to re-setup your entire infrastructure after purging a VM? How do you manage the down time between one vm purge to setting up the next one.

I would love to know, going beyond the VPS what is your total infrastructure + maintenance cost.

I set things up again on the new VM manually. I have a runbook for it, usually takes me 30 mins or less.

To not have any downtime I keep the old VM up and attach a new public IP to the new VM. I then update the DNS records and after a while when the new IP is mapped to my domain I then stop the old VM.

Costs:

Managed Mongodb cluster: $9 but I share it between multiple side projects so let's say $3

API health checks - free! I use digital ocean and fresh ping

Service Desk - free! I use Jira

DNS: Usually $0.3

DB backups: within the free tier on both cloud providers. I have it set to only keep the last x backups so this should always be free

Cron job to run the backup: I have a serverless function for this, still within the free tier

SSL cert - free because I use let's encrypt

Docker image storage costs: <$1

Total ~$9.5

Docker Image - Since I'm running this most of the operation on AWS I use ECR

I run heavy traffic EC sites on $20-30 VPS and can't imagine why you would need more, unless you do data analysis on same node.

Fancy things like Vue/Nuxt are cool, but do you actually need it?

Count how many responses you're providing for a single request. Reduce them.

See what can be done in parallel or out of order, do that.

Check requests through time of day. Eliminate overload.

TIL. Thank you very much.

I always wanted to invest more time in postgres, but I just find the Windows environment to be clunky when working with it. Like psql isn't supported in a windows environment (last time I check few months ago), and setting up the postgres environment on WSL was quite annoying as you have to figure out port forwarding.

I know setting up a postgres on a local machine directly or even without docker may not be a mature decision, but that is the hacky reason, why I keep going back to sqlite, as it is the easiest solution to get started with a database.

But hey, nothing wrong with easy, usually. :)

Once I started to feel limited by google sheets, I upgraded to SQLite. I will invest in postgres once I hit the ceilling with SQLite.

For purely sequential reads of data from disk, sure.

I think the time when the church thought they could buy out that market segment, has passed.

Are you able to help me with these questions?

1. How did you decide which services to start? Did you have any criteria on what types of services you did and didn't want to start?

2. Was all of the income from those services advertising? Or were you charging users directly for some?

3. After it was built, how did you market a service and attract users?

Well, not end users. They're getting ads.

But I would assume that ad buyers and publishers have exclusive improvements. After all, it's not like the ad companies took a substantially smaller cut. It either lowers the cost to ad buyers or it increases the revenue to publishers. Since it's pretty much the same number, it doesn't seem both can be true.

I think advertising is a powerful way to support 'free'ish content and there are ways to use advertising tastefully. People who don't want to participate have options to opt out and are obviously welcome to not make server requests.

Right, not sure why we didn't think of that sooner.

> Well, not end users. They're getting ads.

Why not? Would you prefer ads, or ads with terrible javascript loaders?

I’ll just ignore the part about what you said about end users other than to say it’s arguable.

Since ad buyers pay per conversion, I don't actually think it helps them to increase the conversion rate.

I mean, obviously it's different at the extremes like 0% vs 100%, but I doubt header-bidding produces that great an effect.

That’s our Hitler!