As teams break monoliths into microservices, two things quietly get worse: local development and pull-request testing. You can't run fifteen services on a laptop. Shared staging turns into a queue where one broken deploy blocks the whole team. And the oldest bug in software — "but it works on my machine" — comes roaring back, now multiplied across every service boundary.
At IQCrafter, we see this pattern constantly on Kubernetes-bound microservices projects. One tool worth knowing when you hit this wall is Garden. This post explains what it is, how it works, where it fits, and — just as importantly — where it doesn't.
The problem, concretely
A microservices architecture that looks clean on a diagram creates real friction day to day:
- The laptop can't hold the whole stack. Once you have a dozen services, a couple of databases, a message broker, and some supporting infrastructure, running the full system locally is impractical or impossible.
- Staging becomes a bottleneck. A single shared environment means engineers wait their turn, step on each other's changes, and debug failures that have nothing to do with their own code.
- PR review is shallow. Reviewers read a diff but can't actually use the change, because there's nowhere to run it in isolation.
- CI drifts from production. Tests pass in a CI environment configured differently from prod, so "green" doesn't mean "safe."
The common thread is environment inconsistency: dev, CI, and production are configured in three different ways, so behaviour differs at each stage.
What Garden is
Garden is a DevOps automation tool for developing and testing Kubernetes applications faster. It lets you spin up production-like environments for development, testing, and CI on demand, using the same configuration and workflows at every stage of delivery — and it speeds up builds and test runs through smart caching.
A useful mental model: Garden is a makefile for cloud-native development. You describe your build, deploy, and test workflow once, and run it consistently everywhere — your machine, a teammate's machine, CI, and a preview environment for a pull request.
How it works
Garden is configured through garden.yml files. For large projects you can split the configuration into multiple files and co-locate each with the relevant part of your stack — even across multiple repositories, which matters when each microservice lives in its own repo.
Configuration is built from a few action types that form a dependency graph:
- Build — how a service's image or artifact is built.
- Deploy — how it's deployed (via a plugin, e.g. Kubernetes manifests or a Helm chart).
- Test — how tests run against deployed services.
- Run — one-off tasks such as database migrations.
Because actions declare dependencies on one another, Garden resolves the correct order automatically. A simplified configuration for an API backed by Postgres looks like this:
kind: Deploy
name: db
type: helm
spec:
chart:
name: postgresql
repo: https://charts.bitnami.com/bitnami
---
kind: Build
name: api
type: container
source:
path: ./api
---
kind: Deploy
name: api
type: kubernetes
dependencies: [build.api, deploy.db]
spec:
manifestFiles: [./manifests/api/**/*]
---
kind: Test
name: integ
type: container
dependencies: [deploy.api]
spec:
args: [./gradlew, integrationTest]
Here the api deploy waits for its image to build and for the database to come up, and the integration test waits for the API to be deployed. Swap ./gradlew integrationTest for whatever your stack uses — a Spring Boot service, a Laravel app running PHPUnit, or anything else that runs in a container.
Two features are worth highlighting:
- Plugins decide execution. How actions actually run depends on the plugin. The Kubernetes plugin is the most widely used, followed by Terraform and Pulumi. Your
garden.ymlstays largely the same while the plugin handles the mechanics. - Sync mode gives fast feedback. Garden has a mode that live-reloads changes into your running services, so you get near-instant feedback while developing against a remote environment instead of rebuilding and redeploying by hand.
The real hook: preview environments on every pull request
This is where Garden earns its place in a team workflow. Using the official Garden GitHub Action, you can deploy a preview environment on every pull request — an isolated, production-like stack that reviewers can actually explore, while the latest pushed code is tested in a separate CI environment.
A trimmed GitHub Actions workflow looks like this:
name: garden
on:
pull_request:
branches: [main]
jobs:
preview:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# ... authenticate to your cloud / Kubernetes cluster here ...
- name: Deploy preview environment with Garden
uses: garden-io/garden-action@v2
with:
command: deploy --env preview
garden-auth-token: ${{ secrets.GARDEN_AUTH_TOKEN }}
Now each PR gets its own environment. Reviewers click through the actual change instead of imagining it from a diff, integration tests run against a real deployment, and nobody is blocked waiting for shared staging.
(Note: the Garden GitHub Action currently targets Linux-based runners.)
The benefits
Pulling it together, the payoff for a microservices team is:
| Benefit | What it solves |
|---|---|
| Consistent configuration across stages | "Works on my machine" — dev, CI, and preview all use the same garden.yml |
| Smart shared caching | Slow builds and redundant CI work across the team |
| Isolated per-PR environments | Shallow PR review and the shared staging queue |
| On-demand environment provisioning | Waiting for infra or stepping on a colleague's deployment |
When Garden is not the right fit
Being honest about fit is part of good engineering judgement:
- It assumes Kubernetes. Garden's value is concentrated around K8s workflows. If you aren't on Kubernetes and don't plan to be, most of the benefit doesn't apply.
- It's overkill for simple deployments. A single-container app or a straightforward VM deploy doesn't need this machinery. Garden pays off when the number of services and environment complexity are the actual pain.
- There's a learning curve and added configuration. You're introducing another layer to understand and maintain. That cost is worth it for a genuinely complex system, less so for a small one.
Garden is typically adopted by teams with relatively large projects that run on Kubernetes and can't easily be developed or tested locally. If that describes you, it's very much worth evaluating. If it doesn't, simpler approaches will serve you better.
Closing thought
Preview environments and consistent, reproducible dev/test workflows aren't a luxury for mature microservices teams — they're what keeps velocity from collapsing as the system grows. Garden is one strong way to get there, but the underlying pattern matters more than any single tool.
If your team is wrestling with slow environments, a staging bottleneck, or PRs nobody can properly test, that's exactly the kind of problem we help solve at IQCrafter — from assessing your current setup to implementing a preview-environment workflow that fits your stack. Learn more about our Enterprise Software and Cloud Orchestration capabilities, or get in touch and we'd be glad to talk it through.