Ask HN: Should a solo developer use AWS for his public side project?

I think AWS is good for side projects. I am also a solo developer and have deployed side projects on AWS so far my experience is very good. As you have mentioned that you can't afford to spend >100 euros/month I think you can go with AWS free tier where it is possible

1- For DB server you can you RDS free tier I would say it would be enough for a side project

2- For Redis Instance you can use EC2 free tier to run single Redis Instance or you can try Amazon elastic Cache as well

3- For Rails app depending upon your need again you can either use free tier server or whatever suits you check different AWS EC2 instance types https://aws.amazon.com/ec2/instance-types/

4- For CDN you have to use Amazon S3 first and that would cost you and cost depends upon usage + storage, since its a side project bill won't be too much

Happy Deployment ;)

Companies like Digital Ocean, Linode, Vultr, Scaleway cater to small developers. The costs are much lower, although the flexibility and features aren't the same as AWS. If you need the features of AWS then definitely take a look at their main competitors too (Google and Microsoft), they all have slightly different feature sets and optimizations.

Personally I've never found a reason to use AWS/Azure/GCS for small projects, they're just too costly.

I used to be like OP. Trying to save as much money as possible hosting with OVH or Linode and provisioning my own servers.

Then my projects would die because I spent far more time doing this than writing application business logic. The classic "solving scaling problems with zero customers".

Heroku is expensive when you have scaling issues, but until then, it's $7 a month with the free Postgres and Redis options...

> Heroku doesn't maintain database state. Your dyne can essentially be erased and restarted with an empty database. That's not usable for production systems.

Almost, dynos don't persist filesystem changes but for databases you're suppose to host the data elsewhere (e.g. Heroku Postgresq, AWS RDS, AWS S3) and that data will be persisted. This is by design and a very good strategy for production systems as you can then easily scale by adding more stateless dynos later. All configuration for your dynos is stored and versioned in Git and all your important data is stored somewhere robust with proper backups and rollbacks.

If you've advocating storing your state on the server itself by e.g. using AWS EC2 or Digital Ocean, you're going to need your own strategy to make sure you don't lose any data or configuration settings (e.g. packages, config files) when your server box fails and storing state on the server means you can't easily horizontally scale.

When Heroku doesn't let you SSH into active servers, only lets you deploy via Git and doesn't let you store state on servers, it's done intentionally to force you into making good choices that scale.

Spin up a 2gb+ DigitalOcean server and toss Dokku on it. Feels like Heroku, very reliable, very simple to understand by just reading the Dokku source.

AWS is a great great thing, but has opaque pricing and a lot of nuance to getting everything running smoothly. 99% of projects can survive on a single beefy server for a long time before scaling becomes a concern, at which point that is a good problem to have. Don't make it a bad problem now by making things too complex.