Why leave AWS if the bill was not the main problem?

Because the issue was not only cost. The bigger issue was architectural drag, too many control planes, less privacy-forward defaults, and a stack that no longer matched how the portfolio actually worked.

Why Bunny.net over AWS for this portfolio?

Bunny let me collapse static delivery, edge behavior, storage, and more of the runtime story into one smaller platform with faster operator feedback and fewer moving parts.

What made Bunny feel different in practice?

The biggest difference was working with real people. I modeled the migration carefully, joined the Bunny community, explained the CLI gaps I hit, and got preview access to the database CLI I actually needed.

What role did the custom CLI play?

I was deploying several apps. If an agent or operator had to keep doing the same API action manually, that behavior belonged in the CLI. That made the deployment flow much cleaner.

Why I Moved My Portfolio from AWS to Bunny.net

I did not leave AWS because I suddenly forgot how to use it.

I left because I no longer wanted the shape of it.

The portfolio had accumulated the usual stack: S3, CloudFront, Route 53, API Gateway, Lambda, DynamoDB, CodeBuild, Secrets Manager, and the supporting glue around them. None of that was unusual. It worked. But over time it felt like I was paying for more architectural surface area than the products actually needed.

The apps were real, but too much of the stack had become choreography.

The AWS problem was not just cost

The steady-state bill was not the whole story. The deeper problem was operational drag.

Each product ended up split across too many boundaries: a static layer, an API layer, a function packaging story, a database story, a secrets story, and then the deployment logic required to keep them lined up. Even when the spend was tolerable, the system was heavier than it needed to be.

I wanted something simpler, faster to reason about, and less dependent on a giant default platform. I also wanted a stack that felt more privacy-aware by instinct instead of one that constantly pushed toward more services, more data paths, and more control planes.

Why Bunny.net made sense

Bunny worked because it let me simplify the shape of the portfolio.

For the static and edge-heavy parts, it gave me a tighter path: build, upload, serve, purge, verify. That is much closer to how these sites should work. For the next layer of runtime needs, Magic Containers and Bunny Database made it possible to test whether more of the stack could live in one place without dragging a hyperscaler mindset along with it.

That mattered because I was not moving one brochure site. I was moving several apps.

When you are doing that kind of migration, operator ergonomics matter a lot. If an agentic workflow has to keep reaching into the API to do the same thing over and over, that behavior should usually become a CLI command instead of staying as ad hoc API glue.

That was part of the appeal here: Bunny was small enough, responsive enough, and practical enough that it felt reasonable to build that flow in instead of working around it forever.

Smaller company, better operator feedback

This was one of the biggest surprises.

I had already done the careful part first. I modeled the move privately, validated the shape of the deployment flow, and only then started pushing more of it through the real migration path. While doing that, I joined the Bunny Discord and started talking through the operator gaps I was hitting.

One of those gaps was the database CLI story I needed for the portfolio.

Instead of getting lost in a giant support maze, I ended up talking to real people who understood the use case and gave me preview access to the DB CLI direction I was looking for. That changed the feel of the platform immediately.

It is easier to trust a company when the people behind it behave like builders.

The custom CLI mattered

I already had a custom CLI layer for parts of the portfolio and the migration work.

That meant I had a very practical standard: if the agent or operator repeatedly needs to do something through the API, and it is clearly part of the normal deployment or runtime workflow, it should probably be promoted into the CLI. That gives you a cleaner surface for humans, a cleaner surface for automation, and fewer points where ad hoc behavior can drift.

Bunny fit that mindset better than AWS did for this phase of the portfolio.

On AWS, a lot of the workflow felt like stitching together platform-shaped behavior. On Bunny, it felt much easier to say: this is a first-class deploy action, this is a first-class purge action, this is part of how this site actually ships, so let us build it in.

Privacy, security, and speed all got simpler

The privacy argument was not performative.

I wanted less default dependence on US big tech, fewer moving parts in the hot path, and clearer control over where the portfolio lived. Smaller surface area helps security because there are fewer pieces to misconfigure. Cleaner delivery paths help performance because there are fewer layers to reason about.

And for this portfolio in particular, simpler architecture was a security improvement in its own right.

That does not mean every workload belongs on the exact same platform forever. It means the default path should be the one with the least unnecessary complexity, and the exceptions should have to earn their way back in.

Why Bunny was the right move over AWS

AWS still has breadth. That was never the question.

The question was what kind of platform I wanted shaping the day-to-day reality of the portfolio.

For me, Bunny was a better fit because:

the static and edge path is simpler
the operator experience is tighter
the platform feels more responsive to real builders
the company still feels human-sized
the product direction leaves room for practical tooling instead of endless ceremony

That last point matters more than people admit. The platform you choose affects what kind of software habits you normalize.

I wanted fewer layers, more directness, and a company that still felt like it was building with real users rather than just selling cloud surface area.

That is what made Bunny the right move for this portfolio.