Use Linux, pretend you’re in the 90s/2000s. If you can’t afford a team, you’re too small to need more. - Use NFS (EFS), put builds in a /releases folder - B

Use Linux, pretend you’re in the 90s/2000s. If you can’t afford a team, you’re too small to need more. - Use NFS (EFS), put builds in a /releases folder - Bash scripts for build, deploy, release - Bash scripts to wrap apps (write pidfile, start, stop, etc) - Cron those scripts - Check crontabs into a repo along with all other config - Cron a bash script to pull from that repo and update crontabs on every box - Have a staging environment, deploy stuff there (esp DB migrations) and do smoke tests. - Have some kind of monitoring (I have a slackbot that sends me messages when things break) I general I follow the principle of proportional response, and n=2 (or 3 depending on how trivial the task is to automate). Proportional response means you invest in automation / tooling proportional to the pain you have suffered. Burning a day to build a bulletproof script only makes sense to solve a big problem. For a smaller issue, maybe adding a debug line or writing a line somewhere that you can copy-paste later is good enough. N=2 means you don’t solve stuff until the second time you need it. This stops you from burning hours building clueless complex garbage to solve unnecessary problems - at least by the time you are automating, you have solved it once or twice by hand and you know where you are going. Elon’s 5 principles have been very useful to me as a solo dev: 1. Make requirements less stupid 2. Delete the part/requirement 3. Simplify/Improve the design 4. Accelerate cycle time 5. Automate So in particular you might try 1-4 to see if you can magic problems away before you invest in building devops automation you will then need to maintain.