Commands
Below is a list of Garden CLI commands and usage information.
The commands should be run in a Garden project, and are always scoped to that project.
Note: You can get a list of commands in the CLI by running garden -h/--help
, and detailed help for each command using garden <command> -h/--help
The Outputs sections show the output structure when running the command with --output yaml
. The same structure is used when --output json
is used and when querying through the REST API, but in JSON format.
Global options
The following option flags can be used with any of the CLI commands:
Argument | Alias | Type | Description |
---|---|---|---|
| path | Override project root directory (defaults to working directory). Can be absolute or relative to current directory. | |
| string | The environment (and optionally namespace) to work against. | |
| boolean | Force refresh of any caches, e.g. cached provider statuses. | |
| array:string | Set a specific variable value, using the format <key>=<value>, e.g. `--var some-key=custom-value`. This will override any value set in your project configuration. You can specify multiple variables by separating with a comma, e.g. `--var key-a=foo,key-b="value with quotes"`. | |
| boolean | Automatically approve any yes/no prompts during execution, and allow running protected commands against production environments. | |
| boolean | Suppress log output. Same as setting --logger-type=quiet. | |
|
| Set logger type. default The default Garden logger, basic: [DEPRECATED] An alias for "default". json: Renders log lines as JSON. quiet: Suppresses all log output, same as --silent. | |
|
| Set logger level. Values can be either string or numeric and are prioritized from 0 to 5 (highest to lowest) as follows: error: 0, warn: 1, info: 2, verbose: 3, debug: 4, silly: 5. From the verbose log level onward action execution logs are also printed (e.g. test or run live log outputs). | |
|
| Output command result in specified format (note: disables progress logging and interactive functionality). | |
| boolean | Enable emoji in output (defaults to true if the environment supports it). | |
| boolean | Show timestamps with log output. When enabled, Garden will use the basic logger. I.e., log status changes are rendered as new lines instead of being updated in-place. | |
| boolean | Show the current CLI version. | |
| boolean | Show help |
garden build
Perform your Builds.
Runs all or specified Builds, taking into account build dependency order. Optionally stays running and automatically builds when sources (or dependencies' sources) change.
Examples:
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | Specify Builds to run. You may specify multiple names, separated by spaces. |
Options
Argument | Alias | Type | Description |
---|---|---|---|
| boolean | Force re-build. | |
| boolean | Also rebuild any Builds that depend on one of the Builds specified as CLI arguments (recursively). Note: This option has no effect unless a list of Build names is specified as CLI arguments (since otherwise, every Build in the project will be performed anyway). |
Outputs
garden cloud secrets list
List secrets defined in Garden Cloud.
List all secrets from Garden Cloud. Optionally filter on environment, user IDs, or secret names.
Examples: garden cloud secrets list # list all secrets garden cloud secrets list --filter-envs dev # list all secrets from the dev environment garden cloud secrets list --filter-envs dev --filter-names DB # list all secrets from the dev environment that have 'DB' in their name.
Usage
Options
Argument | Alias | Type | Description |
---|---|---|---|
| array:string | Filter on environment. You may filter on multiple environments by setting this flag multiple times. Accepts glob patterns." | |
| array:string | Filter on user ID. You may filter on multiple user IDs by setting this flag multiple times. Accepts glob patterns. | |
| array:string | Filter on secret name. You may filter on multiple secret names by setting this flag multiple times. Accepts glob patterns. |
garden cloud secrets create
Create secrets in Garden Cloud.
Create secrets in Garden Cloud. You can create project wide secrets or optionally scope them to an environment, or an environment and a user.
To scope secrets to a user, you will need the user's ID which you can get from the garden cloud users list
command.
You can optionally read the secrets from a file.
Examples: garden cloud secrets create DB_PASSWORD=my-pwd ACCESS_KEY=my-key # create two secrets garden cloud secrets create ACCESS_KEY=my-key --scope-to-env ci # create a secret and scope it to the ci environment garden cloud secrets create ACCESS_KEY=my-key --scope-to-env ci --scope-to-user 9 # create a secret and scope it to the ci environment and user with ID 9 garden cloud secrets create --from-file /path/to/secrets.txt # create secrets from the key value pairs in the secrets.txt file
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | The names and values of the secrets to create, separated by '='. You may specify multiple secret name/value pairs, separated by spaces. Note that you can also leave this empty and have Garden read the secrets from file. |
Options
Argument | Alias | Type | Description |
---|---|---|---|
| string | Scope the secret to a user with the given ID. User scoped secrets must be scoped to an environment as well. | |
| string | Scope the secret to an environment. Note that this does not default to the environment that the command runs in (i.e. the one set via the --env flag) and that you need to set this explicitly if you want to create an environment scoped secret. | |
| path | Read the secrets from the file at the given path. The file should have standard "dotenv" format, as defined by dotenv. |
garden cloud secrets update
Update secrets in Garden Cloud
Update secrets in Garden Cloud. You can update the secrets by either specifying secret name or secret ID.
By default, the secrets are updated by name instead of secret ID.
When updating by name, only the existing secrets are updated by default. The missing ones are skipped and reported as errors at the end of the command execution. This behavior can be customized with the --upsert
flag, so the missing secrets will be created.
If you have multiple secrets with same name across different environments and users, specify the environment and the user id using --scope-to-env
and --scope-to-user-id
flags. Otherwise, the command will fail with an error.
To update the secrets by their IDs, use the --update-by-id
flag. To get the IDs of the secrets you want to update, run the garden cloud secrets list
command. The --upsert
flag has no effect if it's used along with the --update-by-id
flag.
Examples: garden cloud secrets update MY_SECRET=foo MY_SECRET_2=bar # update two secret values with the given names. garden cloud secrets update MY_SECRET=foo MY_SECRET_2=bar --upsert # update two secret values with the given names and create new ones if any are missing garden cloud secrets update MY_SECRET=foo MY_SECRET_2=bar --scope-to-env local --scope-to-user-id # update two secret values with the given names for the environment local and specified user id. garden cloud secrets update <ID 1>=foo <ID 2>=bar --update-by-id # update two secret values with the given IDs.
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | The names and values of the secrets to update, separated by '='. You may specify multiple secret name/value pairs, separated by spaces. You can also pass pairs of secret IDs and values if you use `--update-by-id` flag. Note that you can also leave this empty and have Garden read the secrets from file. |
Options
Argument | Alias | Type | Description |
---|---|---|---|
| boolean | Set this flag to upsert secrets instead of only updating them. It means that the existing secrets will be updated while the missing secrets will be created. This flag works only while updating secrets by name, and has no effect with `--update-by-id` option. | |
| boolean | Update secret(s) by secret ID(s). By default, the command args are considered to be secret name(s). The `--upsert` flag has no effect with this option. | |
| path | Read the secrets from the file at the given path. The file should have standard "dotenv" format, as defined by dotenv. | |
| string | Update the secret(s) in scope of user with the given user ID. This must be specified if you want to update secrets by name instead of secret ID. | |
| string | Update the secret(s) in scope of the specified environment. This must be specified if you want to update secrets by name instead of secret ID. |
garden cloud secrets delete
Delete secrets from Garden Cloud.
Delete secrets in Garden Cloud. You will need the IDs of the secrets you want to delete, which you which you can get from the garden cloud secrets list
command.
Examples: garden cloud secrets delete <ID 1> <ID 2> <ID 3> # delete three secrets with the given IDs.
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | The ID(s) of the secrets to delete. |
garden cloud users list
List users defined in Garden Cloud.
List all users from Garden Cloud. Optionally filter on group names or user names.
Examples: garden cloud users list # list all users garden cloud users list --filter-names Gordon* # list all the Gordons in Garden Cloud. Useful if you have a lot of Gordons. garden cloud users list --filter-groups devs-* # list all users in groups that with names that start with 'dev-'
Usage
Options
Argument | Alias | Type | Description |
---|---|---|---|
| array:string | Filter on user name. You may filter on multiple names by setting this flag multiple times. Accepts glob patterns. | |
| array:string | Filter on the groups the user belongs to. You may filter on multiple groups by setting this flag multiple times. Accepts glob patterns. |
garden cloud users create
Create users in Garden Cloud.
Create users in Garden Cloud and optionally add the users to specific groups. You can get the group IDs from the garden cloud users list
command.
To create a user, you'll need their GitHub or GitLab username, depending on which one is your VCS provider, and the name they should have in Garden Cloud. Note that it must the their GitHub/GitLab username, not their email, as people can have several emails tied to their GitHub/GitLab accounts.
You can optionally read the users from a file. The file must have the format vcs-username="Actual Username". For example:
fatema_m="Fatema M" gordon99="Gordon G"
Examples: garden cloud users create fatema_m="Fatema M" gordon99="Gordon G" # create two users garden cloud users create fatema_m="Fatema M" --add-to-groups 1,2 # create a user and add two groups with IDs 1,2 garden cloud users create --from-file /path/to/users.txt # create users from the key value pairs in the users.txt file
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | The VCS usernames and the names of the users to create, separated by '='. You may specify multiple VCS username/name pairs, separated by spaces. Note that you can also leave this empty and have Garden read the users from file. |
Options
Argument | Alias | Type | Description |
---|---|---|---|
| array:string | Add the user to the group with the given ID. You may add the user to multiple groups by setting this flag multiple times. | |
| path | Read the users from the file at the given path. The file should have standard "dotenv" format (as defined by dotenv) where the VCS username is the key and the name is the value. |
garden cloud users delete
Delete users from Garden Cloud.
Delete users in Garden Cloud. You will need the IDs of the users you want to delete, which you which you can get from the garden cloud users list
command. Use a comma- separated list to delete multiple users.
Examples: garden cloud users delete <ID 1> <ID 2> <ID 3> # delete three users with the given IDs.
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | The IDs of the users to delete. |
garden cloud groups list
List groups defined in Garden Cloud.
List all groups from Garden Cloud. This is useful for getting the group IDs when creating users via the garden cloud users create
command.
Examples: garden cloud groups list # list all groups garden cloud groups list --filter-names dev-* # list all groups that start with 'dev-'
Usage
Options
Argument | Alias | Type | Description |
---|---|---|---|
| array:string | Filter on group name. You may filter on multiple names by setting this flag multiple times. Accepts glob patterns. |
garden community
Join our community Discord to chat with us!
Opens the Garden Community Discord invite link
Usage
garden config analytics-enabled
Update your preferences regarding analytics.
To help us make Garden better, we collect some analytics data about its usage. We make sure all the data collected is anonymized and stripped of sensitive information. We collect data about which commands are run, what tasks they trigger, which API calls are made to your local Garden server, as well as some info about the environment in which Garden runs.
You will be asked if you want to opt out when running Garden for the first time and you can use this command to update your preferences later.
Examples:
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | Enable analytics. Defaults to "true" |
garden create project
Create a new Garden project.
Creates a new Garden project configuration. The generated config includes some default values, as well as the schema of the config in the form of commented-out fields. Also creates a default (blank) .gardenignore file in the same path.
Examples:
Usage
Options
Argument | Alias | Type | Description |
---|---|---|---|
| path | Directory to place the project in (defaults to current directory). | |
| string | Filename to place the project config in (defaults to project.garden.yml). | |
| boolean | Set to false to disable interactive prompts. | |
| string | Name of the project (defaults to current directory name). |
garden cleanup namespace
Deletes a running namespace.
This will clean up everything deployed in the specified environment, and trigger providers to clear up any other resources and reset it. When you then run garden deploy
after, the namespace will be reconfigured.
This can be useful if you find the namespace to be in an inconsistent state, or need/want to free up resources.
Usage
Options
Argument | Alias | Type | Description |
---|---|---|---|
| boolean | Clean up Deploy(s) (or services if using modules) in reverse dependency order. That is, if service-a has a dependency on service-b, service-a will be deleted before service-b when calling `garden cleanup namespace service-a,service-b --dependants-first`. |
When this flag is not used, all services in the project are cleaned up simultaneously.
Outputs
garden cleanup deploy
Cleans up running deployments (or services if using modules).
Cleans up (i.e. un-deploys) the specified actions. Cleans up all deploys/services in the project if no arguments are provided. Note that this command does not take into account any deploys depending on the cleaned up actions, and might therefore leave the project in an unstable state. Running garden deploy
after will re-deploy anything missing.
Examples:
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | The name(s) of the deploy(s) (or services if using modules) to delete. You may specify multiple names, separated by spaces. |
Options
Argument | Alias | Type | Description |
---|---|---|---|
| boolean | Clean up Deploy(s) (or services if using modules) in reverse dependency order. That is, if service-a has a dependency on service-b, service-a will be deleted before service-b when calling `garden cleanup namespace service-a,service-b --dependants-first`. |
When this flag is not used, all services in the project are cleaned up simultaneously. | --with-dependants
| | boolean | Also clean up deployments/services that have dependencies on one of the deployments/services specified as CLI arguments (recursively). When used, this option implies --dependants-first. Note: This option has no effect unless a list of names is specified as CLI arguments (since then, every deploy/service in the project will be deleted).
Outputs
garden deploy
Deploy actions to your environment.
Deploys all or specified Deploy actions, taking into account dependency order. Also performs builds and other dependencies if needed.
Optionally stays running and automatically re-builds and re-deploys if sources (or dependencies' sources) change.
Examples:
Usage
Arguments
Argument | Required | Description |
---|---|---|
| No | The name(s) of the Deploy(s) (or services if using modules) to deploy (skip to deploy everything). You may specify multiple names, separated by spaces. |
Options
Argument | Alias | Type | Description |
---|---|---|---|
| boolean | Force re-deploy. | |
| boolean | Force re-build of build dependencies. | |
| array:string | The name(s) of the Deploy(s) to deploy with sync enabled. | |
You may specify multiple names by setting this flag multiple times. | |||
Use * to deploy all supported deployments with sync enabled. |
Important: The syncs stay active after the command exits. To stop the syncs, use the `sync stop` command. | --local-mode
| | array:string | [EXPERIMENTAL] The name(s) of Deploy(s) to be started locally with local mode enabled.
You may specify multiple Deploys by setting this flag multiple times. Use * to deploy all Deploys with local mode enabled. When this option is used, the command stays running until explicitly aborted.
This always takes the precedence over sync mode if there are any conflicts, i.e. if the same Deploys are matched with both `--sync` and `--local` options. | --skip
| | array:string | The name(s) of Deploys you'd like to skip. | --skip-dependencies
| | boolean | Skip deploy, test and run dependencies. Build dependencies and runtime output reference dependencies are not skipped. This can be useful e.g. when your stack has already been deployed, and you want to run specific Deploys in sync mode without deploying or running dependencies that may have changed since you last deployed. | --with-dependants
| | boolean | Additionally deploy all deploy actions that are downstream dependants of the action(s) being deployed. This can be useful when you know you need to redeploy dependants. | --disable-port-forwards
| | boolean | Disable automatic port forwarding when running persistently. Note that you can also set GARDEN_DISABLE_PORT_FORWARDS=true in your environment. | --forward
| | boolean | Create port forwards and leave process running after deploying. This is implied if any of --sync / --local or --logs are set. | --logs
| | boolean | Stream logs from the requested Deploy(s) (or services if using modules) during deployment, and leave the log streaming process running after deploying. Note: This option implies the --forward option. | --timestamps
| | boolean | Show timestamps with log output. Should be used with the `--logs` option (has no effect if that option is not used). | --port
| | number | The port number for the server to listen on (defaults to 9777 if available).