Ask HN: Advice for Hosting and Deploying My Side Project
I'm finally starting to wrap up the MVP of my web app which is my side project. Now I'm starting to look at how I'm going to host it, and I'm getting overwhelmed with the number of options. My background is in desktop\embedded code, so I've not really had to deal with this much before. My app is written in Rust on the Rocket framework and uses PostgreSQL and PostGIS.
I was originally looking at Digital Ocean, however I'm thinking that managing that might be too much work for me, and it will be too easy to make a stupid security mistake. I'm currently looking at https://www.clever-cloud.com/en/rust-hosting ↗ which seems safe and easy. Are there better options?
Should I not try and ignore this stuff and spend the time like learning something like Docker instead?
Any other tips? Anything I'm overlooking?
An open Ask HN community consultation from 2019 where @the_wannabe convened hundreds of developers and bootstrappers to share real experiences, hard numbers, and tactics.
Hundreds of active indie hackers contributed case studies, pricing heuristics, and pitfalls to avoid when moonlighting on side projects.
First piece of advice: Relax, don't sweat it too much. I 'hosted' my first side project on a Raspberry PI. My second was on an AWS EC2 instance on the tiny free tier. Nothing wrong with having the db and the app on the same server (in my case Python and Postgres). The projects were mostly for fun though, and I was not worried about scaling or anything like that, but it was quick, cheap and easy.
If you are worried about scaling (which would be a nice problem to have), you can still start out on AWS (or another provider's) free tier, and then just upgrade the instance if you start getting an uptick in use. If you are lucky enough to out grow vertical scaling, then you will have plenty of motivation to figure out the horizontal part. Just carve out an afternoon to sort it out. And if you are really ambitious, try setting your app up on multiple providers. After the first one is up, figuring out the others should be easier (cause they all basically do the same thing), and then you can play around with them and stick with the one you like best. Might cost a little more initially, but could help put your mind at ease.
Regarding security, just make sure you are salt+hashing users passwords. You can worry about the other stuff later. And as others have mentioned, if you do one thing, make sure you backup your database. You can start by just doing it with a daily crontab (or even do it manually if you really need to). It your app crashes, you can always restart it, but if you loose the db, you are hosed.
Also, you might want to consider getting some test users (friends, family) to poke at it before releasing it into the wild. This will help you surface any bugs. If this is your first web app, I would rate your odds of having issues large enough to ruin your launch as: 95% chance due to bugs | 4.5% chance due to scaling issues. | 0.5% chance due to security issues. If a site is getting the HN hug of death, it usually peaks my interest more, and I will bookmark and come back to it. But if its buggy as hell, I loose interest right away.
Caveat: I have not worked with Rust. The comments below suggesting Heroku, DigitalOcean and other PaaS are good starting points. However, I want my side projects to be able to handle arbitrary load without managing additional infrastructure.
I design my current web apps to work using serverless functions https://serverless.com/ ↗ This ensures that if my applications become popular, I will not have to do additional infrastructure work to scale. I use a cloud provider managed database (AWS DynamoDB, RDS for Postgresql) so I don't need to worry about managing that either.
There is a steep learning curve! A quick Google search shows that Rust serverless is in its infancy (https://github.com/softprops/serverless-rust ↗). Also, if you need to have bi-directional communication using WebSockets (or something comparable), the options you have to work with are limited (AWS AppSync is what I am currently struggling with)
That being said, it has been an extremely challenging and rewarding experience, migrating my personal projects.
I am writing a book exactly for this purpose right now.
For someone making a project and asking "how do I host it now?". My pre-release is still ~3 months far away, so you cannot buy it now, but if you would like to learn the deployment yourself at some point, here it is:
https://vpsformakers.com/ ↗
What I recommend is to learn the fundamentals right and start with Bash before jumping to more complex config management tools. Even if your deployment process won't be smooth in the beginning (copy files, setting something manually) do not underestimate the security aspect - you owe it to your users to protect their data.
And avoid ANYTHING you don't need right now. Avoid Docker and the whole universe of tools around Kubernetes. I imagine with Rust you can easily deploy one binary with systemd unit, PostgreSQL service from the OS, set up NGINX and SELinux and you are done.
Someone here said Docker is about uptime. What the *? Docker is additional layer where something can go wrong so by definition it won't be better than just a systemd service.
You were on the right track, DigitalOcean is the easiest and at $5/mo for Debian/Ubuntu, it should be sufficient for an MVP.
If you are concerned about security, just follow the "simple" steps below
https://www.digitalocean.com/community/questions/best-practices-for-hardening-new-sever-in-2017 ↗
.. it's mostly just typing stuff in a terminal
You can probably skip 10, 11, 14, 15, 16, 17 (in the short run)
If you want to automate this, you can learn Ansible (or Fabric fabfile.org) but that is probably premature
Just make sure you have a backup of everything on your server (nobody is going to take that more seriously than you, specially for customer data)
For scaling, they have some simple Load Balancers now (pick the correct region where it is available) ... used to have to do some DNS-based load balancing before (AWS R53). Again, probably premature but it can be done without too much pain once you get there
Docker is about uptime, consistency, integrity, CI/CD, etc. If you're just testing stuff, and won't notice a day or two of downtime, you can skip it for now (but it does make things easier once you learn it).
Always keep working backups of whatever you want to have on your server. Expect your server to get erased at any moment without previous notice, be aware of how much data are you willing to lose in case of a failed restore.
If you're processing user data, be aware of applicable data protection laws (if any).
Security is only relevant if you become somewhat popular, or you plan on leaving the project completely unattended for a longer period of time (don't, you will most likely get hacked). Otherwise, apply basic security measures and don't sweat it too much until you actually start having something worth protecting. Erasing and re-creating a server/instance from scratch is acceptable and secure enough in the beginning.