Per-Environment Config (rdt.json)

RDT uses a layered configuration system for Kubernetes deployments. Machine-wide defaults come from VS Code settings, while per-environment overrides live in rdt.json files that can be committed to version control.

Config Layering

Merge rules:

1. Start with VS Code settings as the base
2. Overlay any values defined in rdt.json (rdt.json wins)
3. Re-apply tooling keys from VS Code settings (tooling always wins)

File Location

Each environment has its own rdt.json:

<subproject>/
└── project/
    └── environments/
        ├── default/
        │   ├── rdt.json              ← per-env config
        │   ├── environment.properties
        │   └── ...
        ├── staging/
        │   ├── rdt.json              ← per-env config
        │   └── ...
        └── production/
            ├── rdt.json              ← per-env config
            └── ...

Lazy Creation

rdt.json is created automatically on first deployment if it doesn't exist:

1. You click Deploy to Kubernetes and select an environment
2. RDT calls RdtConfigLoader.loadOrCreate()
3. If rdt.json is missing, current VS Code settings are written as the initial config
4. Future deployments use the rdt.json values (which can then be customized)

This means you don't need to create rdt.json manually — just deploy and it appears.

tip

After the first auto-generated rdt.json, open it and customize values for that specific environment. The JSON schema provides full IntelliSense.

Schema and IntelliSense

The rdt.json file is validated by a JSON Schema registered in the extension's package.json:

{
  "fileMatch": ["**/project/environments/*/rdt.json"],
  "url": "./resources/schemas/rdt-schema.json"
}

This gives you:

• Autocompletion for all property names
• Validation — red squiggles on unknown or invalid properties
• Hover documentation for each field
• additionalProperties: false — catches typos and drift immediately

GIF needed

Rdt.json IntelliSense — autocomplete for property names, red squiggle on invalid property

File Format

rdt.json

{
  "helmChartVersion": "0.1.1",
  "ociRegistry": "oci://registry.example.com/samo",
  "licenseXmlPath": "licenses/license.xml",
  "licenseFilePath": "licenses/license.lic",
  "secretsYamlPath": "secrets/values-secret.yaml",
  "driverName": "postgresql",
  "lidsasProperties": "lidsas-environment.properties",
  "samogatewayProperties": "samogateway-environment.properties",
  "securityserverProperties": "securityserver-environment.properties",
  "userserviceProperties": "userservice-environment.properties",
  "licenseserverProperties": "licenseserver-environment.properties",
  "datasourceProperties": "datasource-environment.properties",
  "lidsasMasterProperties": "lidsas-master-environment.properties",
  "configPackagesPath": "configuration/packages"
}

Allowed Properties

Property	Type	Description
helmChartVersion	string	SAMO Helm chart version
ociRegistry	string	OCI registry URL
licenseXmlPath	string	Path to license XML (relative to workspace)
licenseFilePath	string	Path to license file (relative to workspace)
secretsYamlPath	string	Path to secrets YAML
driverName	"oracle" or "postgresql"	Database driver
lidsasProperties	string	LIDS-AS property file name
samogatewayProperties	string	SAMO Gateway property file name
securityserverProperties	string	Security Server property file name
userserviceProperties	string	User Service property file name
licenseserverProperties	string	License Server property file name
datasourceProperties	string	Datasource property file name
lidsasMasterProperties	string	LIDS-AS Master property file name
configPackagesPath	string	Configuration packages directory

warning

additionalProperties is set to false. Any property not in the list above will cause a validation error. This is intentional — it prevents configuration drift and typos.

Excluded Properties (Tooling Keys)

The following properties are never stored in rdt.json:

Property	Why
kubectlPath	Machine-specific binary location
helmPath	Machine-specific binary location
helmTimeout	Machine-specific performance preference
namespace	Derived dynamically from OS username

These are always read from VS Code settings, ensuring rdt.json is safe to commit to version control and share across the team.

Example: Multi-Environment Setup

A typical project with three environments, each with different database targets:

environments/dev/rdt.json

{
  "driverName": "postgresql",
  "secretsYamlPath": "secrets/dev-secrets.yaml"
}

environments/staging/rdt.json

{
  "driverName": "postgresql",
  "helmChartVersion": "0.2.0",
  "secretsYamlPath": "secrets/staging-secrets.yaml"
}

environments/oracle-test/rdt.json

{
  "driverName": "oracle",
  "secretsYamlPath": "secrets/oracle-secrets.yaml"
}

Values not specified in rdt.json fall back to your VS Code settings.

Version Control

rdt.json is designed to be committed:

• No machine-specific paths (tooling keys are excluded)
• No secrets (those are in the secrets YAML file)
• No personal preferences (namespace is derived from username)

Add it to your repository so the whole team shares the same environment configuration:

git add project/environments/*/rdt.json
git commit -m "chore: add per-environment deploy configs"