Why we built Bananahost

Bananahost started with two friends who each had a problem that looked a lot like the other one's.

We had two completely separate use-cases, but the requirements were the same. We needed to deploy workloads reliably, keep each workload logically separated from the others, and take care of backups, maintenance, and patching so that a workload could be upgraded safely, every time.

The workloads themselves had little in common, but the plumbing they needed was identical: infrastructure automation, deployments, TLS termination, backups, patching. So instead of solving the same problem twice, we set out to build one automated deployment package that each project could use on its own infrastructure. That package became Bananahost, and it's where our tagline comes from: building automated deployments.

Learning from production

While we were building the package, the first use-case went into production. That project isn't something we advertise, since it's unrelated to what we offer, but it played a big part in Bananahost's development: it showed us which features were missing and where the codebase needed to be simpler. There's no faster way to find the gaps in your tooling than running a real workload in production.

We fixed what production taught us to fix. And once we'd learned everything we could from that first project, we already had our course set for the bigger one.

What's next

Both of us have spent years monitoring our own infrastructure, and our customers' infrastructure on top of that. That shaped what we wanted to build on top of Bananahost first: a hosted monitoring service, powered by a tool we already knew and loved.

That service is Hosted Uptime Kuma, and it launches in September. Read the announcement for the full story.