Main features
- Deploys source code, a Dockerfile build or a container image
- Platforms for Python, Node.js, Go, Ruby, PHP, Java and more
- Service API to provision and bind databases and other services
- Apps spread across several Kubernetes clusters and regions
- Teams, roles, pools and quotas
- Autoscaling of app units
- Rollback to earlier deploys
- TLS certificates through certificate issuers
- Jobs as well as long-running apps
- Terraform provider for clusters and resources
What Tsuru does
Tsuru is a platform-as-a-service for organizations that want to run an internal Heroku for many development teams. Developers create apps with the tsuru command-line tool, deploy them, set environment variables and bind them to services, while the platform team decides which Kubernetes clusters, pools and plans the apps run on. Its BSD license names Globo.com alongside the project’s other authors.
A deploy can send source code to be built with one of the platforms (Python, Node.js, Go, Ruby, PHP, Perl, Lua and Java are provided), build from a Dockerfile, or use an existing image. Builds go through Tsuru’s deploy agent and BuildKit, and images are stored in a registry. Earlier deploys can be rolled back, apps can autoscale, and the same API also runs jobs.
Services and multi-team features
Tsuru’s service API follows the add-on model: a service provider implements a small HTTP API, and Tsuru calls it to create an instance, bind it to an app or remove it. When an app is bound, the service returns credentials that Tsuru exports as environment variables, for example a MySQL host, user and password. This lets a platform team offer managed databases, queues or cloud services through one interface.
Access is organized by teams and roles. Pools set the cluster and namespace an app runs in and can be reserved for particular teams or open to everyone, and quotas cap how many apps a user can create and how many units an app can run. Routing goes through a router API, with a default Kubernetes router, and different plans can use different routers. A single Tsuru API can manage apps across several Kubernetes clusters and regions, and clusters can be declared with Terraform.
Self-hosting Tsuru
Tsuru runs on Kubernetes. The documented installation uses the tsuru-stack Helm chart on Google Kubernetes Engine or on minikube for local testing; the GKE guide was written for Kubernetes 1.24. The architecture includes the Tsuru API server, a MongoDB 4.x database for its state, a container registry, the deploy agent and BuildKit, and a router API. After installing, you create the admin user with tsurud, add teams and platforms with the CLI, and can deploy the separate Tsuru dashboard as an app.
Hosted version
None. Tsuru is self-hosted only, and the documentation says there is no proprietary code in the project.
Limitations
Tsuru is built for platform teams, not for one developer with a VPS: it needs Kubernetes, MongoDB and a registry, and much of the work happens in the CLI. The installation guides are short and cover only minikube and GKE. There are no pull-request preview environments, and Git push deploys are not part of the documented workflow; deploys are started from the CLI or CI.
Who it suits
Tsuru suits companies that want to give many teams a self-service PaaS on Kubernetes, with quotas, pools and a service catalog, under a permissive BSD license with no paid edition. Smaller teams on Kubernetes may find Kubero, Canine or Epinio easier to start with.
Technical details
Self-hosting needs
- Kubernetes
- MongoDB
- Container registry
Built with
- Go
GitHub topics
- containers
- devops
- docker
- go
- hacktoberfest
- kubernetes
- paas
Reviewed by the OpenSourcePicks editors from the project's repository and documentation. Something out of date? Tell us.