Using the CLI
Here, we'll describe at a high level the common day-to-day usage of the Garden CLI, with specific examples.
The garden CLI is how you work with Garden in most scenarios, during development and in CI pipelines. It features a fairly large number of commands, so we'll list the most common ones below. You can run garden --help to list them, and use garden <command> --help to learn more about individual commands, arguments, option flags, usage examples etc. You can also find a full reference here.
If you've not installed the CLI yet, please check out the installation guide.
Most of the examples below assume that you've already defined a Garden project.
The garden dev command, as well as the build, deploy and test commands (when run with the --watch flag) all start a web dashboard that you can open in a browser. See the dashboard section for more on that.
It is currently not advisable to run multiple dev, build, deploy or test commands in parallel, especially with --watch because they may interfere with each other. It is fine, however, to run one of those and then run other commands to the side, such as garden logs. We plan on improving this in the future.
Every Garden command supports a common set of option flags. The full reference can be found here, but here are the most important ones:
--envsets the environment (and optionally namespace) that the command should act on. Most Garden commands only act on a specific environment, so in most cases you'll specify this, unless you're working on the default environment for the project. See here for more about environments and namespaces.--log-level/-lsets the log level. Use e.g.-l=debugto get debug logs for the command.--logger-type=basicdisables the fancy log output (with spinners etc.) and just prints a simple line-by-line output. SettingGARDEN_LOGGER_TYPE=basicdoes the same thing. You should set that environment variable in CI and other automated environments.--output/-osets the output format. Use this to get structured output from the commands.--output=jsonoutputs JSON, and--output=yamloutputs YAML. The structure of the outputs is documented in the reference for most commands.
All option flags can be specified with a space or a = between the flag and the value.
This deploys all your services to the default environment and namespace.
garden deploy
This deploys your services to my-namespace in the dev environment.
garden deploy --env my-namespace.dev
garden deploy my-service
When arguments accept one or more services, modules etc. we comma-separate the names.
garden deploy service-a,service-b
garden deploy my-service --watch # or -w for short
See the Hot reload guide for more information on how to configure and use hot reloading for rapid iteration on services. Enabling --hot-reload implicitly sets --watch=true.
garden deploy my-service --hot-reload=* # or --hot for short
garden run service my-service --interactive # or -i for short
garden exec my-service <command>
Note: This assumes that sh is available in the container.
garden exec my-service -i sh
garden get status
This is suitable for parsing with e.g. the jq utility.
garden get status --output=json # or `-o json` for short
This removes all running services in my-namespace in the dev environment.
garden delete env --env=my-namespace.dev
garden delete service my-service
garden test
garden test my-module --watch
This runs the integ test, defined in my-module, and watches for changes (including changes in modules and services that the test depends on).
garden test my-module --name integ -w
This is handy for running a single test and streaming the log outputs (garden test, in comparison, is more meant to run multiple ones or watch for changes, and is less suitable for getting log output).
garden run test my-module my-test -i
garden run task my-task
garden build
garden build --force # or -f for short
garden build my-module
garden build my-module -w
This will start a dashboard as well.
Runs my-workflow in my-namespace in the dev environment.
garden run workflow my-workflow --env=my-namespace.dev
garden logs
garden logs my-service
garden logs my-service --follow # or -f for short
The garden dev command builds, deploys and tests all parts of your project, and also runs any tasks that are listed as dependencies for your services and tests. It then waits for any code changes, and automatically re-builds, re-deploys and re-runs any parts affected by your code changes.
This is handy for small projects, and when your code changes don't tend to trigger a lot of heavy operations, but may be too "busy" to run for large projects or when you're making big changes to your code.
garden dev
garden dev --skip-tests
See the Hot reload guide for more information on how to configure and use hot reloading for rapid iteration on services.
garden dev --hot-reload=*
garden dev --hot-reload=my-service
The garden dev command, as well as the build, deploy and test commands when run with the --watch flag all start a web dashboard that you can open in a browser. See the dashboard section for more on that.
The CLI will print a URL which you can copy or click (or Cmd/Ctrl-click, depending on your terminal). The dashboard stays open while the command is running.
The dashboard gives you:
An overview of all the parts of your project, including links to any configured ingresses on your services.
A visualization of your Stack Graph, where you can see the status of each node, and click them to get the most recent status or logs.
A log viewer, which you can use to fetch the latest logs for your services.
For rapid iteration on a running service, you can use an advanced feature called hot reloading. See the Hot reload guide for details on how to configure and use that feature.
Project outputs are a handy way to extract generated values from your project.
garden get outputs
This you can use to parse in scripts, e.g. using jq.
garden get outputs --output=json # or `-o json` for short
You can also output in YAML with --output=yaml.
This bootstraps a boilerplate garden.yml with a project definition in the current directory, and a .gardenignore file.
garden create project
This bootstraps a boilerplate garden.yml with a module definition in the current directory. You'll get an interactive menu to select a module type. You may get suggestions for appropriate module types, depending on which files are found in the directory (such as a container module when a Dockerfile is found).
garden create module
Remote sources are a mechanism to connect multiple git repositories in a single Garden project. See the remote sources guide for more information, including how to use the CLI to manage these sources.
Individual plugins (currently referred to as providers in your project configuration) may include specific commands that help with their usage and operation. The available commands will depend on which providers are configured in your project.
You can run garden plugins without arguments to list the available commands.
When using a remote Kubernetes cluster and in-cluster building, the cluster needs to be set up with some shared services when you first start using it, when you update the provider configuration, or sometimes when you update to a new Garden version. See the remote kubernetes guide for more information.
Here we initialize the cluster configured for the dev environment:
garden plugins kubernetes cluster-init --env=dev
When you use in-cluster building, the image caches build up over time and need to be cleaned up periodically. Use this command for that:
garden plugins kubernetes cleanup-cluster-registry --env=dev
The terraform provider includes several commands that facilitate interaction with the Terraform stacks in your project. See the Terraform guide for more information.
Garden plugins generally define their external tool dependencies, such that Garden can automatically fetch them ahead of use. The garden tools command exposes these tools, so that you can use them without having to install them separately. You can also use these to ensure that you're using the exact same versions as the Garden plugins.
Note that this command currently only works when run within a Garden project root.
If you use this frequently, we recommend defining the following helper function for quick access:
# Note: This is made to work in bash and zsh, other shells may need a different syntaxfunction gt() {garden tools $1 -- "${@:2}"}
You can then type e.g. gt docker build . to run docker build . using the Garden-provided version of the docker CLI.
Run garden tools to get a full list of available tools, and garden tools --help for more usage information.
Note that the -- is necessary to distinguish between Garden options, and kubectl arguments. See above for a shorthand function you can put in your shell profile.
garden tools kubectl -- <args>
This prints the absolute path to the kubectl binary defined by the kubernetes provider, downloading it first if necessary.
garden tools kubectl --get-path
Take a look at our Guides section for in-depth guides on specific use cases and setups, or keep exploring other sections under Using Garden to learn more about Garden concepts and configuration.
