Automatic Environment Cleanup

With automatic environment cleanup, you can configure Garden Cloud to automatically delete Kubernetes Namespace resources deployed with Garden:

• When the namespace hasn't been used by a Garden command for longer than a specified number of hours; or

• At a specified time of day (or at a specified time on a given weekday). This cleanup can optionally be enabled on a per-environment basis, and the cleanup schedule for each environment can be set independently.

Automatic environment cleanup can greatly save on infrastructure costs by making sure that namespaces (and their associated resources) aren't kept around longer than needed.

Configuring a cleanup run

Visit the project settings tab of your project to configure automatic environment cleanup for that project's environments:

Project Settings

Click the settings icon for any of your environments to configure automatic environment cleanup:

Automatic Environment Cleanup Settings

Choosing a Cleanup mode

You can either configure Garden to delete or to scale down the namespace resources.

Delete namespaces

All the resources deployed in the namespace set to be cleaned up are going to be deleted, including the Namespace itself. This is the default option.

Scale down namespaces

If selected, all Deployments and StatefulSets deployed in the namespace will be scaled down by setting their respective replicas to 0. All other resources are preserved.

Note: in order to successfully redeploy a namespace that has been scaled down by Garden Cloud you will need Garden Core >=0.12.35.

Setting up an authentication script

The authentication script is a shell script that's run before cleanup to enable Garden Cloud to delete namespaces. This is done in an ephemeral pod that's terminated after the requested namespaces have been deleted.

After the script is run, the pod should be able to use kubectl to delete the requested namespaces. Usually, this means providing credentials to a CLI tool, but the specific approach varies by cloud provider and the specifics of your setup.

You can use project- and environment-scoped secrets in the init script, using Garden-style template-syntax (see the example in the screenshot above)

In general, the same approach used for workflow runner pods works for the authentication script.

If you need help getting this set up, plese contact Garden support—we'd be happy to assist.

How are hours of inactivity calculated?

When a logged-in Garden CLI command builds, deploys or runs tests or tasks in a given namespace, the events streamed to Garden Cloud are used to update the "last used" timestamp of that namespace in Garden Cloud.

For environments configured for cleanup after a certain number of hours of inactivity, the automatic cleanup logic periodically checks for namespaces that haven't been used by logged-in Garden commands for longer than the specified duration, and deletes any matching namespaces in that environment.