AppConfig + dynamic config strategy

Problem

You distribute one loader binary across Starter, Pro, and Enterprise tiers. Hardcoding tier logic per build explodes CI matrix size and leaks feature-gate decisions into the build pipeline.

Solution

Embed a signed AppConfig blob inside the binary's resource section. The loader reads it at startup, validates the Ed25519 signature against a baked-in public key, then branches on tier, feature flags, and endpoint URLs. The config is updated via the auto-update CDN independently of the loader binary.

Structure

{
  "version": 2,
  "tier": "pro",
  "features": {
    "kernel_driver": true,
    "etw_monitor": true,
    "tpmi_fingerprint": false
  },
  "endpoints": {
    "auth": "https://auth.getnimbus.net",
    "cdn": "https://cdn.getnimbus.net"
  },
  "grace_days": 7
}

Key decisions

• →Sign with Ed25519 — loader rejects unsigned or tampered configs at boot.
• →Version field enables forward-compatible schema evolution.
• →Feature flags are booleans, not tier enums — decouples packaging from capability.
• →Grace period baked into config lets CDN push emergency offline windows.