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.

Enable for Garden Enterprise

The following section only applies to Garden Enterprise.
To enable automatic environment cleanup for your Garden Enterprise instance, you need to tick the checkbox enabling automatic environment cleanup it in your Replicated console.
You will also need to provide a randomly generated In-Cluster Auth Token which will be used to authenticate a cleanup Kubernetes CronJob against the API service. See screenshot below:
Automatic Environment Cleanup Features Config
Once you've saved your changes, you'll need to re-deploy Garden Enterprise.

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

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.
Last modified 3mo ago