garden-io/garden: Kubernetes dev environments from a YAML action graph

The problem Garden targets: Kubernetes feedback loops that are too slow

Kubernetes gives you production-like environments, but the usual workflow around them is slow and duplicated. A developer edits code, rebuilds an image, pushes it, reapplies manifests, waits for pods, and repeats. CI then reimplements much of the same logic in a different tool with different configuration. The README frames Garden as an answer to exactly that split: it is described as a DevOps automation tool for developing and testing Kubernetes apps faster, with the promise of production-like environments for development, testing and CI on demand, the same configuration and workflows at every stage of software delivery, and caching to speed up builds and test runs.

The audience is narrow on purpose. You need an application that runs on Kubernetes, a container build step, and a desire to run integration tests against deployed services rather than mocks. Teams that already maintain Helm charts or raw manifests are the natural fit, because Garden wraps those artifacts rather than replacing them. Teams without a cluster, or with a single long-running staging environment and no per-branch deploys, get much less from it.

How the action graph, plugins and sync mode fit together

The README states that Garden Core is a standalone binary that can run from CI or from a developer's machine, and that its configuration framework codifies a description of the stack in YAML so workflows are reproducible and portable. The central mechanism is what the README calls the action graph: you declare the dependency structure of the project, and Garden tracks changes to avoid unnecessary builds, deploys and test runs. The README describes this as CI/CD config that you can additionally use for development.

Configuration is split into typed actions. The README's example defines kind: Build with type: container and a source path, kind: Deploy with type: helm for a Postgres chart, kind: Deploy with type: kubernetes and manifestFiles, and kind: Test with type: container and an args list. Dependencies are declared explicitly, for example dependencies: [build.api, deploy.postgres], which is what lets the graph order execution and decide what is stale.

Execution itself is delegated to plugins. The README says how actions are executed depends on the plugins used, and names the Kubernetes plugin as the most popular, followed by Terraform and Pulumi. That is a real architectural boundary: Garden orchestrates and caches, but the plugin decides what a deploy means. Sync mode is the development-facing feature. The README describes it as live reloading changes to your running services, enabled with garden deploy --sync, and the repository includes a code-synchronization example and a gatsby-code-sync example.

Installing Garden and running a first deploy and test

The README does not list package-manager install commands. It points readers to the quickstart guide at docs.garden.io/getting-started/quickstart as the fastest way to get started, and the repository also carries a shell.nix and a nix/ directory, so a Nix-based setup exists in the tree. Treat the quickstart as the install source of truth rather than copying a binary URL from anywhere else.

Once the CLI is available, the unit of configuration is a garden.yml file. The README gives a simplified example for a web app, split into actions with a --- separator. This is what Garden reads to build the action graph:

kind: Deploy
name: db
type: helm
spec:
  chart:
    name: postgres
    repo: https://charts.bitnami.com/bitnami
---
kind: Build
name: api
type: container
source:
  path: ./api

With config in place, the README shows that you build and deploy the project with garden deploy and test it with garden test. Run them from the directory containing the config. The first deploy is the slow one, because every action in the graph has to execute; later runs skip actions whose inputs have not changed.

garden deploy
garden test

For per-pull-request environments the README adds an environment flag to the same command. The environment name has to exist in your project configuration for this to resolve:

garden deploy --env preview

For interactive work the README documents a dev console that can build, deploy and test the project from one session, and sync mode for live reloading changes into running services:

garden dev
garden deploy --sync

Where Garden is the wrong tool, and what it does not document

Garden assumes Kubernetes. If your services run on a single VM, on Docker Compose, or as managed serverless functions, the action graph has nothing meaningful to order and the Kubernetes plugin has nothing to talk to. The README's own framing is about Kubernetes apps, and the plugin list is Kubernetes, Terraform and Pulumi; there is no documented path for a non-Kubernetes runtime in the repository documentation.

The second constraint is operational. Garden is a client that talks to a cluster, so it inherits every cluster problem: credentials, namespaces, image pull access, and the cost of running production-like environments on demand. The README does not document rollback behaviour, does not describe how it cleans up environments that are no longer needed, and does not explain what happens to the cache when two branches touch the same action. Those are the questions to settle before you put garden deploy --env preview into a pipeline that runs on every pull request.

There is also a versioning wrinkle worth noticing. The repository's package.json declares version 0.14.20 and a Node engine requirement of >=22.17.1, while the most recent releases listed are 0.13.65 from 2026-08-24 and 0.13.64 from 2026-06-11, with an edge-bonsai release from 2023-02-01. The README links examples under a 0.14.20 path. Anyone pinning a version should reconcile which line they are actually installing rather than assuming the newest tag matches the tree.

Garden compared with Skaffold and Tilt

Skaffold and Tilt solve an overlapping problem and are the honest comparisons. Skaffold's model is a pipeline: build, tag, render, deploy, with profiles selecting variants, and it stays close to the underlying kubectl and Helm commands. Tilt centres on a live-update loop and a browser UI for watching services converge. Both are Kubernetes-focused and neither asks you to model tests as first-class graph nodes the way Garden's kind: Test action does.

The difference in approach is where the dependency information lives. Skaffold and Tilt mostly react to file changes and rebuild what their pipeline rules say; Garden asks you to declare dependencies such as dependencies: [build.api, deploy.postgres] and then derives staleness from that graph, which the README says covers builds, deploys and test runs together. That is more upfront configuration and a steeper first hour, and it is the reason Garden can skip a test whose upstream deploy did not change. If you want the thinnest possible wrapper over kubectl, Skaffold is closer to that; if you want Garden's caching and test ordering, you pay for it in YAML.

Licence, maintenance and the cost of upgrading

Garden is licensed under MPL-2.0, the Mozilla Public License 2.0, per the README and the LICENSE.md file in the repository root. MPL-2.0 is a file-level copyleft licence: modifications to files that are part of the covered source must be made available under the same licence, while larger works that combine it with other code can be distributed under other terms. That matters if you fork the CLI or a plugin and ship the modified files. It is not legal advice; check with counsel for your distribution model.

The repository is not archived, and the last push was on 2026-08-24, so it is current. The upgrade surface is the action schema in your garden.yml files. Because actions are typed and carry spec fields, a change to a plugin's action type can require edits across every config file in the project, including configs co-located in other repositories, which the README explicitly supports. The repository keeps a CHANGELOG.md and a RELEASE_PROCESS.md, so the changelog is the place to look before bumping. Budget for reading it, not just for running an upgrade command.

Editorial conclusion

Adopt Garden if your application already targets Kubernetes and you want the same garden.yml to drive local deploys, preview environments per pull request, and test runs, with sync mode for live reload. Skip it if your stack is plain Docker Compose, serverless functions, or anything the Kubernetes, Terraform and Pulumi plugins do not cover, because the action graph only pays off when it can model your resources. Before committing, verify that your cluster version and the Kubernetes plugin work together, run garden deploy --env preview against a throwaway namespace to confirm the environment variable and namespace handling matches your CI, and check the CHANGELOG for the version you intend to pin.

Frequently asked questions

Official sources

1. garden-io/garden on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases