Ship Your Side Project to the Internet

The full journey from 'it works on my laptop' to 'a stranger can use it at a real URL' - pick a VPS, SSH in, run it with Docker, point a domain, put it behind Cloudflare, and auto-deploy on merge - with every first-time gotcha flagged.

1. Pick a Cheap VPS A small VPS is plenty to start - but the box has to survive the build, not just the run, and the billing keeps charging while it's powered off. Pick for build-RAM, and delete (not stop) to stop paying.
2. SSH In With a Key Get onto the box with an SSH key, not a password: generate a keypair, put the public half in authorized_keys, and work through the 'Permission denied (publickey)' decision tree when it won't let you in.
3. Docker & Your Private Repo Install Docker, pull your PRIVATE repo onto the box with a read-only deploy key, and bring it up with compose - dodging the two .env traps that waste everyone's first afternoon: a $ in a value, and restart not re-reading .env.
4. Domains & DNS Buy a domain, point its nameservers at a DNS provider, and add an A record for the apex and a CNAME for www - knowing that the apex usually can't be a CNAME, and that a .dev domain refuses to load over plain HTTP.
5. Behind Cloudflare Put your site behind Cloudflare for free HTTPS and protection - via a proxied DNS record or, better, a Cloudflare Tunnel that needs no open ports - then fix the app-side must-dos (public origin, CSRF, secure cookies) and firewall the origin so nobody bypasses Cloudflare.
6. Auto-Deploy on Merge Close the loop: a GitHub Actions workflow that, on every merge to main, SSHes into your box and pulls + recreates the stack - so shipping is a merge, not a chore - with the build-OOM and restart-vs-recreate traps handled.