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

Was this helpful?

  1. Overview

Core Concepts

PreviousHow Garden WorksNextAdopting Garden

Last updated 2 months ago

Was this helpful?

Below you'll find a glossary of the main Garden concepts.

Garden CLI

An open-source standalone binary that's responsible for parsing Garden config and executing the actions defined there.

Dashboard

A that's a part of Garden's community tier that adds functionality to the Garden CLI such as storing command results, displaying logs, and more.

Garden config

A YAML config file with the ending garden.yml that includes some Garden configuration.

Project

The top-level unit of organization in Garden. A project consists of a project-level Garden config file and zero or more actions.

A project can be a monorepo or span multiple repositories.

Garden CLI commands are run in the context of a project.

Environment

The second level of organization in Garden after project.

Each environment includes zero or more providers and can be used to set variables for the actions that belong to it.

Environments can also be used to toggle what actions are used. For example, a Deploy action of type helm could be used to deploy an ephemeral database for a dev environment while a Deploy action of type terraform could be used to spin up a cloud managed database for a staging environment.

Plugin

Plugins are responsible for executing a given action.

Garden has built-in plugins for Kubernetes, Helm, Pulumi, local scripts, and more, and we plan on releasing a PluginSDK that allows users to add their own.

Provider

The part of a Garden plugin that holds the main configuration and knows how to handle a given action type.

For example, Garden has a kubernetes provider for remote environments and a local-kubernetes provider for local environments. Both can deploy an action of type helm but will handle them differently.

Providers are listed in the project-level Garden config and are scoped to environments.

Action

Actions are core to how Garden works and the most basic unit of organization. They are the "atoms" of a Garden project and form the nodes of the Stack Graph.

There are four actions kinds:

  • Build: describes something you build.

  • Deploy: something you deploy and expect to stay up and running.

  • Run: something you run and wait for to finish.

  • Test: also something you run and wait for to finish, similar to tasks, but with slightly different semantics and separate commands for execution.

Running garden build will e.g. execute all the Build actions for that project (i.e., it will build the project).

Similarly, actions have types (e.g. container, helm, exec) that dictate how they're executed.

Actions may define dependencies on other actions. For example, if a given Deploy action depends on a given Build, Garden will first execute the Build action and then the Deploy. Actions can also reference output from other actions.

This is a powerful concept that allows you to model a system of almost any complexity by just focusing on a single part at a time.

Stack Graph

A DAG (directed acyclic graph) that the actions and their dependencies make up for a given project and environment.

You can think of it as a blueprint of how to go from zero to a running system in a single command.

Versions

Garden generates a Garden version for each action, based on the source files and configuration involved, as well as any upstream dependencies. When using Garden, you'll see various instances of v-<some hash> strings scattered around logs, e.g. when building, deploying, running tests etc.

These versions are used by Garden and the Stack Graph to work out which actions need to be performed whenever you want to build, deploy, or test your project.

Each version also factors in the versions of every dependency. This means that anytime a version of something that is depended upon changes, every dependant's version also changes.

For example if the source code of a Build action is changed it's version will change. The Deploy action referencing the build will also have a new version due it being dependant on the build and any Test actions referencing the Deploy will also have new versions.

🌸
free web app