Skip to content
FortressFlag Docs

Node.js quickstart

In a few minutes your Node 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 runtime dependencies: the package’s dependencies block doesn’t exist, and stays that way.

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
npm install github:FortressFlag/FortressFlag_SDK_node

The package is ESM-only. On Node 22 and later, CommonJS code can load it with a plain require("@fortressflag/sdk-node") too.

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 { create } from "@fortressflag/sdk-node";


let client;
try {
  client = create({ key: process.env.FF_SERVER_KEY });
} catch (error) {
  // The one place the SDK throws: a malformed key, before anything serves.
  console.error(error);
  process.exit(1);
}


await client.start(AbortSignal.timeout(15_000)); // resolves at the first ruleset (or the deadline)


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

start never rejects — if the first fetch can’t land in time, the client keeps trying in the background and your callers get their fallbacks meanwhile. And the poller never keeps your process alive: when your code finishes, Node exits as usual.

4. Evaluate a flag

Section titled “4. Evaluate a flag”
const enabled = client.bool(
  "new-checkout",
  {
    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 and client.number 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, string, and number always answer and never throw — a flagging problem must never take down your service. A restarted process serves your call-site fallbacks until its first fetch lands (or set cachePath 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”