Managing Variables

In line with the best practices laid out for Twelve-Factor Applications, workflows on the CTO.ai platform offer multiple methods to make your application’s configuration available in its execution environment. These include the ability to define static environment variables on a per-workflow basis, as well as two centralized data stores (a Secrets Store for sensitive details and a Configs Store for non-sensitive configuration information) for use across your Team’s workflows.

Setting constants directly in your codebase can introduce operational difficulties down the road, especially when multiple workflows need to have consistent configurations. Configs Stores (and static environment variables, in some cases) are an optimal place to manage configuration details:

Centrally store the hostnames, identifiers, and (non-sensitive) database connection details that define a workflow’s runtime environment.
Ensure identifiers and (non-sensitive) configuration options for your backend services and applications are consistent across workflows owned by your Team.
Record persistent infrastructure configuration details, such as the deployment region, the deployment environment’s default resource configuration, or the identifiers of the base images used to construct your workflow containers.

Additionally, Secrets Stores are an ideal tool for managing sensitive configuration details that should be kept private and secure, such as API tokens, database authentication credentials, and private keys.

Managing Workflow Behavior with Environment Variables

The simplest way to pass application configuration to your workflow’s runtime environment is through static environment variables, defined under the env key of a workflow within an ops.yml config file. The static key within the env mapping accepts an array of strings defining environment variables in KEY=val format. For example, the ops.yml excerpt below shows how the environment variable DOCKER_REGISTRY can be set to the value ghcr.io in a Pipeline workflow’s execution environment:

# Content in the `ops.yml` not relevant to this example has been omitted
pipelines:
	- name: example-pipeline:0.1.0
  	#
  	# Other fields, including a required field, have been omitted from this excerpt
    #
    env:
    	static:
      	- DOCKER_REGISTRY=ghcr.io

Of course, static env variables must be set on a per-workflow basis, and if the value of the variable must be changed in multiple workflows, you’d have to manually change the value in the ops.yml file of each workflow.

Managing Workflow Behavior with Configs and Secrets

To make it easier for you to manage your application configurations, we offer Configs and Secrets Stores, where you can centrally set these values for all workflows published to your CTO.ai team. You can specify values for the Configs and Secrets associated with your CTO.ai Team through our CLI or Dashboard:

Before a workflow can use a value from either your Secrets Store or Configs Store, you’ll need to make that value accessible as an environment variable by specifying its key in the secrets or configs array under the workflow’s env mapping. Because the values for Configs and Secrets are centrally defined—unlike static environment variables—you only need to specify their keys in your ops.yml to make them available as environment variables in the workflow’s runtime environment:

# Content in the `ops.yml` not relevant to this example has been omitted
pipelines:
	- name: example-pipeline:0.1.0
  	#
  	# Other fields, including a required field, have been omitted from this excerpt
    #
    env:
      configs:
      	- BASE_API_URL
      secrets:
      	- GITHUB_TOKEN

Configs & Secrets Stores