# The schema version of this config (currently not used).
# The type of this module.
# The name of this module.
# Specify how to build the module. Note that plugins may define additional keys on this object.
# A list of modules that must be built before this module is built.
- # Module name to build ahead of this module.
# Specify one or more files or directories to copy from the built dependency to this module.
- # POSIX-style path or filename of the directory or file(s) to copy to the target.
# POSIX-style path or filename to copy the directory or file(s), relative to the build directory.
# Defaults to to same as source path.
# Maximum time in seconds to wait for build to finish.
# For multi-stage Dockerfiles, specify which image to build (see
# https://docs.docker.com/engine/reference/commandline/build/#specifying-target-build-stage---target for details).
# A description of the module.
# Set this to `true` to disable the module. You can use this with conditional template strings to disable modules
# based on, for example, the current environment or other variables (e.g. `disabled: \${environment.name == "prod"}`).
# This can be handy when you only need certain modules for specific environments, e.g. only for development.
# Disabling a module means that any services, tasks and tests contained in it will not be deployed or run. It also
# means that the module is not built _unless_ it is declared as a build dependency by another enabled module (in which
# case building this module is necessary for the dependant to be built).
# If you disable the module, and its services, tasks or tests are referenced as _runtime_ dependencies, Garden will
# automatically ignore those dependency declarations. Note however that template strings referencing the module's
# service or task outputs (i.e. runtime outputs) will fail to resolve when the module is disabled, so you need to make
# sure to provide alternate values for those if you're using them, using conditional expressions.
# Specify a list of POSIX-style paths or globs that should be regarded as the source files for this module. Files that
# do *not* match these paths or globs are excluded when computing the version of the module, when responding to
# filesystem watch events, and when staging builds.
# Note that you can also _exclude_ files using the `exclude` field or by placing `.gardenignore` files in your source
# tree, which use the same format as `.gitignore` files. See the [Configuration Files
# guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories) for
# Also note that specifying an empty list here means _no sources_ should be included.
# If neither `include` nor `exclude` is set, and the module has a Dockerfile, Garden
# will parse the Dockerfile and automatically set `include` to match the files and
# folders added to the Docker image (via the `COPY` and `ADD` directives in the Dockerfile).
# If neither `include` nor `exclude` is set, and the module
# specifies a remote image, Garden automatically sets `include` to `[]`.
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the module. Files that match these
# paths or globs are excluded when computing the version of the module, when responding to filesystem watch events,
# and when staging builds.
# Note that you can also explicitly _include_ files using the `include` field. If you also specify the `include`
# field, the files/patterns specified here are filtered from the files matched by `include`. See the [Configuration
# Files guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories)
# Unlike the `modules.exclude` field in the project config, the filters here have _no effect_ on which files and
# directories are watched for changes. Use the project `modules.exclude` field to affect those, if you have large
# directories that should not be watched for changes.
# A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific
# branch or tag, with the format: <git remote url>#<branch|tag>
# Garden will import the repository source code into this module, but read the module's config from the local
# When false, disables pushing this module to remote registries.
# A list of files to write to the module directory when resolving this module. This is useful to automatically
# generate (and template) any supporting files needed for the module.
- # POSIX-style filename to read the source file contents from, relative to the path of the module (or the
# ModuleTemplate configuration file if one is being applied).
# This file may contain template strings, much like any other field in the configuration.
# POSIX-style filename to write the resolved file contents to, relative to the path of the module source directory
# (for remote modules this means the root of the module repository, otherwise the directory of the module
# Note that any existing file with the same name will be overwritten. If the path contains one or more
# directories, they will be automatically created if missing.
# By default, Garden will attempt to resolve any Garden template strings in source files. Set this to false to
# skip resolving template strings. Note that this does not apply when setting the `value` field, since that's
# resolved earlier when parsing the configuration.
# The desired file contents as a string.
# A map of variables scoped to this particular module. These are resolved before any other parts of the module
# configuration and take precedence over project-scoped variables. They may reference project-scoped variables, and
# generally use any template strings normally allowed when resolving modules.
# Specify a path (relative to the module root) to a file containing variables, that we apply on top of the
# module-level `variables` field.
# The format of the files is determined by the configured file's extension:
# * `.env` - Standard "dotenv" format, as defined by [dotenv](https://github.com/motdotla/dotenv#rules).
# * `.yaml`/`.yml` - YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may
# contain any value type.
# * `.json` - JSON. Must contain a single JSON _object_ (not an array).
# _NOTE: The default varfile format will change to YAML in Garden v0.13, since YAML allows for definition of nested
# To use different module-level varfiles in different environments, you can template in the environment name
# to the varfile name, e.g. `varfile: "my-module.\$\{environment.name\}.env` (this assumes that the corresponding
# Specify build arguments to use when building the container image.
# Note: Garden will always set a `GARDEN_MODULE_VERSION` argument with the module version at build time.
# Specify extra flags to use when building the container image. Note that arguments may not be portable across
# Specify the image name for the container. Should be a valid Docker image identifier. If specified and the module
# does not contain a Dockerfile, this image will be used to deploy services for this module. If specified and the
# module does contain a Dockerfile, this identifier is used when pushing the built image.
# Specifies which files or directories to sync to which paths inside the running containers of hot reload-enabled
# services when those files or directories are modified. Applies to this module's services, and to services with this
# module as their `sourceModule`.
# Specify one or more source files or directories to automatically sync into the running container.
- # POSIX-style path of the directory to sync to the target, relative to the module's top-level directory. Must be
# a relative path. Defaults to the module's top-level directory if no value is provided.
# POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not
# An optional command to run inside the container after syncing.
# POSIX-style name of Dockerfile, relative to module root.
# A list of services to deploy from this container module.
- # Valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters, numbers and dashes, must start with a letter,
# and cannot end with a dash), cannot contain consecutive dashes or start with `garden`, or be longer than 63
# The names of any services that this service depends on at runtime, and the names of any tasks that should be
# executed before this service is deployed.
# Set this to `true` to disable the service. You can use this with conditional template strings to enable/disable
# services based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name
# != "prod"}`). This can be handy when you only need certain services for specific environments, e.g. only for
# Disabling a service means that it will not be deployed, and will also be ignored if it is declared as a runtime
# dependency for another service, test or task.
# Note however that template strings referencing the service's outputs (i.e. runtime outputs) will fail to resolve
# when the service is disabled, so you need to make sure to provide alternate values for those if you're using
# them, using conditional expressions.
# Annotations to attach to the service _(note: May not be applicable to all providers)_.
# When using the Kubernetes provider, these annotations are applied to both Service and Pod resources. You can
# generally specify the annotations intended for both Pods or Services here, and the ones that don't apply on
# either side will be ignored (i.e. if you put a Service annotation here, it'll also appear on Pod specs but will
# be safely ignored there, and vice versa).
# The command/entrypoint to run the container with when starting the service.
# The arguments to run the container with when starting the service.
# Whether to run the service as a daemon (to ensure exactly one instance runs per node). May not be supported by
# Specifies which files or directories to sync to which paths inside the running containers of the service when
# it's in dev mode, and overrides for the container command and/or arguments.
# Dev mode is enabled when running the `garden dev` command, and by setting the `--dev` flag on the `garden
# See the [Code Synchronization guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for more
# Override the default container arguments when in dev mode.
# Override the default container command (i.e. entrypoint) when in dev mode.
# Specify one or more source files or directories to automatically sync with the running container.
- # POSIX-style path of the directory to sync to the target, relative to the module's top-level directory.
# Must be a relative path. Defaults to the module's top-level directory if no value is provided.
# POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the sync.
# `.git` directories and `.garden` directories are always ignored.
# The sync mode to use for the given paths. See the [Dev Mode
# guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for details.
# The default permission bits, specified as an octal, to set on files at the sync target. Defaults to 0600
# (user read/write). See the [Mutagen
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
# The default permission bits, specified as an octal, to set on directories at the sync target. Defaults to
# 0700 (user read/write). See the [Mutagen
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
# Set the default owner of files and directories at the target. Specify either an integer ID or a string
# docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for more
# Set the default group on files and directories at the target. Specify either an integer ID or a string
# docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for more
# List of ingress endpoints that the service exposes.
- # Annotations to attach to the ingress (Note: May not be applicable to all providers)
# The hostname that should route to this service. Defaults to the default hostname configured in the provider
# Note that if you're developing locally you may need to add this hostname to your hosts file.
# The link URL for the ingress to show in the console and on the dashboard. Also used when calling the service
# with the `call` command.
# Use this if the actual URL is different from what's specified in the ingress, e.g. because there's a load
# balancer in front of the service that rewrites the paths.
# Otherwise Garden will construct the link URL from the ingress spec.
# The path which should be routed to the service.
# The name of the container port where the specified paths should be routed.
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
# `GARDEN`) and values must be primitives or references to secrets.
# Specify how the service's health should be checked after deploying.
# Set this to check the service's health by making an HTTP request.
# The path of the service's health check endpoint.
# The name of the port where the service's health check endpoint should be available.
# Set this to check the service's health by running a command in its container.
# Set this to check the service's health by checking if this TCP port is accepting connections.
# The maximum number of seconds to wait until the readiness check counts as failed.
readinessTimeoutSeconds: 3
# The maximum number of seconds to wait until the liveness check counts as failed.
livenessTimeoutSeconds: 3
# If this module uses the `hotReload` field, the container will be run with this command/entrypoint when the
# service is deployed with hot reloading enabled.
# If this module uses the `hotReload` field, the container will be run with these arguments when the service is
# deployed with hot reloading enabled.
# The maximum duration (in seconds) to wait for resources to deploy and become healthy.
# The minimum amount of CPU the service needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
# The maximum amount of CPU the service can use, in millicpus (i.e. 1000 = 1 CPU)
# The minimum amount of RAM the service needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
# The maximum amount of RAM the service can use, in megabytes (i.e. 1024 = 1 GB)
# List of ports that the service container exposes.
- # The name of the port (used when referencing the port elsewhere in the service configuration).
# The protocol of the port.
# The port exposed on the container by the running process. This will also be the default value for
# This is the port you would expose in your Dockerfile and that your process listens on. This is commonly a
# non-priviledged port like 8080 for security reasons.
# The service port maps to the container port:
# `servicePort:80 -> containerPort:8080 -> process:8080`
# Specify a preferred local port to attach to when creating a port-forward to the service port. If this port
# busy, a warning will be shown and an alternative port chosen.
# The port exposed on the service. Defaults to `containerPort` if not specified.
# This is the port you use when calling a service from another service within the cluster. For example, if
# your service name is my-service and the service port is 8090, you would call it with:
# http://my-service:8090/some-endpoint.
# It is common to use port 80, the default port number, so that you can call the service directly with
# http://my-service/some-endpoint.
# The service port maps to the container port:
# `servicePort:80 -> containerPort:8080 -> process:8080`
# Set this to expose the service on the specified port on the host node (may not be supported by all
# providers). Set to `true` to have the cluster pick a port automatically, which is most often advisable if
# the cluster is shared by multiple users.
# This allows you to call the service from the outside by the node's IP address and the port number set in
# The number of instances of the service to deploy. Defaults to 3 for environments configured with `production:
# Note: This setting may be overridden or ignored in some cases. For example, when running with `daemon: true`,
# with hot-reloading enabled, or if the provider doesn't support multiple replicas.
# List of volumes that should be mounted when deploying the service.
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
# deploying the container.
- # The name of the allocated volume.
# The path where the volume should be mounted in the container.
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
# and providers. Some providers may not support it at all._
# A local path or path on the node that's running the container, to mount in the container, relative to the
# module source path (or absolute).
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
# dependency of this service, as well as a build dependency of this module.
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
# services at the same time. Refer to the documentation of the module type in question to learn more.
# If true, run the service's main container in privileged mode. Processes in privileged containers are essentially
# equivalent to root on the host. Defaults to false.
# POSIX capabilities to add to the running service's main container.
# POSIX capabilities to remove from the running service's main container.
# A list of tests to run in the module.
- # The name of the test.
# The names of any services that must be running, and the names of any tasks that must be executed, before the
# Set this to `true` to disable the test. You can use this with conditional template strings to
# enable/disable tests based on, for example, the current environment or other variables (e.g.
# `enabled: \${environment.name != "prod"}`). This is handy when you only want certain tests to run in
# specific environments, e.g. only during CI.
# Maximum duration (in seconds) of the test run.
# The arguments used to run the test inside the container.
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
# `.garden/artifacts` directory.
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
# The command/entrypoint used to run the test inside the container.
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
# `GARDEN`) and values must be primitives or references to secrets.
# The minimum amount of CPU the test needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
# The maximum amount of CPU the test can use, in millicpus (i.e. 1000 = 1 CPU)
# The minimum amount of RAM the test needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
# The maximum amount of RAM the test can use, in megabytes (i.e. 1024 = 1 GB)
# List of volumes that should be mounted when deploying the test.
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
# deploying the container.
- # The name of the allocated volume.
# The path where the volume should be mounted in the container.
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
# and providers. Some providers may not support it at all._
# A local path or path on the node that's running the container, to mount in the container, relative to the
# module source path (or absolute).
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
# dependency of this service, as well as a build dependency of this module.
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
# services at the same time. Refer to the documentation of the module type in question to learn more.
# If true, run the test's main container in privileged mode. Processes in privileged containers are essentially
# equivalent to root on the host. Defaults to false.
# POSIX capabilities to add to the running test's main container.
# POSIX capabilities to remove from the running test's main container.
# A list of tasks that can be run from this container module. These can be used as dependencies for services (executed
# before the service is deployed) or for other tasks.
- # The name of the task.
# A description of the task.
# The names of any tasks that must be executed, and the names of any services that must be running, before this
# Set this to `true` to disable the task. You can use this with conditional template strings to enable/disable
# tasks based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name !=
# "prod"}`). This can be handy when you only want certain tasks to run in specific environments, e.g. only for
# Disabling a task means that it will not be run, and will also be ignored if it is declared as a runtime
# dependency for another service, test or task.
# Note however that template strings referencing the task's outputs (i.e. runtime outputs) will fail to resolve
# when the task is disabled, so you need to make sure to provide alternate values for those if you're using them,
# using conditional expressions.
# Maximum duration (in seconds) of the task's execution.
# The arguments used to run the task inside the container.
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
# `.garden/artifacts` directory.
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
# Set to false if you don't want the task's result to be cached. Use this if the task needs to be run any time
# your project (or one or more of the task's dependants) is deployed. Otherwise the task is only re-run when its
# version changes (i.e. the module or one of its dependencies is modified), or when you run `garden run task`.
# The command/entrypoint used to run the task inside the container.
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
# `GARDEN`) and values must be primitives or references to secrets.
# The minimum amount of CPU the task needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
# The maximum amount of CPU the task can use, in millicpus (i.e. 1000 = 1 CPU)
# The minimum amount of RAM the task needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
# The maximum amount of RAM the task can use, in megabytes (i.e. 1024 = 1 GB)
# List of volumes that should be mounted when deploying the task.
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
# deploying the container.
- # The name of the allocated volume.
# The path where the volume should be mounted in the container.
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
# and providers. Some providers may not support it at all._
# A local path or path on the node that's running the container, to mount in the container, relative to the
# module source path (or absolute).
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
# dependency of this service, as well as a build dependency of this module.
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
# services at the same time. Refer to the documentation of the module type in question to learn more.
# If true, run the task's main container in privileged mode. Processes in privileged containers are essentially
# equivalent to root on the host. Defaults to false.
# POSIX capabilities to add to the running task's main container.
# POSIX capabilities to remove from the running task's main container.