Component Anatomy

Every deployable service in the platform is defined as a component. A component is a directory containing a TOML configuration file and one or more templates. The CLI reads these definitions, resolves variables, renders templates, and produces the manifests that ArgoCD deploys.

Directory structure

Components live under src/manifests/source/<group>/<component>/:

src/manifests/source/
├── common/
│   ├── keycloak/
│   │   ├── variables.toml
│   │   ├── values.yaml.j2
│   │   └── extra/
│   │       ├── gateway-httproute.yaml.j2
│   │       └── db-credentials.yaml.j2
│   ├── grafana/
│   │   ├── variables.toml
│   │   └── values.yaml.j2
│   └── ...
├── coreai/
│   └── ...
└── proai/
    └── ...

The three groups (common, coreai, proai) map directly to ArgoCD parent applications and sync wave tiers.

Component formats

The format field in variables.toml determines what the CLI expects:

The component table

Every variables.toml has a required [component] table:

[component]
name          = "keycloak"
namespace     = "keycloak"
version       = "26.5.2"

format        = "helm"
chart_name    = "keycloak"
chart_version = "18.10.0"
release_name  = "keycloak"

url_prefix    = "iam"

parent_app       = "common"
sync_wave        = "7"
sync_options     = "- SkipDryRunOnMissingResource=true"
sync_annotations = ""

Extra tables

Tables beyond [component] are optional and component-specific. Not every component has all of these — each component defines only the tables it needs. The following are common examples.

Database configuration (optional)

[database]
postgresql_name     = "keycloak"
postgresql_owner    = "keycloak"
postgresql_password = {value = "", secret = true}

These variables are available in templates following the naming pattern:

<component_name>_<table>_<variable>

For example, the [database] table above produces keycloak_database_postgresql_name, keycloak_database_postgresql_owner, etc.

The [component] table is the exception — it omits the table segment: keycloak_namespace, keycloak_chart_version.

SSO configuration (optional)

Keycloak is the SSO provider, so it does not have an [sso] table itself. The following example is from the Grafana component, which enrolls as an SSO consumer:

[sso]
enabled       = true
client_id     = "grafana"
client_secret = {value = "", secret = true}
description   = "Grafana OAuth client"

default_scope                = ["openid", "profile", "email"]
standard_flow_enabled        = true
redirect_uris                = ["*"]
groups                       = [{name = "Grafana-Viewer"}]

When [sso] enabled = true, the CLI generates Keycloak enrollment resources from shared templates: an SSO config secret, a registration job (deployed at a negative sync wave to run before the component), and a PostDelete cleanup job. See Configuration model — SSO scope for details.

Resource sizing (optional)

The Keycloak component defines its own sizing through a [server] table:

[server]
cpu_request    = "1"
memory_request = "4Gi"
cpu_limit      = "2"
memory_limit   = "8Gi"

When a component does not define its own sizing, the [default] section in platform.toml provides fallback values.

Template rendering

The CLI uses Jinja2 to render templates. All resolved variables from platform.toml and every component's variables.toml are available in the template context as a flat dictionary.

Variable naming in templates

Both global and component variables follow the same <table>_<variable> pattern. Global variables from platform.toml use the section name as prefix, without a component name:

common_base_domain                    # [common] base_domain
common_registry_name                  # [common] registry_name
git_repo_url                          # [git] repo_url
git_branch                            # [git] branch

Component variables add the component name: <component_name>_<table>_<variable>. The [component] table is the exception — it omits the table segment:

keycloak_namespace                    # [component] name     → no table segment
keycloak_chart_version                # [component] chart_version → no table segment
keycloak_database_postgresql_name     # [database] postgresql_name
keycloak_auth_admin_password          # [auth] admin_password

Additional template directories

Beyond values.yaml.j2, a component can include additional manifests in a subdirectory. The directory name depends on the component format:

• helm components use extra/. These manifests are included as additional ArgoCD sources on top the Helm chart pulled from the upstream OCI registry and the rendered values file.
• yaml and kustomize components use resources/. Nothing is pulled from an upstream registry — all resources are declared locally in the component directory and applied directly by ArgoCD from Git.

Any rendered kind: Secret in either directory is automatically sealed with kubeseal. All .yaml.j2 files are rendered with the same variable context as values.yaml.j2.

Overriding values

Per-component environment overrides

Any variable can be overridden via environment variable. The key format is uppercase, with hyphens replaced by underscores:

Global overrides

Global variables from platform.toml follow the same pattern but without a component prefix:

Component inventory

The platform currently includes 46 components across three groups:

Run uv run -m src.cli.main list-components to see the full list for the current version.

Related pages

• Configuration model
• Platform CLI
• GitOps workflow