Skip to main content

Environment Configuration

Overview​

Taqueria Environments provide a powerful and flexible way to develop Tezos projects in multiple contexts. These environments can be used throughout the life cycle of a project from development to production.

note

To target an environment for a stateful task such as taq originate, add the --env flag with the name of the environment you would like to target. For example, to target an environment named kathmandu_env for an origination, you would use the following command:

taq originate --env kathmandu_env

Example Environments​

Environments are declared in .taq/config.json

    "environmentDefault": "development",
    "environments": {
        "development": {
            "type": "flextesa",
            "label": "Local Tezos Sandbox"
        },
        "testing": {
            "type": "simple",
            "label": "ghostnet",
            "rpcUrl": "https://ghostnet.ecadinfra.com"
        },
        "production": {
            "type": "simple",
            "label": "mainnet",
            "rpcUrl": "https://mainnet.api.tez.ie"
        }
    }

The above example shows 3 environments: development, testing, and production.

Each environment has a type. The development environment is flextesa which uses the flextesa plugin for a local sandbox. The testing and production environments are both the simple type which use only the rpcUrl.

Other environment types can be created with a plugin and it can define additional environment fields as needed.

The Default Environment​

In the above example, the default environment is development. For most taq commands the default environment will be used unless the --env flag is provided.

Local Config​

Each environment also has a config.local... file.

Going back to the example config.json above, it has three environments. So, each would have their own config.local... file:

  • config.local.development.json
  • config.local.testing.json
  • config.local.production.json

These local config files are intended to store custom settings that are specific to a single developer's context.

For example, when deploying a contract to a sandbox or a test environment, the config.local... file could contain the address of a contract deployed by a developer. Since each developer working on the same project would each have their own config.local... file for each environment, they will have an isolated context when working.

The config.local... files should be excluded from git commits, and are listed in the .gitignore by default.

On the other hand, the main config.json contains settings that belong to the project itself and should be shared by all developers working on that project since those settings are common.

Deploying and Transferring with Mainnet​

danger

Improvements are on the way. However, we currently only support signing in memory and we require a mnemonic to be written in the config file, so do not commit this file or delete the mnemonic before doing so. This is not the safest way to interact with mainnet so proceed with caution

Add the accounts field to the config.local.production.json file. For example:

{
    "networkName": "mainnet",
    "accounts": {
        "tempUser": {
            "mnemonic": <12-24 words mnemonic generated via a wallet>
        }
    }
}

To interact with mainnet using tempUser, users must include the --env and the --sender flags. E.g. taq deploy counter --env production --sender tempUser