Skip to main content

Configuration

Component configuration in CodeNOW defines how the component is set up at runtime. All configuration defined at the component level — whether in its repository or in the component settings — represents default values only. These defaults are used as a baseline and can be overridden in the Deployment Configuration for a specific target environment. If no override is defined for a given environment, the component's defaults apply.

CodeNOW stores this default configuration together with each released version of the component. This ensures that if no deployment configuration is available for a target environment, the configuration corresponding to the specific component version being deployed is used — keeping the default configuration consistent with the component version.

warning

CodeNOW strongly recommends not storing any sensitive information (passwords, tokens, connection strings, etc.) directly in the component's Git repository. The repository should only define the configuration structure — keys with placeholder or non-sensitive default values. Actual sensitive values should be provided in the Deployment Configuration for each target environment.

CodeNOW distinguishes four types of configuration:

Configuration Files​

Files injected directly into the runtime container at deployment. These typically contain framework-specific settings (e.g. application.yaml, application.properties) and are sourced from the codenow/config/ directory in the component's repository.

In the default CodeNOW scaffolders, the files from codenow/config/ are configured to be injected into the same path (codenow/config/) inside the runtime container.

warning

Relying on full configuration files as the primary configuration mechanism is not recommended. When entire files are overridden per environment, it significantly increases configuration management complexity — every change to the file must be tracked and replicated across all target environment overrides. Prefer environment variables for environment-specific values wherever possible.

Framework-specific configuration files (e.g. application.yaml, application.properties) should be built into the component together with proper environment variable handling — so that the component reads its settings from environment variables, which can then be cleanly managed through the environment-variables configuration file.

Environment Variables​

Environment variables made available to the component at runtime. CodeNOW supports two sources:

  • Configuration file — variables defined in a file named environment-variables stored in the codenow/config/ directory. The file uses a simple key-value format:

    ENV_VAR1=value1
    ENV_VAR2=value2

    Unlike configuration files, this file is not injected into the container as a file — instead, its contents are transformed into environment variables of the runtime container.

    note

    CodeNOW supports one level of variable referencing. A variable can reference any other environment variable available at runtime using the ${VAR_NAME} syntax — including variables defined in the same file or injected from connected services (Managed Services or External Service Templates):

    ENV1=value
    ENV2=${ENV1}
    ENV3=${SOME_SERVICE_CONNECTION_STRING}

  • Connected Services — variables injected automatically from Managed Services or External Service Templates connected to the component

Helm Templating​

Helm values stored in a file named helm-values.yaml in the codenow/config/ directory. During deployment, these values are applied in the Helm templating phase and override all previously set keys — giving the highest priority among all Helm value sources.

note

Helm templating configuration is only meaningful in combination with advanced mode, where the user has customized the Helm deployment descriptor (helm/ directory) and needs a way to parameterize it. In standard mode, where CodeNOW manages the deployment descriptor automatically, there is typically no reason to use this file. Advanced mode is enabled in CI Configuration.

Runtime Configuration​

Defines the compute resources and scaling parameters for the component — the number of running instances and CPU/memory request and limit values. Configured directly in the Component Detail.