Skip to main content
An environment defines the connection between a project and your chosen cloud data warehouse. Environments include useful defaults—such as a default warehouse, database, and schema—that can be used to pre-populate component configurations in Designer. Haven’t added a project yet? Read Add project.
We recommend using environments to separate your development and production environments:
  • Use development environments for building, testing, and iterating on pipelines before they are deployed.
  • Use production environments to run pipelines that are fully deployed to work on live data. Only stable and thoroughly tested pipelines should be deployed here.
  • You can also use intermediate environments, such as staging, test, or preprod, to validate pipelines before they are deployed to production. These can also be used for performance testing.
For more information, read our Unlocking Data Productivity DataOps guide.

​
Add an environment

  1. In your project, click the Environments tab. This tab lists all environments currently created.
  2. Click Add environment.

​
Warehouse-specific setup

The steps to create your environment, specify your cloud data warehouse credentials, and select your data warehouse defaults depend on the data platform you chose when creating your project.

​
Prerequisites

Before configuring a Snowflake connection, you will need:For details about Snowflake key-pair authentication, read the Snowflake guide to Configuring key-pair authentication.

​
Create an environment

  1. Create an environment by providing the following information:
    Maia runners can be restricted to specific projects and environments. If a Maia runner is not allowed for your project or environment, it will not appear in the Runner drop-down. For more information, read Restricting Maia runners.
  2. Click Continue.

​
Select authentication method

Use the reference tables below to set up your environment connection to your cloud data platform. If you’re using a Full SaaS deployment, credentials such as passwords and private keys are stored directly as strings. However, if you’re using a Hybrid SaaS deployment with your own Maia runner via AWS or Azure, credentials such as passwords and private keys are only retrieved via references to secrets created in either AWS Secrets Manager or Azure Key Vault.

​
Key-pair

We recommend using key-pair authentication to set up your connection to Snowflake, because Snowflake has announced plans to block single-factor password authentication by November 2025. For more information, read our Tech note.Refer to this table if you’re using Snowflake key-pair authentication.
If you’re using a Matillion Maia runner for Snowflake, create the environment before creating the secrets that hold your private key and passphrase. The Private key secret name and Passphrase secret name drop-downs only list secrets that already exist for this environment, so they show no results if you try to create the secrets first. Create the environment, then read Secrets in Matillion Maia runner for Snowflake to add the secrets, and edit the environment afterward to select them.
If your private key has been shared, the format may have been altered. To correct this, run the following command to validate and convert the key to the correct format:

​
Password

Refer to this table if you’re using your Snowflake password to authenticate to Snowflake.

​
Programmatic access token

An alternative authentication option is to use a Snowflake programmatic access token (PAT). To use this option, follow the instructions for Password authentication, above, using your PAT as the password. For more details of this authentication option, read Snowflake programmatic access token authentication.

​
Select Snowflake defaults

​
Default session parameters

You can set session parameters to change the behavior of the Snowflake connection. An example of this would be setting the QUOTED_IDENTIFIERS_IGNORE_CASE parameter to determine whether the case of letters in double-quoted object identifiers is preserved.Setting default session parameters when you create an environment is optional, and should only be done if you need to change the default behavior of the Snowflake connection.To set default session parameters for the environment:
  1. In the Default session parameters field, click the cog icon to open the Configure Session Parameters dialog.
  2. Enter a name and value for each required parameter.
  3. Click Save to close the dialog.
For a description of the available session parameters, read the Snowflake documentation. Note that for security reasons we don’t allow all parameters on that page to be set, only the session-level parameters.

​
Associate cloud provider credentials with an environment

Each environment in your project should have at least one set of cloud credentials associated with it. This allows you to access account resources on different platforms other than that hosting your project. For example, if your project is on AWS and you want to access resources in Azure, you need to associate your Azure cloud credentials with the environment. Credentials are configured at the project level and apply to selected environments within the project. They can then be used by any pipelines that use those environments. To create and associate cloud credentials, read Cloud provider credentials. To associate cloud credentials with an environment:
  1. Click the three dots … in the row of the environment you want to update.
  2. Click Associate credentials.
  3. In the Associate cloud credentials dialog, select credentials from the Azure credentials, AWS credentials, or GCP credentials drop-downs as required.
  4. Click Associate.

​
Edit or remove an associated credential

Edit or remove which credential is in use by your environment:
  • Hybrid SaaS: Removing the credential causes the environment to fall back to runner-assigned credentials.
  • Full SaaS: Removing the credential leaves the environment unusable, because Full SaaS environments require an explicitly associated credential.

​
Manage environments

To view your environments:
  1. From the Your projects menu, select your project.
  2. Navigate to the Environments tab.
Use the Search field to filter environments by name. Click the column headers to sort your environments by name, default Maia runner, cloud data warehouse account name, or credential type. To navigate between pages of results, use the Previous and Next buttons or select a page number.

​
View environment defaults

To view the default settings configured for an environment:
  1. Click the three dots … in the row of the environment.
  2. Click View environment defaults.
The dialog displays the default role, warehouse, database, and schema configured for the environment.

​
Edit an environment

  1. Click the three dots … in the row of the environment you want to edit.
  2. Click Edit environment.
  3. On the second screen, use the Allow inherit project defaults toggle to manage how the environment handles variable values. By default, this setting is enabled, and the environment will inherit the project-level default values.
If you disable this toggle, the environment will not inherit project-level defaults. You must manually provide a default value for each variable within the environment to ensure pipelines function successfully across different environments.
For Google BigQuery environments, the edit screen is labeled Edit Google BigQuery credentials and additionally lets you select a different Runner. The Allow inherit project defaults toggle appears after clicking Continue, on the BigQuery defaults screen; click Update to save your changes.

​
Edit user access

You must have the Owner project role to edit user access for an environment. For more information, read Project roles.
To manage which users can access an environment and at what role:
  1. Click the three dots … in the row of the environment you want to update.
  2. Click Edit user access.
  3. Use the Search field to find a specific user by name or email address.
  4. For each user, select an access level from the Access drop-down.
  5. Click Save.
For more information about environment roles and access levels, read Environment roles.

​
Edit API access

You must have the Super Admin account role to manage API credentials. For more information, read Account roles.
To manage which API credentials can access an environment:
  1. Click the three dots … in the row of the environment you want to update.
  2. Click Edit API access.
  3. Use the Search field to find a specific API credential by name or client ID.
  4. For each API credential, select an access level from the Access drop-down.
  5. Click Save.
For more information about creating and managing API credentials, read API credentials.

​
Delete an environment

Deleting an environment permanently removes the environment from your project. All artifacts and schedules in the deleted environment will be inaccessible. This action cannot be undone.
Before you delete an environment, you must:
  • Disable any active schedules that run pipelines in this environment.
  • Change the default environment of any branches that currently use this environment as their default. For more information, read Branches.
To delete an environment:
  1. Click the three dots … in the row of the environment you want to delete.
  2. Click Delete environment.
  3. In the confirmation dialog, enter the name of the environment you want to delete.
  4. Click Delete environment.