providers:
  - # List other providers that should be resolved before this one.
    dependencies: []
​
    # If specified, this provider will only be used in the listed environments. Note that an empty array effectively
    # disables the provider. To use a provider in all environments, omit this field.
    environments:
​
    # Choose the mechanism for building container images before deploying. By default your local Docker daemon is
    # used, but you can set it to `cluster-buildkit`, `cluster-docker` or `kaniko` to sync files to the cluster, and
    # build container images there. This removes the need to run Docker locally, and allows you to share layer and
    # image caches between multiple developers, as well as between your development and CI workflows.
    #
    # For more details on all the different options and what makes sense to use for your setup, please check out the
    # [in-cluster building guide](https://docs.garden.io/guides/in-cluster-building).
    buildMode: local-docker
​
    # Configuration options for the `cluster-buildkit` build mode.
    clusterBuildkit:
      # Enable rootless mode for the cluster-buildkit daemon, which runs the daemon with decreased privileges.
      # Please see [the buildkit docs](https://github.com/moby/buildkit/blob/master/docs/rootless.md) for caveats when
      # using this mode.
      rootless: false
​
      # Exposes the `nodeSelector` field on the PodSpec of the BuildKit deployment. This allows you to constrain the
      # BuildKit daemon to only run on particular nodes.
      #
      # [See here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) for the official Kubernetes
      # guide to assigning Pods to nodes.
      nodeSelector: {}
​
    # Configuration options for the `cluster-docker` build mode.
    clusterDocker:
      # Enable [BuildKit](https://github.com/moby/buildkit) support. This should in most cases work well and be more
      # performant, but we're opting to keep it optional until it's enabled by default in Docker.
      enableBuildKit: false
​
    # Configuration options for the `kaniko` build mode.
    kaniko:
      # Specify extra flags to use when building the container image with kaniko. Flags set on `container` modules
      # take precedence over these.
      extraFlags:
​
      # Change the kaniko image (repository/image:tag) to use when building in kaniko mode.
      image: 'gcr.io/kaniko-project/executor:v1.6.0-debug'
​
      # Choose the namespace where the Kaniko pods will be run. Set to `null` to use the project namespace.
      #
      # **IMPORTANT: The default namespace will change to the project namespace instead of the garden-system namespace
      # in an upcoming release!**
      namespace: garden-system
​
      # Exposes the `nodeSelector` field on the PodSpec of the Kaniko pods. This allows you to constrain the Kaniko
      # pods to only run on particular nodes.
      #
      # [See here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) for the official Kubernetes
      # guide to assigning Pods to nodes.
      nodeSelector:
​
    # A default hostname to use when no hostname is explicitly configured for a service.
    defaultHostname:
​
    # Defines the strategy for deploying the project services.
    # Default is "rolling update" and there is experimental support for "blue/green" deployment.
    # The feature only supports modules of type `container`: other types will just deploy using the default strategy.
    deploymentStrategy: rolling
​
    # Require SSL on all `container` module services. If set to true, an error is raised when no certificate is
    # available for a configured hostname on a `container` module.
    forceSsl: false
​
    # References to `docker-registry` secrets to use for authenticating with remote registries when pulling
    # images. This is necessary if you reference private images in your module configuration, and is required
    # when configuring a remote Kubernetes environment with buildMode=local.
    imagePullSecrets:
      - # The name of the Kubernetes secret.
        name:
​
        # The namespace where the secret is stored. If necessary, the secret may be copied to the appropriate
        # namespace before use.
        namespace: default
​
    # Resource requests and limits for the in-cluster builder, container registry and code sync service. (which are
    # automatically installed and used when `buildMode` is `cluster-docker` or `kaniko`).
    resources:
      # Resource requests and limits for the in-cluster builder. It's important to consider which build mode you're
      # using when configuring this.
      #
      # When `buildMode` is `kaniko`, this refers to _each Kaniko pod_, i.e. each individual build, so you'll want to
      # consider the requirements for your individual image builds, with your most expensive/heavy images in mind.
      #
      # When `buildMode` is `cluster-buildkit`, this applies to the BuildKit deployment created in _each project
      # namespace_. So think of this as the resource spec for each individual user or project namespace.
      #
      # When `buildMode` is `cluster-docker`, this applies to the single Docker Daemon that is installed and run
      # cluster-wide. This is shared across all users and builds in the cluster, so it should be resourced
      # accordingly, factoring in how many concurrent builds you expect and how heavy your builds tend to be.
      builder:
        limits:
          # CPU limit in millicpu.
          cpu: 4000
​
          # Memory limit in megabytes.
          memory: 8192
​
        requests:
          # CPU request in millicpu.
          cpu: 100
​
          # Memory request in megabytes.
          memory: 512
​
      # Resource requests and limits for the in-cluster image registry. Built images are pushed to this registry,
      # so that they are available to all the nodes in your cluster.
      #
      # This is shared across all users and builds, so it should be resourced accordingly, factoring
      # in how many concurrent builds you expect and how large your images tend to be.
      registry:
        limits:
          # CPU limit in millicpu.
          cpu: 2000
​
          # Memory limit in megabytes.
          memory: 4096
​
        requests:
          # CPU request in millicpu.
          cpu: 200
​
          # Memory request in megabytes.
          memory: 512
​
      # Resource requests and limits for the code sync service, which we use to sync build contexts to the cluster
      # ahead of building images. This generally is not resource intensive, but you might want to adjust the
      # defaults if you have many concurrent users.
      sync:
        limits:
          # CPU limit in millicpu.
          cpu: 500
​
          # Memory limit in megabytes.
          memory: 512
​
        requests:
          # CPU request in millicpu.
          cpu: 100
​
          # Memory request in megabytes.
          memory: 90
​
    # Storage parameters to set for the in-cluster builder, container registry and code sync persistent volumes
    # (which are automatically installed and used when `buildMode` is `cluster-docker` or `kaniko`).
    #
    # These are all shared cluster-wide across all users and builds, so they should be resourced accordingly,
    # factoring in how many concurrent builds you expect and how large your images and build contexts tend to be.
    storage:
      # Storage parameters for the data volume for the in-cluster Docker Daemon.
      #
      # Only applies when `buildMode` is set to `cluster-docker`, ignored otherwise.
      builder:
        # Volume size in megabytes.
        size: 20480
​
        # Storage class to use for the volume.
        storageClass: null
​
      # Storage parameters for the NFS provisioner, which we automatically create for the sync volume, _unless_
      # you specify a `storageClass` for the sync volume. See the below `sync` parameter for more.
      #
      # Only applies when `buildMode` is set to `cluster-docker` or `kaniko`, ignored otherwise.
      nfs:
        # Storage class to use as backing storage for NFS .
        storageClass: null
​
      # Storage parameters for the in-cluster Docker registry volume. Built images are stored here, so that they
      # are available to all the nodes in your cluster.
      #
      # Only applies when `buildMode` is set to `cluster-docker` or `kaniko`, ignored otherwise.
      registry:
        # Volume size in megabytes.
        size: 20480
​
        # Storage class to use for the volume.
        storageClass: null
​
      # Storage parameters for the code sync volume, which build contexts are synced to ahead of running
      # in-cluster builds.
      #
      # Important: The storage class configured here has to support _ReadWriteMany_ access.
      # If you don't specify a storage class, Garden creates an NFS provisioner and provisions an
      # NFS volume for the sync data volume.
      #
      # Only applies when `buildMode` is set to `cluster-docker` or `kaniko`, ignored otherwise.
      sync:
        # Volume size in megabytes.
        size: 10240
​
        # Storage class to use for the volume.
        storageClass: null
​
    # One or more certificates to use for ingress.
    tlsCertificates:
      - # A unique identifier for this certificate.
        name:
​
        # A list of hostnames that this certificate should be used for. If you don't specify these, they will be
        # automatically read from the certificate.
        hostnames:
​
        # A reference to the Kubernetes secret that contains the TLS certificate and key for the domain.
        secretRef:
          # The name of the Kubernetes secret.
          name:
​
          # The namespace where the secret is stored. If necessary, the secret may be copied to the appropriate
          # namespace before use.
          namespace: default
​
        # Set to `cert-manager` to configure [cert-manager](https://github.com/jetstack/cert-manager) to manage this
        # certificate. See our
        # [cert-manager integration guide](https://docs.garden.io/advanced/cert-manager-integration) for details.
        managedBy:
​
    # cert-manager configuration, for creating and managing TLS certificates. See the
    # [cert-manager guide](https://docs.garden.io/advanced/cert-manager-integration) for details.
    certManager:
      # Automatically install `cert-manager` on initialization. See the
      # [cert-manager integration guide](https://docs.garden.io/advanced/cert-manager-integration) for details.
      install: false
​
      # The email to use when requesting Let's Encrypt certificates.
      email:
​
      # The type of issuer for the certificate (only ACME is supported for now).
      issuer: acme
​
      # Specify which ACME server to request certificates from. Currently Let's Encrypt staging and prod servers are
      # supported.
      acmeServer: letsencrypt-staging
​
      # The type of ACME challenge used to validate hostnames and generate the certificates (only HTTP-01 is supported
      # for now).
      acmeChallengeType: HTTP-01
​
    # Exposes the `nodeSelector` field on the PodSpec of system services. This allows you to constrain the system
    # services to only run on particular nodes.
    #
    # [See here](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) for the official Kubernetes guide
    # to assigning Pods to nodes.
    systemNodeSelector: {}
​
    # For setting tolerations on the registry-proxy when using in-cluster building.
    # The registry-proxy is a DaemonSet that proxies connections to the docker registry service on each node.
    #
    # Use this only if you're doing in-cluster building and the nodes in your cluster
    # have [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).
    registryProxyTolerations:
      - # "Effect" indicates the taint effect to match. Empty means match all taint effects. When specified,
        # allowed values are "NoSchedule", "PreferNoSchedule" and "NoExecute".
        effect:
​
        # "Key" is the taint key that the toleration applies to. Empty means match all taint keys.
        # If the key is empty, operator must be "Exists"; this combination means to match all values and all keys.
        key:
​
        # "Operator" represents a key's relationship to the value. Valid operators are "Exists" and "Equal". Defaults
        # to
        # "Equal". "Exists" is equivalent to wildcard for value, so that a pod can tolerate all taints of a
        # particular category.
        operator: Equal
​
        # "TolerationSeconds" represents the period of time the toleration (which must be of effect "NoExecute",
        # otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate
        # the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately)
        # by the system.
        tolerationSeconds:
​
        # "Value" is the taint value the toleration matches to. If the operator is "Exists", the value should be
        # empty,
        # otherwise just a regular string.
        value:
​
    # The name of the provider plugin to use.
    name: kubernetes
​
    # The kubectl context to use to connect to the Kubernetes cluster.
    context:
​
    # The registry where built containers should be pushed to, and then pulled to the cluster when deploying services.
    #
    # Important: If you specify this in combination with in-cluster building, you must make sure `imagePullSecrets`
    # includes authentication with the specified deployment registry, that has the appropriate write privileges
    # (usually full write access to the configured `deploymentRegistry.namespace`).
    deploymentRegistry:
      # The hostname (and optionally port, if not the default port) of the registry.
      hostname:
​
      # The port where the registry listens on, if not the default.
      port:
​
      # The namespace in the registry where images should be pushed.
      namespace: _
​
    # The ingress class to use on configured Ingresses (via the `kubernetes.io/ingress.class` annotation)
    # when deploying `container` services. Use this if you have multiple ingress controllers in your cluster.
    ingressClass:
​
    # The external HTTP port of the cluster's ingress controller.
    ingressHttpPort: 80
​
    # The external HTTPS port of the cluster's ingress controller.
    ingressHttpsPort: 443
​
    # Path to kubeconfig file to use instead of the system default. Must be a POSIX-style path.
    kubeconfig:
​
    # Specify which namespace to deploy services to, and optionally annotations/labels to apply to the namespace.
    #
    # You can specify a string as a shorthand for `name: <name>`. Defaults to `<project name>-<environment
    # namespace>`.
    #
    # Note that the framework may generate other namespaces as well with this name as a prefix. Also note that if the
    # namespace previously exists, Garden will attempt to add the specified labels and annotations. If the user does
    # not have permissions to do so, a warning is shown.
    namespace:
      # A valid Kubernetes namespace name. Must be a valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters,
      # numbers and dashes, must start with a letter, and cannot end with a dash) and must not be longer than 63
      # characters.
      name:
​
      # Map of annotations to apply to the namespace when creating it.
      annotations:
​
      # Map of labels to apply to the namespace when creating it.
      labels:
​
    # Set this to `nginx` to install/enable the NGINX ingress controller.
    setupIngressController: false

providers:
  - dependencies:
      - exec

providers:
  - environments:
      - dev
      - stage

providers:
  - clusterBuildkit:
      ...
      nodeSelector:
          disktype: ssd

providers:
  - defaultHostname: "api.mydomain.com"

providers:
  - imagePullSecrets:
      - name: "my-secret"

providers:
  - resources:
      ...
      builder:
        ...
        limits:
          ...
          cpu: 4000

providers:
  - resources:
      ...
      builder:
        ...
        limits:
          ...
          memory: 8192

providers:
  - resources:
      ...
      builder:
        ...
        requests:
          ...
          cpu: 100

providers:
  - resources:
      ...
      builder:
        ...
        requests:
          ...
          memory: 512

providers:
  - resources:
      ...
      registry:
        ...
        limits:
          ...
          cpu: 2000

providers:
  - resources:
      ...
      registry:
        ...
        limits:
          ...
          memory: 4096

providers:
  - resources:
      ...
      registry:
        ...
        requests:
          ...
          cpu: 200

providers:
  - resources:
      ...
      registry:
        ...
        requests:
          ...
          memory: 512

providers:
  - resources:
      ...
      sync:
        ...
        limits:
          ...
          cpu: 500

providers:
  - resources:
      ...
      sync:
        ...
        limits:
          ...
          memory: 512

providers:
  - resources:
      ...
      sync:
        ...
        requests:
          ...
          cpu: 100

providers:
  - resources:
      ...
      sync:
        ...
        requests:
          ...
          memory: 90