LogoLogo
Bonsai (0.13) DocsGitHubDiscord CommunityGarden Enterprise
Bonsai (0.13)
Bonsai (0.13)
  • Welcome to Garden!
  • 🌸Overview
    • How Garden Works
    • Core Concepts
    • Adopting Garden
    • Garden vs Other Tools
  • 🌳Use Cases
    • Isolated On-Demand Preview Environments
    • Fast, Portable CI Pipelines that Run Anywhere
    • Shift Testing Left
    • Local Development With Remote Clusters
    • Jumpstart your Internal Developer Platform
  • 🌻Getting Started
    • Quickstart Guide
    • Installing Garden
    • Next Steps
  • 💐Tutorials
    • Your First Project
      • 1. Create a Garden Project
      • 2. Pick a Kubernetes Plugin
      • 3. Add Actions
      • 4. Add Tests
      • 5. Code Syncing (Hot Reload)
      • 6. Next Steps
  • 🌿Using Garden
    • About
    • Configuration Overview
    • Projects
    • Dashboard
    • Actions
    • Tests
    • Runs
    • Workflows
    • Variables and templating
    • Config Templates
    • Using the CLI
    • Modules
  • Kubernetes Plugins
    • About
    • Remote K8s Plugin Configuration
      • 1. Create a Cluster
        • AWS
        • GCP
        • Azure
      • 2. Configure Container Registry
        • AWS
        • GCP
        • Azure
        • Docker Hub
      • 3. Set Up Ingress, TLS and DNS
      • 4. Configure the Provider
    • Local K8s Plugin Configuration
      • 1. Install Local Kubernetes
      • 2. Configure the Provider
    • Ephemeral K8s Plugin Configuration
      • 1. Configure the Provider
      • 2. Login to the Garden dashboard
      • 3. Configure Ingress (optional)
      • 4. Retrieve Kubeconfig (optional)
    • Actions
      • Build
        • Container
      • Deploy
        • Kubernetes
        • Helm
        • Container
        • PersistentVolumeClaim
        • ConfigMap
      • Run and Test
        • Kubernetes Pod
        • Helm Pod
        • Kubernetes Exec
        • Container
    • Guides
      • In-Cluster Building
      • Minimal RBAC Configuration for Development Clusters
      • Deploying to Production
      • Using a Registry Mirror
  • ☘️Terraform Plugin
    • About
    • Plugin Configuration
    • Actions
  • 🌹Pulumi Plugin
    • About
    • Plugin Configuration
    • Actions
  • 🌼Other Plugins
    • Container
    • Exec (local scripts)
  • 🌷Guides
    • Migrating to Bonsai
    • Migrating from Docker Compose to Garden
    • Deprecations and updating to Cedar
    • Code Synchronization
    • Connecting a local application to a Kubernetes cluster (Local Mode)
    • Environments and namespaces
    • Using Garden in CircleCI
  • 🪷Advanced
    • Using Remote Sources
    • Custom Commands
  • 🎋Reference
    • Providers
      • conftest-container
      • conftest-kubernetes
      • conftest
      • container
      • ephemeral-kubernetes
      • exec
      • hadolint
      • jib
      • kubernetes
      • local-kubernetes
      • octant
      • otel-collector
      • pulumi
      • terraform
    • Action Types
      • Build
        • container Build
        • exec Build
        • jib-container Build
      • Deploy
        • configmap Deploy
        • container Deploy
        • exec Deploy
        • helm Deploy
        • kubernetes Deploy
        • persistentvolumeclaim Deploy
        • pulumi Deploy
        • terraform Deploy
      • Run
        • container Run
        • exec Run
        • helm-pod Run
        • kubernetes-exec Run
        • kubernetes-pod Run
      • Test
        • conftest-helm Test
        • conftest Test
        • container Test
        • exec Test
        • hadolint Test
        • helm-pod Test
        • kubernetes-exec Test
        • kubernetes-pod Test
    • Template Strings
      • Project template context
      • Environment template context
      • Provider template context
      • Action (all fields) template context
      • Action spec template context
      • Module template context
      • Remote Source template context
      • Project Output template context
      • Custom Command template context
      • Workflow template context
      • Template Helper Functions
    • Commands
    • Project Configuration
    • ConfigTemplate Reference
    • RenderTemplate Reference
    • Workflow Configuration
    • Garden Containers on Docker Hub
    • Module Template Configuration
    • Module Types
      • configmap
      • conftest
      • container
      • exec
      • hadolint
      • helm
      • jib-container
      • kubernetes
      • persistentvolumeclaim
      • pulumi
      • templated
      • terraform
  • 🌸Misc
    • FAQ
    • Troubleshooting
    • Telemetry
    • New Garden Cloud Version
  • Contributing to Garden
    • Contributor Covenant Code of Conduct
    • Contributing to the Docs
    • Setting up your developer environment
    • Developing Garden
    • Config resolution
    • Graph execution
Powered by GitBook
On this page
  • The Stack Graph
  • The Garden CLI
  • Plugins
  • Caching
  • Templating
  • Garden Cloud

Was this helpful?

  1. Overview

How Garden Works

PreviousOverviewNextCore Concepts

Last updated 2 months ago

Was this helpful?

This page contains a brief explanation of the how and why of Garden. For those that prefer something a bit more visual, we recommend checking out this video. Otherwise, continue reading below.

The Stack Graph

Garden Core is a standalone binary that can run from CI or from a developer’s machine. It allows you to codify a complete description of your stack using intuitive YAML declarations—making your workflows reproducible and portable.

It is based on the simple idea that all DevOps workflows can be fully described in terms of the following four actions:

  • build

  • deploy

  • test

  • run (for running ad-hoc tasks)

…along with the dependencies between these actions across the components of the system.

To make a concrete example, here’s a simplified description of a three tier web application:

# This config is in a single file for convenience.
# You can split it into multiple files and even across repositories!
kind: Deploy
name: db
type: helm
spec:
  chart:
    repo: https://charts.bitnami.com/bitnami
---
kind: Run
name: db-init
type: container
dependencies: [deploy.db]
---
kind: Build
name: api
type: container
---
kind: Deploy
name: api
type: kubernetes
dependencies: [build.api, run.db-init]
spec:
  files: [api/manifests]
---
kind: Build
name: web
type: container
---
kind: Deploy
name: web
type: kubernetes
dependencies: [build.web, deploy.api]
spec:
  files: [web/manifests]
---
kind: Test
name: e2e
type: kubernetes-exec
dependencies: [deploy.api]
spec:
  args: [python, /app/test.py]

Garden collects all of these descriptions, even across multiple repositories, into the Stack Graph—an executable blueprint for going from zero to a running system in a single command.

Garden then leverages your existing configuration (Helm charts, Kubernetes manifests, Dockerfiles, Terraform files, etc) and infrastructure to execute the graph in any environment.

The Stack Graph is pluggable so how these actions (i.e. the graph nodes) are actually run depends on the plugins used (see below).

The Garden CLI

Each of the four actions (build, deploy, test, run) has a corresponding command that you can run with the Garden CLI.

For example, to create a preview environment on every pull request, simply add the following to your CI pipeline:

garden deploy --env preview

Or say a developer wants to run an end-to-end test from their laptop as they code. Again, it’s simple:

garden test --name e2e

Garden also has a special mode called "sync mode" which live reloads changes to your running deploys ensuring blazing fast feedback while developing. To enable it, simply run:

garden deploy --sync

There are also a handful of utility commands for getting logs, exec-ing into services, publishing images, and more.

Thanks to the Stack Graph, these workflows stay consistent no matter how big your stack grows.

Plugins

Garden is pluggable by design and supports a variety of providers and action types, which you can choose based on preference and to suit your existing set-up.

It’s the plugins that determine what happens when you run a given Garden command. Each action, or node in the graph, belongs to a plugin which is responsible for executing it.

You can for example use the Kubernetes plugin to install your Helm charts and apply your Kubernetes manifests, and the Terraform plugin to provision infrastructure.

For more detail on how some common plugins work, see for example:

We will be adding more plugins and releasing a Plugin SDK (exact timeline TBD) which will allow the community to maintain their own Garden plugins.

Sky’s the limit but to name some examples:

  • Plugins for serverless runtimes will allow users to mix and match platforms in the same project.

  • Security plugins that benefit from Garden’s caching and only run time consuming scans when needed.

  • Language specific plugins for streamlining workflows.

This ensures that Garden is future proof and can grow with your stack. No need to retool or disrupt developer workflows for the “next big thing”.

Caching

One of the most important features of Garden is its smart caching abilities. Thanks to the graph structure, Garden can calculate the version of any part of your system, while accounting for upstream dependencies.

This ensures that the same image never needs to be built twice or the same test run twice.

If the end-to-end test in the example above passes, Garden will know not to run it again if the code hasn’t changed. Since Garden factors in dependencies, it will however re-run the test if any of the upstream services under test are modified.

Most tools don’t have this granular understanding of the system and the choice is between running everything or nothing. With Garden you can be confident that tests run when they need to, but no more.

This alone can speed up your pipelines by orders of magnitude.

Templating

Garden has a powerful templating engine that allows you to set variables and enable or disable parts of the graph depending on your environment.

You might for e.g. deploy a development database with the Kubernetes plugin in development but use the Terraform plugin to provision a managed database for production.

This allows you to codify your entire stack and use the same workflows for all stages of software delivery.

Garden Cloud

Garden Cloud is a web platform built on top of Garden Core that adds features for teams using Garden Core such as user and secret management, log streaming, interactivity, and much more.

To learn about Garden Cloud, check out our or the official .

🌸
How the Kubernetes plugin works
How the Terraform plugin works
website
Cloud docs
The Stack Graph
Configure once, run anywhwere
Garden scales with your stack
Garden plugins