Environment Groups

An environment group (or env group for short) is a set of environment variables that are meant to be reused across multiple applications. For example, if all web services require a shared set of API and database keys, this could form a web-service environment group with all of those keys as a shared configuration. In this guide, we will explain how to create and use environment groups.

​

Creating and Using Environment Groups

You can create a new environment group in the “Env Groups” tab on the dashboard. Click on “Create Env Group” from this tab:

From this screen, you can name your env group and add your environment variables. In this example, we will simply create an environment group named web that will be shared across all web services that we create. When you’re finished, press “Create env group”.

You will be redirected to the list of environment groups, and your new environment group should be listed. At this point, you can use this environment group in a deployment. From the “Launch” tab, you can select “Load from Env Group” in the “Environment” tab:

You can then select your environment group and click “Load Selected Env Group”, which will automatically populate the environment group variables that you previously set. You can modify these environment variables in this tab, for example if you’d like to add environment variables that aren’t currently in the environment group. To view all deployment options, head over to our application deployment docs.

​

🔒 Creating Secret Environment Variables

Porter supports creating secret environment variables that will not be exposed after creation. At the moment, you must create an environment group in order to create secret environment variables. To create a secret environment variable, click on the lock icon next to the environment variable during creation of the environment variable:

When you launch a new service, and you select “Load from Env Group” in the “Environment” tab, this sensitive value will be injected into the container before it is mounted:

​

Syncing Environment Groups to Applications

Environment groups have the capability to sync with applications, so when the environment variables are updated the synced applications are automatically restarted. To enable environment group syncing, click on Sync env group when loading the environment variables from the group:

When you subsequently update those env group variables from the Env groups tab, the applications will be restarted with the new variables.

​

Updating and Deleting Environment Groups

To update or delete your environment group, navigate back to the “Env Groups” tab, and click on the existing environment group to update or delete. You can make changes to the env group here, and select the “Update” button when finished:

To delete the environment group, navigate to the “Settings” tab, and press the “Delete” button:

​

How Secrets are Stored

All env group variables are stored in your own cluster, and not on Porter’s infrastructure. The entire env group is stored as a Kubernetes Config Map, which is meant for non-sensitive, unstructured data. When you create a secret environment variable, the ConfigMap will contain a reference to a Kubernetes Secret, which contains the secret data. This secret will be injected into your container as it is mounted, and will not be exposed on the Porter dashboard after creation. To summarize:

• No env group data is stored on Porter’s servers: it is all stored on your own cluster.
• Non-sensitive data in an env group will be read into memory on Porter’s servers during deployment, and added directly to the deployment.
• Sensitive data in an env group will not be read into memory on Porter’s servers during deployment, and are referenced as a secret during deployment. This sensitive data only exists in memory on Porter’s infrastructure during creation/updating of the env group (not the deployment).

​

Encryption

There is no further encryption beyond what is offered by the managed Kubernetes providers. Some providers will encrypt all secret data in the control plane at rest (in etcd), others will store it as base64-encoded data. While you don’t have access to this control plane or the etcd instance, users with access to your cluster could view the secrets using kubectl get secrets -o yaml, for example.