Skip to content
FortressFlag Docs

Python quickstart

In a few minutes your Python service will evaluate feature flags in-process — no network hop per check, no latency in your request path, one poll serving every request your process handles.

Zero dependencies: the SDK is pure standard library, on Python 3.11 and later. It works the same inside an asyncio app — evaluation is a plain in-memory read, so there’s nothing to await.

1. Install

Section titled “1. Install”

The SDK is pre-release and its repository isn’t public yet. If your team has been given access, install it straight from the repository:

Terminal window
pip install git+https://github.com/FortressFlag/FortressFlag_SDK_python

2. The server key — a genuine secret

Section titled “2. The server key — a genuine secret”

This SDK uses a server key (ffs_…), and it’s the opposite of the client keys the mobile and web SDKs ship: it can download your full ruleset, targeting rules included. Treat it exactly like a database password — an environment variable or a secret manager, never code, never a repository, never a log. The two key classes, side by side.

3. Start the client

Section titled “3. Start the client”
import os


import fortressflag


try:
    client = fortressflag.create(
        fortressflag.Configuration(key=os.environ["FF_SERVER_KEY"])
    )
except fortressflag.MalformedKeyError:
    # The one place the SDK raises: a malformed key, before anything serves.
    raise SystemExit(1)


client.start(timeout=15.0)  # returns at the first ruleset (or the deadline)


# ... your service runs; flag checks are now in-memory function calls.

start never raises — if the first fetch can’t land in time, the client keeps trying on its background thread and your callers get their fallbacks meanwhile. The poller is a daemon thread: it never blocks your interpreter from exiting.

4. Evaluate a flag

Section titled “4. Evaluate a flag”
enabled = client.bool_value(
    "new-checkout",
    fortressflag.Context(
        key="user-42",  # your stable context key: a user id, a session id — your choice
        tags={"cohort": "beta"},
    ),
    False,  # the fallback if the flag is unknown or nothing was ever fetched
)

client.string_value and client.number_value work the same way. The context key is what percentage rollouts bucket on — pass the same identifier consistently and each user gets a stable cohort. It’s your data: the SDK never validates, stores, or logs it.

That’s it — your service is evaluating flags locally. A dashboard change reaches every process within about a minute.

Evaluation never fails

Section titled “Evaluation never fails”

bool_value, string_value, and number_value always answer and never raise — a flagging problem must never take down your service. A restarted process serves your call-site fallbacks until its first fetch lands (or set cache_path in the configuration to persist the last ruleset to a file of your choosing, and restarts resume from it instantly). Even a revoked key doesn’t break anything: the SDK keeps evaluating with the last ruleset it downloaded until you hand it a new key.

Where to next

Section titled “Where to next”