Garden

What Garden actually is

Garden is a development tool, not a hosting provider — worth stating up front, since we list it among cloud platforms and the comparison points are different. It is an open-source CLI (Apache 2.0) paired with an optional cloud service that together attack one specific problem: the gap between "works on my machine" and "works in the cluster." You describe your stack — builds, deploys, tests, and one-off runs — as a graph of actions in version-controlled config files, and Garden executes that graph against whatever Kubernetes target you point it at: kind or Minikube locally, Docker Desktop, a shared dev namespace, or a production-like remote cluster.

The core mechanic is dependency-aware caching and orchestration. When you change one service, Garden's graph engine works out which build, deploy, and test actions are affected and runs only those. Test results and build layers can be cached, so an unchanged test is skipped rather than re-run. In CI this is where the big wins come from: Garden reported one Fortune 500 team cutting an end-to-end pipeline from around an hour to two and a half minutes after adopting its automation. We can't reproduce that figure ourselves — the honest framing is that graph-aware caching removes redundant work, and the savings scale with how much of your pipeline is genuinely unchanged between runs.

The workflow features are the day-to-day draw. garden dev gives an interactive loop with hot reload that syncs code changes into running containers without a rebuild, plus a live view of logs and service status. Tests can run as Kubernetes pods against real cluster behavior rather than a mocked local approximation, which matters for teams with inter-service dependencies. Environments are declared once and reused: the same config that runs your stack locally deploys it to a staging cluster, so environment drift shrinks. In the 0.14 ("Cedar") generation, Garden moved its cache backend for Kubernetes test and run actions to Garden Cloud, which enables sharing cache hits across clusters and between local development and CI; when you can't log in, it falls back to a local file-based cache.

There is also a web dashboard on the free community tier: an interactive graph view, command history, build and action log viewers, a command palette, live log streaming, and on-demand ephemeral clusters. Sign-up is GitHub-only at the time of writing.

Pricing: what you really pay

The CLI is free and open source, and that is the version most individual developers will use. Garden Cloud, the hosted layer that adds remote builds, shared caching, and team features, operates on tiers. The free community tier covers up to 3 seats with 200 compute minutes, 300 cache hits per month, 10-day command-result and log retention, and 7-day cache retention. The Team tier (minimum 4 seats, up to 8) is priced per seat per month and includes 1,000 compute minutes per seat monthly, 10,000 cache hits per month, and 30-day retention across the board. Enterprise is a quote: tailored compute minutes, unlimited cache hits and retention, unlimited seats.

One caveat we'd flag: the exact Team-tier price is not currently published in a machine-readable form on the plans page, and since Incredibuild acquired Garden in November 2024, third-party trackers report the commercial pricing page has been redirecting to documentation. We don't think the open-source CLI is going anywhere — it remains on GitHub under Apache 2.0 — but if you're budgeting a multi-seat commitment, get current terms in writing from Incredibuild rather than from a cached pricing page.

The remote container builder is the other cost axis. It gives you remote build compute and shared layer caching; the free tier includes a monthly allotment of build minutes and caching, and if you run out, Garden falls back to local builds rather than failing the pipeline. That fallback is a genuinely good design decision — your CI doesn't stop because a quota lapsed.

Because Garden runs on infrastructure you supply, there is no hosting bill from Garden itself. Your Kubernetes cluster is the cost center: minikube is free, a cloud dev namespace is whatever your provider charges.

Performance & infrastructure

Garden doesn't own datacenters, so our usual infrastructure columns don't apply — there is no SLA, no entry-level vCPU/RAM spec, no regions. What matters instead is what Garden does with the infrastructure you point at it. On the plus side, the action graph plus caching is a real multiplier: nothing runs twice if nothing changed, and shared caches mean CI and local development stop being separate silos. Remote container builds offload image building from developer laptops and CI runners, which helps both iteration speed and runner costs.

Where performance depends on you: cache hit rates, cluster size, and how cleanly your dependencies are modeled. A project whose config declares tight dependencies gets fast, targeted runs; a project where every test depends on every build gets much less benefit. In our view, teams that invest an afternoon modeling their service graph properly get paid back on every subsequent run.

Support-wise, the open-source side is GitHub issues and community discussion. Paid tiers add commercial support and onboarding, with the usual enterprise caveat that terms live in a contract rather than a public page.

Where it falls short

The learning curve is the main honest objection, and it's steeper than the row above suggests. Garden has its own config language, its own action model (build, deploy, test, run), and its own templating. Teams coming from Docker Compose or a pile of shell scripts will spend real time before they see the payoff. Kubernetes knowledge is assumed — Garden doesn't hide the cluster from you.

Uncertainty after the acquisition is the second concern. Incredibuild bought Garden in a reported ~$65 million deal in November 2024 and simultaneously trimmed its own staff, and public commercial pricing has gone quiet since. The project is still maintained and the docs are current, but we understand why a platform team hesitates to standardize on a tool whose vendor just changed hands.

Third: the value proposition concentrates in multi-service Kubernetes projects. If you run two containers, Garden is overhead. If you run twenty microservices with integration tests, it's one of the few tools that addresses the whole loop rather than one slice of it. Smaller teams will find the community smaller than Docker's or Kubernetes' own ecosystem, so answers to exotic problems come slower.

Finally, most Garden features work best with Garden Cloud. The CLI alone gives you the graph and local caching; cross-environment cache sharing, remote builds, and the dashboard want an account. That's a reasonable trade for a hosted service, but it means "fully self-contained" is only mostly true.

Who should pick this

Our pick for platform teams running multi-service Kubernetes stacks who lose most of their day to rebuild-and-retest cycles. If your CI pipeline runs long because nothing is cached and everything depends on everything, Garden's graph is the direct fix. It also suits teams chasing environment parity — one config, local to staging to production — and organizations that want tests to run against real Kubernetes behavior rather than local approximations.

Skip it if you want a hosted platform: Garden builds and deploys, it doesn't sell you compute. Skip it if your stack fits in Docker Compose. And if post-acquisition roadmap stability is a hard procurement requirement for you, talk to Incredibuild first.

Compared with the alternatives in our /category/kubernetes-managed and /category/container-platforms listings, Garden is unusual in being an open-source workflow layer rather than a service you buy capacity from. The comparable decisions are closer to "do we build this orchestration ourselves" than "which cloud do we use."

Key takeaways

• Open-source Apache 2.0 CLI for Kubernetes dev/test orchestration, with an optional Garden Cloud layer for remote builds and shared caching
• Dependency-aware graph means unchanged builds and tests are skipped; one reported Fortune 500 pipeline dropped from an hour to about two and a half minutes
• Free community tier: up to 3 seats, 200 compute minutes, 300 cache hits per month; Team tier is per-seat with higher limits; Enterprise is by quote
• No infrastructure of its own — no SLA, no regions, no entry specs; it runs on the clusters you supply
• Acquired by Incredibuild in November 2024 (reported ~$65 million); commercial pricing is no longer published clearly, so confirm terms before committing
• Best for multi-service Kubernetes teams chasing faster iteration and environment parity; overkill for small stacks

Sources

• https://docs.garden.io/
• https://app.garden.io/plans
• https://docs.garden.io/misc/migrating-to-cedar
• https://docs.garden.io/using-garden-with/containers/using-remote-container-builder.md
• https://www.prnewswire.com/news-releases/garden-announces-bonsai-a-better-way-to-automate-ci-pipelines-301832026.html
• https://thecompanycheck.com/company/b/garden/fx7ssnzabrz42icpr
• https://calcalistech.com/ctechnews/article/1ifvf95ra
• https://incredibuild.com/news/incredibuild-acquires-garden