I migrated my SaaS from DigitalOcean to AWS EC2 solo, here's what broke and what I fixed
I'm building ClientFlo, an agency management platform for solo founders and small agencies (client tracking, invoicing, and scheduling in one place).
A few months ago, I moved the whole stack off DigitalOcean to AWS EC2. Here's what actually happened, not the clean version.
The problem
My old deployment pipeline built Docker images directly on the production server. One deploy caused an OOM crash and took the app down. That's not a "maybe someday" risk when you're solo, it's a when.
What I changed
- Moved to a GHCR-based pull-only pipeline. Images are built in CI, the server just pulls and runs. No more building under load on a box serving live traffic.
- Migrated Postgres to RDS instead of self-managed. One less thing to babysit at 2 am.
- Added concurrent deploy locks in GitHub Actions so two deploys can't race each other.
- Split staging onto a home server behind a Cloudflare Tunnel, so I stop testing in production like an animal.
What I learned
Infrastructure that's "good enough" quietly becomes a liability the moment you can't afford downtime. As a solo founder, you don't get a pager rotation, you get you, and you get to decide upfront whether 3 am is a good time to debug a build failure.
ClientFlo is live at clientflo.tech. Still early, still solo, happy to answer anything about the AWS migration or agency SaaS in general.
The infrastructure story is solid, but the more interesting part is what changed once “solo founder” became an actual operating constraint rather than just a founder label. The same architecture means something different when the person maintaining it is also the person carrying the cost of every failure.
That's the actual shift. Solo founder used to just mean nobody to delegate to. Now every infra decision gets weighed against my own time and the cost of me debugging something at 2 am with no backup.
The GHCR pull only pipeline came straight out of that math.
Short enough to read in one breath, it keeps the point that mattered, cuts the rest.
That makes sense. It sounds like the constraint changed how you evaluate infrastructure decisions, not just which infrastructure you use. Curious what decision has been hardest to make under that constraint so far?