Secrets & Config Management

The Problem

Secrets management starts as a .env file and quietly becomes a liability. Production credentials live on developer laptops. Rotating a key means updating five services and hoping you got them all. One engineer leaves the company and you spend a week auditing what they had access to.

Config management is the same story. Environment variables scattered across CI systems, Kubernetes secrets, and documentation that was last updated in 2023. The combination of secrets and config sprawl is one of the most common sources of incidents and security gaps in SaaS companies.

How Flux Handles It

Flux provides a centralized secrets and config layer that’s aware of your environments, your tenants, and your team:

• Environment-scoped secrets: Development, staging, and production secrets live separately, with promotion workflows to move values between environments safely
• Tenant-scoped config: Override any value per organization — give one enterprise customer a different API endpoint or limit without forking your app
• Access control: Secrets are scoped to teams and roles; developers can read dev secrets without touching production
• Rotation built-in: Rotate a secret and Flux propagates the change to every service that consumes it, with zero-downtime switchover
• Audit trail: Every read, write, and rotation is logged with actor, timestamp, and context

What Makes It Different

Most secrets managers are vaults — they store values and return them on request. Flux secrets are connected to the rest of the platform. A secret rotation triggers a deployment event in your audit log. A tenant-scoped config override is tracked alongside the organization record. The access control model matches the one your app already uses.

use flux_sdk::Flux;

let flux = Flux::init("your-api-key");

// Fetch a secret — resolved for the current environment
let db_url = flux.secrets().get("database_url")?;

// Fetch a config value with a tenant override
let api_limit = flux
    .config()
    .for_org(&org_id)
    .get("api_rate_limit")
    .unwrap_or(1000);

No .env files in your repo. No credentials on developer laptops. No 2am rotation incident. Just configuration that works the way your app does.