garden create project
helper command, or manually create a project.garden.yml
file in the root directory of your project:project.garden.yml
for clarity, but you can also use garden.yml
or any filename ending with .garden.yml
.project.garden.yml
file is where project-wide configuration takes place. This includes environment configurations and project variables. Most importantly, it's where you declare and configure the providers you want to use for your project (see below)..git
directory as the repo's root directory.--env
flag or by setting a defaultEnvironment
. Alternatively, Garden defaults to the first environment defined in your configuration.kubernetes
and local-kubernetes
providers set the Kubernetes namespace to <project name>-<Garden namespace>
. You can override this by setting the namespace
field in the respective provider configuration (more on that below), for example namespace: ${environment.namespace}
.dev
environment. For the latter we set the defaultNamespace
to the current username (plus a prefix), to implicitly split it up by different users.defaultNamespace: null
and require users to explicitly set a namespace at runtime. You do this by specifying --env=<namespace>.<env>
at the command line, e.g. --env=hellothisisme.dev
.defaultNamespace
set to the default, which is simply default
. So when you run Garden with --env=staging
, that automatically expands to --env=default.staging
.staging
and prod
environments have an additional flag set, the production
flag. This flag changes some default behavior and turns on protection for certain Garden commands that might be destructive, e.g. garden deploy
, requiring you to explicitly confirm that you want to execute them. See more details on that in the reference.${environment.name}
resolves to the environment name (in the above example, local
, dev
, staging
or prod
), ${environment.namespace}
resolves to the namespace, and ${environment.fullName}
resolves to the two combined with a DNS-style notation, e.g. my-namespace.dev
.type
, for example container
or kubernetes
. (We talk about adding modules in the next guide.) Providers implement some of the behaviour of these module types.garden build my-module --env empty
, the build
handler for the container
module type (which is configured automatically) will do the build, essentially calling docker build
behind the scenes. Running garden deploy
will fail because no provider is configured to handle the deployment.garden build my-module --env local
, the local-kubernetes
provider will "step in". It will still build the module via Docker but it will also push the image to the local Kubernetes cluster. Running garden deploy
will deploy the project to a local Kubernetes cluster such as Minikube or Docker Desktop.garden build my-module --env remote
, the kubernetes
provider will take over. It basically does the same thing as the build
handler for the local-kubernetes
provider, but requires some extra configuration. Running garden deploy
will deploy the project to the remote cluster.outputs
key in your project configuration that you can resolve and retrieve using the garden get outputs
command. This is handy when you need to extract some values generated by Garden for further scripting, either in a custom script or within workflows.container
module build:garden get outputs -o json
and parsing the output with jq
.project-variables
example project: