User Configurations

Per-user configurations let users define their own configuration derived from enterprise Configuration Templates. These configurations supply validated environment variables and mounts that can be reused across multiple authorized applications.

What You'll Learn

• Store per-user configurations at %LOCALAPPDATA%\\Turbo\\Launcher\\user-profiles.json
• Base each configuration on an enterprise template (templateRef)
• Validate user-provided environment variables and mounts against template constraints at creation and launch time

---

Terminology

• User configurations (user-profiles.json → profiles[]): Per-user environment variables and mounts validated against enterprise templates; they do not change command-line arguments.
• Launch profiles (apps[].profiles[]): App-level variants that change arguments, runtime, or post-launch actions (for example, an Incognito entry for Chrome).
• Configuration templates (configurationTemplates[]): Enterprise-governed constraints that user configurations must satisfy; apps link templates via apps[].configurationTemplates.

Use “user configuration” in UI text and docs to avoid conflating per-user environment/mount definitions with launch profiles.

How It Works

• Administrators define reusable, centrally governed constraints in the enterprise policy via Configuration Templates.
• Users create configurations in a local file that reference one of those templates via templateRef.
• When launching an app that links the same template (via apps[].configurationTemplates), the Launcher exposes user configurations for selection in the app’s context menu.
• The Launcher validates the configuration against the enterprise template before allowing use. For mounts, validation includes allowed sources, destinations, and options. Mount precedence integrates with policy: Launch Profile > User Configuration > Policy (App) > Global.

File Structure (user-profiles.json)

Location: %LOCALAPPDATA%\\Turbo\\Launcher\\user-profiles.json

{
  "profiles": [
    {
      "id": "user-project-alpha",
      "displayName": "Project Alpha Configuration",
      "templateRef": "p4-shared-environment",
      "configuration": {
        "environmentVariables": {
          "P4PORT": "ssl:p4.alpha.trusted.com:1666",
          "P4USER": "jdoe",
          "P4CLIENT": "jdoe_ws_alpha"
        },
        "mounts": [
          {
            "name": "RepoA",
            "ruleRef": "src-ro",
            "source": "D:\\Repos\\RepoA",
            "destination": "P:\\src\\RepoA",
            "options": ["read-only"]
          }
        ]
      }
    }
  ]
}

Fields

Top-level

• profiles (array): User-defined configurations.

Configuration

• id (string, required): Stable, kebab-case recommended; unique within this file.
• displayName (string, required): Label shown in UI.
• templateRef (string, required): References an enterprise template id (configurationTemplates[].id) from the active policy.
• configuration (object, required):
  • environmentVariables (object<string,string>): Key/value pairs constrained by the template’s constraints.environmentVariables.
  • mounts (array<UserMount>, optional): User-declared mounts validated against the template’s constraints.mounts.rules (allowedSourcePatterns, allowedDestinationPatterns, allowedOptions).

Validation Rules

• Template reference:
  • templateRef must match a configurationTemplates[].id in the active enterprise policy.
  • If the referenced template is missing or disabled, the configuration is considered invalid and will not appear.
• Environment variables:
  • Only keys listed in the template are accepted (recommended behavior).
  • Keys marked required: true must be present.
  • If validationPattern is defined on a key, the user-provided value must match (patternType enforced, typically regex).
• Case sensitivity:
  • Path-oriented matches are evaluated case-insensitively by default (aligned with Windows path semantics).
• Security/authorization:
  • User configurations do not authorize applications and cannot override deny rules.
  • Apps must still be discoverable and allowed by an action: "allow" policy to surface user configuration entries.

UI Behavior

When an allowed app policy includes apps[].configurationTemplates referencing the same template id(s):

• The Launcher automatically generates separate entries for each user configuration that references the linked template(s).
• Each configuration appears as a distinct launcher entry with the format: {AppName} - {ConfigurationDisplayName}
• User configurations are validated at creation and launch time against the enterprise constraints.
• Configurations can be reused across multiple apps that link the same template.
• Configuration entries automatically appear/disappear as configurations are created/deleted.
• Launch profiles (context menu variants) work with all entries, including configuration-bound entries.

Related topics:

• App linkage: Configuration Templates
• Authorization gating: Authorization & Visibility

Troubleshooting

• Configuration not shown:
  • Verify the app is discoverable and allowed (action: "allow").
  • Confirm the app’s policy includes a non-empty configurationTemplates array that contains the configuration’s templateRef.
  • Ensure templateRef exists in the system-wide policy’s configurationTemplates.
• Validation failures:
  • Missing required environment variable or pattern mismatch.

Best Practices

• Keep id stable and use kebab-case.
• Avoid storing sensitive secrets; prefer secure prompts or OS-level credential storage if available.
• Use glob for path patterns in templates; use regex for value formats like connection strings.

Schema and Editor Validation

• JSON Schema: User Configurations Schema
• Add a $schema directive to your user-profiles.json for IntelliSense and validation:

{
  "$schema": "https://schemas.turbo.net/launcher-user-configurations.schema.json",
  "profiles": []
}