Ask HN: Low-maintenance and cheap deployment and persistence?

Every now and then I think of creating a HTTP API/web service to resolve a pain point I'm experiencing, for which no good solution currently exists. I would do this purely on a hobby basis. My fear is that when I have done this in the past, I have always run into one of two problems: 1. After a year or two, I lose persistent storage and discover that the backups have not worked for a few months. If I ran the service as a day job, I'd use a high quality but expensive backup provider and do restoration testing regularly, but I can't afford to spend that time for a hobby project. 2. After a year or two, for various reasons I end up needing to migrate the service to a new server, and I run into all sorts of deployment issues (builds failing, missing dependencies, incorrectly configured firewalls, etc.). If I ran the service as a day job, I would just take whatever time was needed to sort out the deployment issues, but I cannot afford to suddenly drop everything for a hobby project, so I leave it offline for a few weeks, and then it becomes harder and harder to prioritise fixing it. It's often not brought back online until months later – or never. Being in a position where I have no choice but to disappoint users like that is extremely demotivating. These two factors mean that I don't want to create a service that requires deployment or persistence. This rules out a large class of things I want to build, and leaves in basically only small ECMAScript applications that use browser local storage. Recently I realised that maybe I've just approached deployments and persistence for hobby projects wrong. Maybe I'm involving too many moving parts, and relying too much on being my own sysadmin in addition to being the developer. How are you all doing it in a way that's cheap and low maintenance?