LogoLogo
Bonsai (0.13) DocsGitHubDiscord CommunityGarden Enterprise
Docs Edge
Docs Edge
  • Welcome to Garden!
  • Overview
    • What is Garden
    • 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
    • Garden vs Other Tools
  • Getting Started
    • Quickstart
    • Garden Basics
    • 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
    • Setting up a Kubernetes cluster
      • 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
  • Using Garden With
    • Containers
      • Using Remote Container Builder
      • Building Containers
    • Kubernetes
      • Using Remote Kubernetes
      • Using Local Kubernetes
      • Deploying K8s Resources
      • Installing Helm charts
      • Running Tests and Tasks
    • Terraform
      • Using Terraform
      • Applying Terrform Stacks
    • Pulumi
      • Using Pulumi
      • Applying Pulumi Stacks
    • Local Scripts
  • Features
    • Remote Container Builder
    • Team Caching
    • Variables and Templating
    • Config Templates
    • Workflows
    • Code Synchronization
    • Custom Commands
    • Remote Sources
  • Guides
    • Connecting a Project
    • Environments and Namespaces
    • Installing Garden
    • Including/Excluding files
    • Installing Local Kubernetes
    • Migrating from Docker Compose to Garden
    • Using the CLI
    • Using Garden in CircleCI
    • Minimal RBAC Configuration for Development Clusters
    • Deploying to Production
    • Using a Registry Mirror
    • Local mode
  • Reference
    • Providers
      • container
      • ephemeral-kubernetes
      • exec
      • jib
      • kubernetes
      • local-kubernetes
      • 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
        • container Test
        • exec 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
    • Glossary
    • Module Template Configuration
    • Module Types
      • configmap
      • container
      • exec
      • helm
      • jib-container
      • kubernetes
      • persistentvolumeclaim
      • pulumi
      • templated
      • terraform
  • Misc
    • FAQ
    • Troubleshooting
    • Telemetry
    • How Organizations Adopt Garden
    • New Garden Cloud Version
    • Migrating to Bonsai
  • 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
  • CI systems (GitHub Actions, BuildKite etc.)
  • PaaS (Heroku, Fly etc.)
  • Internal developer portals (Backstage, Cortex etc.)
  • Deployment and IaC tools (Helm, kubectl, Terraform, Pulumi etc.)
  • Kubernetes dev tools (Okteto, Skaffold, Loft)
  • GitOps CD tools (Argo, Flux)
  • Custom deployment scripts

Was this helpful?

  1. Overview

Garden vs Other Tools

The tooling landscape for cloud development has gotten a lot more crowded over the past few years. In this doc, we’ll put Garden in context by comparing and contrasting it with other types of tools and platforms.

In short, Garden automates the process of building, deploying, developing and testing applications in a way that’s simpler, faster and way easier to maintain than laboriously writing CI pipelines or shell scripts by hand.

On top of this, it’s got code syncing for live reloading during development, live log streaming and an intuitive web interface. It combines advanced CI automation with a first-class experience during development and debugging.

CI systems (GitHub Actions, BuildKite etc.)

Garden is not intended to replace traditional CI systems—in fact, the most common use-case for Garden is calling it in CI!

Where Garden fits into CI pipelines is by taking care of building, deploying and testing a graph of components (and publishing the built images afterwards if needed).

Garden can greatly simplify the task of creating ephemeral environments for every pull request, deploying to a staging environment on merges to the main branch, and running test suites involving one or more runtime components (e.g. API tests, end-to-end tests and load tests).

Our users report that over time the amount of YAML in their CI pipeline definitions shrinks down to almost nothing, since deploying an entire environment or running an end-to-end test suite becomes just garden deploy or garden test.

On top of that, developers and DevOps engineers alike can run Garden from their dev machines to reproduce anything that goes wrong in CI. No need to repeatedly re-trigger pipelines just to see if your fix works—your laptop can now do anything your CI system can!

PaaS (Heroku, Fly etc.)

PaaS (platform-as-a-service) offerings provide developers with simplified abstractions of the underlying platform (e.g. Kubernetes or AWS EC2), and often come with their own special-purpose tools (CLIs and the like).

In contrast, Garden isn’t a hosting platform at all. It builds, deploys and tests on your own infrastructure. Bring your own infrastructure, and Garden will take it from there.

Just point it at a Kubernetes cluster or your AWS/Azure/GCP account, and Garden will build, deploy and test your application using the Dockerfiles, Kubernetes manifests, Helm charts, Terraform stacks etc. that you’re already using in CI or production.

Our goal is to add automation on top of what you already have, not to abstract it away.

This has two main benefits:

  1. It keeps Garden simple to use and understand—we’re not trying to reinvent the wheel when it comes to building, deploying and testing—we delegate to specialist tools like BuildKit, kubectl, Helm and Terraform to do what they’re best at.

  2. It lets Garden work for any system, no matter how simple or complex. Since we’re not asking you to fundamentally change how you’re building, deploying or testing your application, you can always add Garden on top of it to bring advanced dev & testing automation to your project.

Internal developer portals (Backstage, Cortex etc.)

These tools take a different approach to dev automation: After being configured by DevOps engineers, they provide a point-and-click way for developers to create environments or deploy specific components. This is a simple and easy-to-use approach for companies where developers prefer to abstract away the complexity of the underlying system during development.

Garden also enables developers to easily deploy an entire environment or a subset of components (via the garden deploy command).

But it also goes a lot further than just deploying environments:

  • Testing is a built-in primitive in Garden.

  • Live-reloading during development via code syncing, and building without going through CI.

  • Garden can be run from your dev machine, without committing & pushing your changes! This is a big deal when you're working on a feature and need a rapid code/debug/test loop to stay productive.

  • Live log streaming from running services during development.

All in all, Garden provides more out-of-the box functionality for the developer, and tries to automate not just the creation of environments, but to provide a first-class developer experience when writing, debugging and testing code ( the perfect companion to your editor/IDE of choice).

In short, Garden merges the capabilities of a CI system with that of a developer tool.

Another difference is that tools like Backstage and Cortex are typically adopted by platform teams, whereas Garden is typically adopted by lead developers or DevOps engineers on individual teams, i.e. the people who are directly involved with CI & dev automation for a given team.

Deployment and IaC tools (Helm, kubectl, Terraform, Pulumi etc.)

We work together! Garden has plugins for deploying using Helm, kubectl, Terraform and Pulumi. Our philosophy is to work with the way your system is currently built, deployed and tested, and focus on being the graph automation and developer experience layer on top of those building blocks.

Kubernetes dev tools (Okteto, Skaffold, Loft)

These tools take a more focused approach to solving specific problems in developing apps for Kubernetes, and also generally focus only on Kubernetes (there's no support for Terraform or Pulumi, for example).

Like Garden, they offer code syncing, building and deploying, but don't have a built-in notion of testing. They're not intended to do the heavy lifting in a complex CI pipeline, but they're good at what they do. They also tend to be simpler to understand and get started with than Garden.

GitOps CD tools (Argo, Flux)

Garden works well with GitOps-based CD tools. In short, Garden helps with everything up to production deployments, which most users prefer to do with dedicated CD tools.

The process is usually something like this (using ArgoCD as an example):

  1. A developer uses Garden to debug & test a feature in a production-like dev environment.

  2. After the developer opens a PR, a CI pipeline calls the Garden CLI to deploy an ephemeral environment from the branch (via garden deploy), and run the full set of test suites (via garden test).

  3. After the PR is approved, a pipeline uses garden publish to publish the built images to the production container registry, where they're picked up by e.g. the ArgoCD image updater.

  4. ArgoCD then triggers the production deployment process and takes things from there.

Custom deployment scripts

While custom scripts and other in-house tooling gives you complete control, it also means a lot more work for your team down the line. Scripts also tend to be brittle, and are hard to maintain and test when new components are introduced, or dependencies change.

Garden's Stack Graph means you can easily add or remove components and change their dependencies, and your pipelines automatically adapt (since the execution graph is automatically generated from your Garden configs).

Garden's Run actions (one of the four main action kinds, the others being Builds, Deploys and Tests) can also be used to wrap any script or tool that you'd like to call in your pipeline, so you always have a general-purpose escape hatch for any custom logic you need to run in your pipeline that doesn't fit easily into Garden's way of doing things.

PreviousJumpstart your Internal Developer PlatformNextQuickstart

Last updated 1 month ago

Was this helpful?

See our for a full example of this.

blog post on using Garden with ArgoCD and Helm