Variables and Secrets

Build and Runtime Variables can be defined either inline within a Blueprint Manifest (blueprint.yaml), or on the Application and Environment settings pages within the Noop Console. Build and Runtime Variables can also be defined as Secrets. Secrets provide a secure mechanism for supplying sensitive data to a component at build and runtime with mitigated risk of public exposure.

Variables

When a variable does not need to be secret, it can be defined directly within a Blueprint Manifest. Providing a static value for a variable within a Blueprint Manifest offers a convenient mechanism for instantiating default values for a given variable. If desired, default static variables defined within a Blueprint Manifest can be overridden in the Noop Console at a later time.

Build Variables

Build Variables are expressed as an object of key-value pairs under the variables key within a Component’s Build Manifest. Here is an example of a Build Variable, NODE_ENV, being assigned for a component’s build process:

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    build:
      steps:
        - copy: [package.json, package-lock.json]
        - run: npm install
      variables:
        NODE_ENV: production

Build Variables are only assigned as environment variables during the run build steps of a given component, and will be unassigned at the component’s runtime. In the Console, Build Variables can be defined within the Variables section on the Application settings page.

Runtime Variables

Runtime Variables are expressed as an object of key-value pairs under the variables key within a Component’s Runtime Manifest. Here is an example of a Runtime Variable, LOG_LEVEL, being assigned for the component’s runtime:

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      command: npm start
      variables:
        LOG_LEVEL: info

Runtime Variables only exist as environment variables during the runtime of a given component. In the Console, Runtime Variables can be defined within the Variables section on the Environment settings page.

Logic-based Variables

When a Build or Runtime Variable needs to change based on dynamic details, you can define it within a Blueprint Manifest using Noop Logic. Here is an example where a Runtime Variable, LOG_LEVEL, will be conditionally assigned with Noop Logic based on the production state of the environment the component is being deployed to:

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      command: npm start
      variables:
        LOG_LEVEL:
          $env:
            if:
              - var: production
              - warn
              - info

Noop Logic can also be used to dynamically resolve Resource properties as Runtime Variables. Using Resource properties is useful when you need to connect a Service or Task Component to a Resource. Here is an example of a Service that uses a Redis Resource and surfaces the URL as a Variable in the Service runtime:

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      resources:
        - ExampleCache
      variables:
        dbUrl:
          $resources: ExampleCache.url
resources:
  - name: ExampleCache
    type: redis

During build time, the Logic scopes $org, $app, $build, $source, and $execution are available for reference when resolving Build Variables. During runtime, the Logic scopes $org, $app, $env, $build, $source, $resources, and $stack are available for reference when resolving Runtime Variables.

Console-defined Variables

Build and Runtime Variables can also be defined within the Noop Console on the Application and Environment settings pages.

The Variable’s name, value, and component are specified using the form. The form can also be used to express a Variable as a Secret (see below).

Secrets

Secrets are a special type of Variable, the contents of which are stored in an encrypted state. For build time, Secrets are decrypted when provided to authorized Components during their run build steps. For runtime, Secrets are decrypted when provided to authorized Components at runtime. Both Build and Runtime Secrets can also be decrypted on-demand by authorized users on the Application and Environment settings pages in the Noop Console.

Noop protects Build and Runtime Secrets from exposure in the Console by masking their decrypted values within Build and Environment logstreams. If a decrypted Secret is logged within a Build or Environment logstream, its value will show as ***SECRET***.

To create a Secret, go to the Application or Environment settings page and select the Variables section. Fill out the form as you would for a Variable and click on the 🔒 button to the right of the “Select Component” field. Toggling the 🔒 button to a locked state indicates to Noop that the Variable should be created as a Secret.