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 . 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

Creating an environment for Google BigQuery? Read Google BigQuery environments.
  1. In your project, click the Environments tab. This tab lists all environments currently created.
  2. Click Add environment.
s can be restricted to specific projects and environments. If a is not allowed for your project or environment, it will not appear in the Runner drop-down. For more information, read Restricting s.
Click Continue. Depending on the data platform that you selected when creating your project, follow the corresponding instructions below to specify your cloud data warehouse credentials and select your data warehouse defaults for this environment.

​
Snowflake

​
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.

​
Specify credentials

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 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 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 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.

​
Databricks

​
Specify credentials

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.

​
Select defaults

​
Amazon Redshift

​
Specify credentials

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.
Ensure the IAM user has appropriate permissions to read from and write to the specified S3 bucket. At a minimum, the user should have:
  • s3:GetObject
  • s3:PutObject
  • s3:ListBucket
Next, in the Specify AWS cloud credentials dialog, in the drop-down, select one of the following options:
  • Use the cloud credentials assigned to the you specified when creating this environment.
  • Enter different cloud credentials. This will override the IAM role belonging to the you specified.
If you choose to enter different cloud credentials, use the fields to enter the cloud credential name, access key ID, and secret access key. For details about access keys, read the AWS documentation.

​
Select defaults

If you use a Matillion Full SaaS solution, the cloud credentials associated with your environment will be used to access the S3 bucket.If you use a Hybrid SaaS solution, your new environment will inherit the Maia runner’s execution role (service account role) to access the default S3 bucket specified here.To overwrite this role, associate different cloud credentials with this environment after you have finished creating it. You can create these credentials before or after creating the environment.

​
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 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.

​
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 , 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.

​
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.