Philosophy

Why Rust

Infrastructure lives in the hot path. Every authentication check, every flag evaluation, every rate limit decision — these happen on every request, before your application logic even runs. A garbage collector pause at the wrong moment isn’t a theoretical concern; it’s a P99 spike, a timeout, a frustrated user.

We chose Rust because it gives us zero-cost abstractions, predictable single-digit microsecond performance, and a memory model that makes entire classes of runtime bugs impossible. There are no GC pauses to tune, no warm-up period before performance stabilizes, no surprises under load.

But Flux isn’t a Rust-only product, and it never will be. Rust is the engine. The SDKs — Python, TypeScript, Go, Ruby, Java — are the steering wheel. You get the performance whether or not you write a single line of Rust. The choice to build in Rust is our problem to solve, not yours.

Why Catppuccin

Our design system uses Catppuccin Mocha. This is a deliberate choice, not a default.

Most dark themes optimize for contrast at the expense of comfort. They’re cold — stark whites on near-blacks, eye-strain after an hour. Catppuccin is warm. The palette was designed for extended use, for people who spend their days in terminals and editors and dashboards.

Catppuccin is the theme of developers who think about their tools. It’s in Neovim configs and WezTerm settings and Obsidian vaults of people who see no contradiction between caring about performance and caring about aesthetics. These are Flux’s people.

When your infrastructure dashboard looks like your editor, you’ve removed one more context switch from your day. That’s a small thing. Small things add up.

Why Unified

The SaaS industry accidentally created a fragmentation problem.

Authentication became a company. Feature flags became a company. Billing became a company. Observability became a company. Each solved its problem well. Collectively, they created a coordination burden that falls entirely on you — the person trying to build a product.

The best individual tool in each category is not the same as the best overall system. A unified platform that understands the relationships between auth, billing, flags, and rate limiting can do things that no combination of best-in-class point solutions can: answer entitlement questions in a single call, maintain consistent tenant context across every subsystem, surface cross-cutting insights that require data from multiple domains.

We’re not building a feature-flag tool that also does auth. We’re building a single system that treats all of these concerns as what they are: deeply interconnected parts of the same problem.

Why Open

Trust is earned, not declared.

Our changelog is public because you deserve to know what changed and when. Our comparisons are honest — we tell you when Auth0 or WorkOS or LaunchDarkly is genuinely the better choice for your situation. Our architecture is documented because black boxes make bad infrastructure.

We build in the open because we think the alternative — opaque pricing, vague SLAs, changelog-free releases — is a way of treating customers as accounts rather than partners. We’d rather lose a customer to a competitor we recommended than keep one by obscuring the truth.

Openness isn’t just a values statement. It’s a competitive strategy. Teams that trust their infrastructure vendors ship faster, escalate less, and stay longer. We want to be the vendor you trust.