Tsuru

Brazilian media conglomerate Globo created Tsuru in 2012 to give internal engineering teams a self-hosted, Heroku-style deployment workflow across private infrastructure. The platform has since evolved from early Docker orchestration into an open-source control plane on Kubernetes. Today, it provides DevOps teams with an abstraction layer that handles builds, routing, and scaling without exposing developers to raw manifests.

Why Tsuru instead of Engine Yard

Engine Yard provides a managed proprietary platform tied to AWS, provisioning instances and configuring runtimes through predefined recipes. Tsuru shifts that operational model to your own infrastructure, turning standard Kubernetes clusters into a multi-tenant platform. DevOps teams configure node pools, compute plans, and routers once, allowing developers to deploy applications using tsuru app deploy or Git pushes while operations retains cluster governance.

That autonomy trades vendor management for internal platform ownership. Engine Yard offloads OS patching, control plane resilience, and runtime upgrades in exchange for infrastructure markups. Running Tsuru requires operating the Go API daemon, a MongoDB metadata store, BuildKit builders, and an ingress router. Platform engineers own the cluster lifecycle and storage, but gain the freedom to run on any cloud or bare metal without commercial constraints.

What it does well

• Multi-cluster routing across pools: Teams register multiple Kubernetes clusters and route workloads via pool labels through a single API endpoint.
• Git and archive deploys: Developers push code or tarballs to trigger container builds and rolling updates without writing Kubernetes manifests.
• Service marketplace binding: Operations attaches backing datastores like PostgreSQL and Redis through service brokers, injecting credentials into application environments automatically.
• Declarative resource plans: Administrators enforce CPU, memory, and unit scale limits per plan, preventing tenant workloads from exhausting cluster capacity.
• Native autoscaling: Workloads scale horizontally and vertically using Kubernetes HPA, VPA, and KEDA event-driven triggers.
• Multi-tenant RBAC: Native teams, OIDC authentication, and granular permissions isolate applications, audit events, and deployment privileges across business units.