Manage secret groups

You can set the type for a secret group as either secret values or configuration values. This is useful when working with colleagues if you need to control access to certain secrets, but allow team members to view or edit other values inherited by services and jobs.

RBAC permissions can be configured separately for the two types of secret group. This allows you to, for example, create a role that has full access to configuration groups, but access only to secret group keys and not their values.

The group type can be edited from the group settings page of a secret group.

You can create a group of either runtime variables, build arguments, or both.

The scope will define when your secrets are inherited by services and jobs: at build time, runtime, or both. The group scope can be edited from the group settings page of a secret group.

Use Group settings to restrict a secret group to services, jobs, tags, or environments within the project.

The group scope controls whether workloads receive build arguments, runtime variables, or both.

Restrict by tag

You can grant access to resources with selected tags. By default, a resource needs any selected tag. Enable Force matching all tags to require every selected tag.

This control applies only to tag matching. Explicitly selected resources and resources in selected environments receive the values independently.

Restrict by environment

Select existing environments in the same project, such as staging or production.

1. Open the secret group's Group settings page.
2. Enable Restrict secret group.
3. Select environments under Apply secrets to specific environments.
4. Select Update settings.

For example, selecting staging and the api tag grants access to staging workloads and production workloads tagged api.

Deleting a selected environment removes it from the restrictions. Other matching criteria still grant access.

Saving the group configuration does not restart workloads. Restart services or start new job runs to apply updated runtime variables.

The priority of a secret group determines the value of which group is used if multiple secrets contain the same key. The group priority can be edited from the group settings page of a secret group.

You can set the priority of a group as any integer between 0 and 100. The secret group with a higher priority will take precedence.

For example if the priority for Group A is 50 and the priority of Group B is 20, the values of Group A will be used for any conflicting keys between the groups:

Build arguments and environment variables set directly in a service or job will always override variables with the same name inherited from secret groups.

You can use dynamic templating to create new variables from variables previously defined in the secret group.