Tsuru

Open-source Platform as a Service, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Open-source (BSD-3-Clause) Platform as a Service built on Kubernetes — think Heroku, but the control plane runs on your own infrastructure and the license lets you do anything with it [4].
• Who it’s for: Engineering teams and DevOps-forward companies that want Heroku-style deploy UX on top of Kubernetes clusters they already own or manage. Not for non-technical founders who’ve never touched a terminal.
• Cost savings: Heroku’s paid dynos start at $5/dyno/month and a typical 3-app setup runs $50–150/mo quickly; Render starts at $7/service/month. Tsuru self-hosted runs on infrastructure you already pay for, with no per-app or per-dyno line item [4].
• Key strength: Genuinely production-tested at scale — Globo.com (one of Brazil’s largest media companies) built and open-sourced it, and ran millions of containers on it. The pedigree is real, not startup vaporware [2].
• Key weakness: Third-party review coverage is thin, the website looks like it hasn’t been updated since 2018, and the star count (5,263) is modest compared to newer alternatives like Coolify (53,000+) or Dokku (31,000+). You’re betting on a tool that the broader open-source community hasn’t widely adopted [4].

---

What is Tsuru

Tsuru is a Platform as a Service layer that sits on top of Kubernetes and gives developers a tsuru deploy-style interface instead of raw kubectl commands. You push code, Tsuru figures out how to build and run it in a container, manages routing, scales dynos on demand, and handles add-on services like Redis and PostgreSQL through a plugin system. The idea is that your engineers think in apps and services, not in pods and ingress controllers.

The project was created by and open-sourced by Globo.com — the Brazilian media conglomerate behind Globo TV — which needed to run thousands of containerized apps across a large infrastructure without drowning their development teams in Kubernetes YAML. That origin story matters: Tsuru was production-hardened at enterprise scale before it was ever released publicly [2]. It’s not a side project someone shipped to get GitHub stars.

The license is BSD-3-Clause [4] — one of the most permissive open-source licenses available. You can use it in commercial products, embed it in your own PaaS offering, resell it to clients, modify it without open-sourcing your changes. No “Fair-code” asterisks, no commercial-use restrictions. Compare this to something like n8n’s Sustainable Use License, which restricts commercial redistribution, and Tsuru’s license is a genuine advantage if you’re building a hosting product on top of it.

As of this writing, the repository sits at 5,273 stars with 551 forks, written in Go, with a last commit within 2 days per opensourcealternative.to — so it’s not abandoned [4]. The GitHub CI badge passes and the Go report card is clean.

---

Why People Choose It

The review coverage for Tsuru is thin compared to tools like Coolify or Dokku, and the available third-party sources range from shallow to irrelevant. What we can piece together:

The Heroku migration angle. Tsuru shows up consistently in “Heroku alternatives” lists written after Heroku discontinued its free tier in November 2022 [3]. The pitch is straightforward: you already know the Heroku mental model, Tsuru speaks a similar language (apps, services, teams, pools), and you own the infrastructure. The difference is that Tsuru requires Kubernetes underneath — you’re not replacing Heroku with a simpler system, you’re replacing the Heroku control plane with one you operate.

The B2Saas review [1] is unfortunately too generic to cite with confidence — it reads like a template rather than genuine hands-on use. Its listed pros are “intuitive user interface, easy setup, reliable performance,” which could describe any software. What it does confirm is that reviewers who have actually tried it found the setup approachable and the performance reliable. The cons listed — “limited customization options” and “lack of advanced features for power users” — are worth noting even if lightly sourced, because they point to a real positioning tension: Tsuru is trying to be simpler than raw Kubernetes, which means experienced Kubernetes users may find it constraining.

The Globo.com pedigree. The media coverage from Tsuru’s early years (Infoworld, Wired) focused on how Globo.com was running this at scale in production [2]. Talks at conferences like TECHINPORTO 2017 describe “service industrialization at scale,” and the “Trusted by” section on the Tsuru homepage lists Globo, Jumia (the African e-commerce company), Stone (Brazilian fintech), and several smaller companies. This isn’t a tool that exists only in demos.

CNCF stack integration. Tsuru is built on CNCF (Cloud Native Computing Foundation) technologies — Kubernetes at its core — which means it composes with Prometheus, Helm, and the rest of the cloud-native toolchain [4]. If you’re already running a Kubernetes cluster and want to add a PaaS layer without replacing your existing infrastructure, Tsuru is a more natural fit than Coolify (which manages its own Docker environment) or Dokku (which is single-server).

---

Features

Based on the README and official documentation:

Core deployment engine:

• Deploy any app in any language or framework — Python, Node.js, Go, Ruby, PHP, Perl, Lua, Java all have official platforms [README]
• Single-command deploys (tsuru app deploy) — the Heroku-style experience [README]
• Runs on Kubernetes, with Minikube support for local dev and GKE guides for production [README]
• Multi-cluster and multi-region management from a single control point — one of the differentiators versus single-server tools like Dokku [README][4]

App management:

• Dynamic resource scaling — allocate and deallocate compute without SSH [4]
• Add-on services: SQL, NoSQL, Redis, memcached and others via the service plugin system [README]
• Team and pool model for multi-tenant access control [README]
• tsuru target system for switching between environments, similar to kubectl context [README]

Infrastructure:

• Docker and docker-compose support [profile]
• Kubernetes as the provisioner [profile][4]
• Plugin system for extending the CLI [profile]
• Redis integration for internal queuing [profile]

What it doesn’t have out of the box:

• No built-in web dashboard (a tsuru-dashboard app exists but is a separate component)
• No managed database offering — you wire in your own or use add-on plugins
• No native CI/CD — you trigger deploys from your existing CI pipeline via the CLI

---

Pricing: Self-Hosted Math vs. The Alternatives

Tsuru itself is free. BSD-3-Clause, no premium tier, no “community vs enterprise” split documented on the website. What you pay for is infrastructure.

Self-hosted cost structure:

• Tsuru software: $0 [4][README]
• A working Kubernetes cluster: the real cost driver. A managed Kubernetes cluster on GKE, EKS, or DigitalOcean Kubernetes runs $50–150/mo for a minimal 3-node setup. On bare metal or a dedicated VPS provider like Hetzner, you can run a small K3s or Minikube cluster for $20–40/mo.
• The Tsuru control plane itself is lightweight Go — the overhead is minimal once Kubernetes is running.

Heroku for comparison (the tool Tsuru most directly replaces):

• Heroku shut down its free tier in November 2022 [3]
• Basic dynos: $5–7/dyno/month, no sleep
• Standard-1x: $25/dyno/month, horizontal scaling
• A 3-app production setup with a database add-on easily runs $100–200/mo
• No self-hosted option; you can’t escape the pricing as you scale

Render for comparison:

• Free tier for static sites; $7/mo per web service, $7/mo per PostgreSQL database
• A 3-app setup with databases: $40–60/mo minimum
• No self-hosted option

The actual savings math:

If you’re running 5 apps on Heroku Standard dynos plus a couple of Postgres instances, you’re likely at $150–250/mo. On Tsuru over a $40/mo K3s cluster at Hetzner, that’s approximately $1,300–2,500/year saved once you amortize the setup time. The Kubernetes cluster cost doesn’t go to zero — that’s the honest caveat — but it scales with your hardware rather than with your number of apps.

Pricing data from Tsuru itself: none available — there’s no pricing page because there’s nothing to price.

---

Deployment Reality Check

Tsuru’s install story is not beginner-friendly, and the documentation doesn’t try to pretend otherwise. The README points to Minikube for local development and GKE for production. The install process requires:

What you actually need:

• A running Kubernetes cluster (Minikube, GKE, EKS, K3s, or any conformant K8s) [README]
• kubectl configured and pointing at that cluster
• go, yq, and either Docker or Podman installed for local dev [README]
• The Tsuru CLI (tsuru-client) installed separately — it’s a different repository from the server [README]
• For macOS local dev: the README specifically recommends the QEMU driver with socket_vmnet for Minikube, which is a non-trivial setup step [README]

The make local.setup → make local.run flow works for getting a local environment running, and the setup only needs to happen once — subsequent starts use make local.run. But you need to understand what you’re running: this is Go, Kubernetes, and Docker all in the dependency chain [README].

Team and pool model is manual. Before deploying your first app, you create a team, create a pool, and label your Kubernetes nodes to assign them to that pool with kubectl label nodes minikube tsuru.io/pool=my-pool [README]. This is not the kind of setup you hand to a junior developer on their first day.

What can go sideways:

• The documentation and website haven’t been refreshed visually in years — some guides may reference older CLI versions or behavior. Cross-reference with the GitHub README which is more current.
• The B2Saas review flags “limited customization options” — likely a reference to the fact that Tsuru’s abstractions are deliberate: it intentionally hides Kubernetes complexity, which means if you need Kubernetes-specific configuration (custom resource definitions, sidecar injection, specific pod specs), you’re fighting the abstraction layer.
• The small star count relative to alternatives (5,263 vs Coolify’s 53,000+) means a smaller community, fewer Stack Overflow answers, and less third-party tooling [4].

Realistic time estimate: An experienced Kubernetes operator can have Tsuru running on an existing cluster in 1–2 hours. Starting from zero — provisioning a cluster, installing Tsuru, deploying a first app — plan for a full day. For non-technical founders: this is not in scope without dedicated DevOps help.

---

Pros and Cons

Pros

• BSD-3-Clause license. The most permissive major open-source license. Use it commercially, embed it in products, modify it without open-sourcing. No legal conversations needed [4][README].
• Built at real scale. Globo.com ran millions of Docker containers on Tsuru in production before it was ever open-sourced. The architecture has been stress-tested in ways most OSS PaaS tools haven’t [2].
• Multi-cluster Kubernetes native. If you’re running multiple Kubernetes clusters across regions, Tsuru gives you a single control plane to manage deployments across all of them — Dokku and Coolify don’t do this [4][README].
• Language-agnostic platforms. Python, Node.js, Go, Ruby, PHP, Perl, Lua, Java — if there’s a Buildpack for it, Tsuru can run it [README].
• CNCF-compatible. Composes with Prometheus, Helm, and the standard cloud-native toolchain without fighting them [4].
• Active development. Last commit 2 days ago as of review data, CI passing, repository under active maintenance [4].

Cons

• Requires Kubernetes to exist. This is not a “spin up a VPS and run a script” situation. Kubernetes is a prerequisite, not an optional backend. That’s a significant operational commitment [README].
• Thin review coverage. The available third-party coverage is sparse and shallow compared to alternatives like Coolify or Dokku. The community is smaller, which means fewer forum answers when you get stuck [1][4].
• Website and docs look dated. The tsuru.io homepage hasn’t been updated visually in years and the documentation structure can be hard to navigate. The project is alive; the marketing presence suggests otherwise.
• No web UI for app management. There’s a tsuru-dashboard app, but it’s not bundled — the primary interface is the CLI. Teams that prefer a web UI will need to assemble it separately.
• “Limited customization” per users. The B2Saas review [1] flags this, and the architecture explains why — Tsuru intentionally abstracts Kubernetes complexity. Power Kubernetes users may find the abstraction ceiling frustrating.
• Smaller star count = smaller ecosystem. 5,263 stars vs. Coolify’s 53,000+ and Dokku’s 31,000+ means fewer community plugins, fewer tutorials, fewer integrations with third-party tooling [4].
• No documented commercial support offering. There’s a Gitter channel and GitHub issues. If you need SLA-backed support for production incidents, you’re on your own or hiring from the open market.

---

Who Should Use This / Who Shouldn’t

Use Tsuru if:

• You’re an engineering team that already runs Kubernetes and wants a PaaS UX layer on top of it without leaving the Kubernetes ecosystem.
• You need to manage deployments across multiple clusters or regions from a single control point.
• You’re building a hosting product or internal developer platform and the BSD-3-Clause license matters for your business model.
• You’re migrating off Heroku and already have Kubernetes operational capacity in-house.
• You want a tool with proven enterprise-scale pedigree (Globo, Jumia, Stone as references) rather than a newer tool that only has small-team testimonials.

Skip it (pick Coolify) if:

• You want a modern web UI, one-script install on a single VPS, and don’t need multi-cluster management. Coolify’s 53,000 stars and active community make it the better choice for most self-hosters in 2025.

Skip it (pick Dokku) if:

• You’re a solo developer or small team that needs a simple Heroku replacement on a single server. Dokku is more mature for this use case, has 31,000 stars, and doesn’t require Kubernetes.

Skip it (pick Caprover) if:

• You want a PaaS with a built-in web dashboard, Let’s Encrypt automation, and one-click app templates. Caprover (14,970 stars) is designed for exactly this.

Skip it entirely if:

• You’re a non-technical founder — this is firmly in DevOps territory. Tsuru is not a tool you learn in an afternoon.
• You need managed support with an SLA — there’s no commercial offering.
• Your team doesn’t already understand Kubernetes — adding Tsuru to a Kubernetes learning curve is the wrong order.

---

Alternatives Worth Considering

Based on direct comparisons in review sources [3][4] and the project’s own positioning:

• Coolify — 53,000+ stars, single-VPS and multi-server, modern web UI, one-script install. The current crowd favorite for self-hosted PaaS. More beginner-friendly than Tsuru.
• Dokku — 31,000+ stars. The original open-source Heroku clone. Single-server, mature, massive community, simpler architecture. Pick this if you don’t need Kubernetes.
• Caprover — 14,970 stars. PaaS with a web UI, built-in Let’s Encrypt, one-click app marketplace. Good middle ground between Dokku’s simplicity and Tsuru’s Kubernetes depth.
• Heroku — the incumbent. Best DX, biggest add-on marketplace, fully managed. No self-hosted option. Pricing becomes painful at scale.
• Render — modern Heroku alternative with a better free tier and cleaner pricing. Still closed SaaS, no self-hosted option.
• OpenFaaS — 26,000+ stars. Good if you’re specifically building serverless functions rather than traditional apps. Different abstraction level than Tsuru.
• Space Cloud — 3,997 stars. Open-source Kubernetes-native backend platform, different angle from Tsuru but comparable positioning.

For a team migrating off Heroku that already runs Kubernetes, the realistic shortlist is Tsuru vs nothing (raw Kubernetes with custom CI/CD scripts). Tsuru wins that comparison for teams that want the PaaS abstraction maintained. For teams starting from scratch without Kubernetes, Coolify or Dokku are the better starting points.

---

Bottom Line

Tsuru is the right tool for a specific kind of team: one that already runs Kubernetes, wants a PaaS abstraction layer with a permissive BSD license, and values enterprise-scale battle-testing over community popularity. The Globo.com origin story and the multi-cluster architecture put it in a different category from single-server tools like Dokku or Caprover. The tradeoffs are real: Kubernetes is required, third-party coverage is sparse, the website looks like 2017, and the community is an order of magnitude smaller than newer alternatives. But for an infrastructure team building an internal developer platform — or a company building a hosting product that needs BSD-licensed PaaS internals — Tsuru is a more serious choice than its star count suggests. Everyone else should start with Coolify.

---

Sources

1. B2Saas — “Tsuru Reviews: Pricing & Software Features 2025” (b2saas.com). https://b2saas.com/tsuru
2. Tsuru.io — Media Coverage and Press Archive (tsuru.io). https://tsuru.io/media/
3. Livecycle — “The Complete List of Heroku Alternatives You Might Want to Consider” (livecycle.io). https://livecycle.io/blogs/complete-list-of-heroku-alternatives/
4. Open Source Alternative — “Tsuru: Open Source Alternative to Heroku, Render” (opensourcealternative.to). https://opensourcealternative.to/project/tsuru

Primary sources:

• GitHub repository and README: https://github.com/tsuru/tsuru (5,263 stars, BSD-3-Clause license)
• Official website: https://tsuru.io
• Documentation: https://docs.tsuru.io/