OSS vs PRO: which tier do you need?

Baldur comes in two tiers — a free open-source core and a paid PRO package for production teams. You start free and upgrade only when you actually need to, without rewriting anything.

What is it?

Baldur ships in two tiers:

OSS. The free, open-source core. Run pip install baldur-framework, import baldur, and you have the resilience building blocks: circuit breaker, retry, idempotency, health checks, graceful shutdown, and more. No license, no sign-up, no cost.
PRO. A paid package you add on top of the OSS core once you run Baldur in production with a team. It adds the heavier operational machinery: an audit trail, coordinated emergency controls, alert routing, and at-scale operation of the failure backlog.

That is the whole model: two tiers, OSS and PRO. Both are the same library with the same @baldur.protected API; PRO unlocks additional capability behind that API rather than replacing it.

Why it matters

A lot of reliability tooling forces a decision before you have any context: pick a plan, commit, integrate. Baldur inverts that. The OSS tier is meant to be good enough to get hooked — you adopt it as an individual developer because it solves a real problem today, for free. You only reach for PRO once the project is load-bearing enough that a team operates it in production and the cost of being blind to a failure, or of working a growing failure backlog by hand, has become real.

That keeps the choice honest:

You don't pay to evaluate. Build on OSS, ship it, and see if it earns its place — at no cost.
You reach for PRO when production starts to hurt. The trigger is a problem you can already feel — a dead-letter backlog too big to work one entry at a time, an incident you only hear about after it's over — not a plan you committed to up front. The need pulls you in; nothing pushes you.
Upgrading is not a migration. PRO is the same framework. You add a package and a license key (in production, also the two settings listed under Configuration); your existing @baldur.protected code keeps working and the PRO capabilities become available behind it.

How it works in Baldur

Adoption runs bottom-up: a developer picks up the free core, the project grows, and PRO joins when the team is running it in production.

flowchart LR
    A["Solo developer<br/>tries the OSS core"] --> B["Project ships<br/>and grows"]
    B --> C["Team runs it<br/>in production"]
    C --> D["Add PRO for<br/>durability & operations"]

What the OSS core gives you

The free tier is the resilience patterns themselves — everything a single service needs to survive a dependency failing, with zero infrastructure to start:

Circuit Breaker, Retry, and Idempotency — handle a failing or flaky dependency without making it worse, and turn away a duplicate request before it charges a customer twice.
Bulkhead isolation — give each dependency a fixed slice of concurrency (semaphore and async variants, via the @bulkhead decorator), so one slow dependency cannot exhaust every worker.
Health Check and Graceful Shutdown — tell a load balancer the truth and drain in-flight work cleanly when the process restarts.
DLQ + Replay — at a dlq=True call site, a call that raises and fails for good is captured with the context needed to run it again, unless a fallback= answered it, a cancellation from outside the call ended it (an asyncio.wait_for around it, say), or another stated rule excludes it. With a replay handler registered for that work, the backlog can be replayed once the dependency recovers, automatically when its on-recovery prerequisites (a Celery worker among them) are in place.
Metrics, System Control, and Precomputed Cache — see what's happening and switch protection on or off at runtime.

This is enough to make a real service meaningfully more resilient. What it is not is everything you need to operate that service across a team, at scale.

What PRO adds

PRO is about running Baldur in production — durability, visibility, and coordinated control that a team depends on. It leads with the operational problem each capability removes:

Production need	PRO capability
Operate the failure backlog at scale, not one entry at a time	DLQ at scale — batch replay from the console, archive/purge
Prove what changed, and what triggered it	Audit trail
Route incident alerts to the right channel instead of watching a dashboard	Unified notification
Shed load and shrink the blast radius under stress	Emergency mode · Bulkhead thread-pool isolation · Throttle
Roll config changes out safely and gate risky automation	Canary recovery · Governance
Notice when Baldur itself gets stuck	Meta-Watchdog — detects the stall and escalates to a human

A PRO subscription includes every PRO feature — capabilities are not sold or unlocked one at a time.

Graduating without a rewrite

Because both tiers are one framework, moving to PRO does not touch your application code. The dead-letter queue shows the shape. On an OSS install you write:

@baldur.protected("charge-customer", retry=True, dlq=True)
def charge(order_id: str) -> dict:
    return payment_gateway.charge(order_id)

and the capture is already real: a charge that still raises once retry gives up is set aside with the context needed to run it again, you can browse the backlog in the web console, and entries retry there one at a time through a replay handler you register. What changes with PRO is how you operate that backlog. With PRO active, the exact same code gains one-click batch replay and archive/purge retention in the console: the difference between working a large backlog one entry at a time in the console and clearing it in one action. On either tier, a retried or replayed call executes the work again, so give retry= and dlq=True only to operations safe to run a second time (a charge that must not double needs a dedup guard first).

Configuration

OSS needs no configuration to install. PRO is the OSS install plus the PRO package and a license, supplied through one of these:

Env Var	What it controls
`BALDUR_LICENSE_KEY`	The PRO license, provided inline as a value
`BALDUR_LICENSE_FILE`	Path to a file that holds the PRO license

In production (BALDUR_ENVIRONMENT=production), a process with an active license also refuses to start without two more settings: BALDUR_SECRETS_AUDIT_SIGNING_KEY, which signs the audit records PRO writes, and a SQL store for its incident records (BALDUR_SQL_DSN, or Django's DATABASES).

Individual PRO features carry their own settings, documented in their own guides and the environment variable reference. If the PRO package is absent, PRO-only knobs are simply inert: an OSS install never breaks because a PRO setting was left in place.