Unleash OSS: a flag server, one Postgres, and a token named unleash-insecure

One Node process, one Postgres, and port 4242

The open source story is deliberately small. docker-compose.yml declares two services: a web service built from unleashorg/unleash-server:latest listening on 4242, and a db service running postgres:15. The web service points at the database with DATABASE_URL set to postgres://postgres:unleash@db/db, sets DATABASE_SSL to false and LOG_LEVEL to warn, and declares depends_on db with condition service_healthy so the server waits for the database rather than racing it. The healthcheck is a wget against http://localhost:4242/health, with a 1 second interval, a 1 minute timeout, 5 retries and a 15 second start period, which is the entire tolerance budget for a cold start that includes database migrations.

The shipped tokens are named unleash-insecure, and the compose file says not to use it

Two environment variables decide whether this stack is a demo or a breach. INIT_BACKEND_API_TOKENS is set to default:development.unleash-insecure-api-token and INIT_FRONTEND_API_TOKENS to default:development.unleash-insecure-frontend-api-token, and a comment in the file says the default backend API token is insecure and should not be used in production. The database side is looser still: POSTGRES_HOST_AUTH_METHOD is set to trust, which the file itself annotates with DON'T DO THIS IN PRODUCTION. The header comment goes further and says the configuration is intended for demo, development and learning purposes only, and that Unleash does not take responsibility for data leaks arising from it. Copying docker-compose.yml into a production host means shipping a published admin token and an unauthenticated database.

AGPL-3.0-or-later, and four Enterprise features the open source tier does not carry

package.json declares the license as AGPL-3.0-or-later, and the repository license file matches, so anyone who modifies Unleash and serves it over a network is working inside a copyleft grant rather than a permissive one. It also splits the product in two: the open source server is what the repository builds, while role-based access control, change requests, single sign-on and SCIM for automatic user provisioning are listed as Unleash Enterprise features, reachable through a hosted instance with unlimited projects and environments or a 14-day cloud trial. That split is the practical limit for a team that needs SSO on day one: the repository does not deliver it.

The token type decides which URL your SDK is given

Connecting an SDK is where the two API surfaces separate, and the quick start gives both values explicitly. Frontend code is pointed at http://localhost:4242/api/frontend/ and authenticates with the clientKey default:development.unleash-insecure-frontend-api-token. Backend services use the Unleash API URL http://localhost:4242/api/ and the API token default:development.unleash-insecure-api-token. The README warns that a different setup produces different configuration details, so treat these four values as development defaults only.

Checking a flag is one call, and it looks the same in every SDK

Once connected, the runtime check is a single function call, and the README gives the Java shape of it:

if (unleash.isEnabled("AwesomeFeature")) {
  // do new, flashy thing
} else {
  // do old, boring stuff
}

The syntax changes per language but the contract does not: one boolean per flag name. The point of the design is that you can deploy code to production before the feature is on, test it against real production data, and work on several features at once without separate branches. That is also where the operational weight lands. A service that accumulates flags keeps evaluating them until they are cleaned up.

Node 22 is the floor, and the image pins 22.23-alpine3.23

package.json sets engines node to >=22, so an older runtime will not do, and the Dockerfile starts from an argument with a default of 22.23.4-alpine3.23. The build runs on corepack with pnpm install --frozen-lockfile --ignore-scripts, then prunes to production dependencies before the second stage copies the build output and node_modules into the runtime image, exposes 4242, switches to the node user and starts node dist/server.js with TZ=UTC. The repository layout matches that build: src/ for the server, frontend/ for the UI, docker/ plus three compose files, pnpm-lock.yaml and pnpm-workspace.yaml for the workspace, biome.json for formatting and vitest.config.ts for tests.

Fifteen official SDKs, and a custom one means reimplementing the same two endpoints

Coverage is the argument the project makes: 15 official client and server SDKs, over 15 community SDKs, compatibility with any language and framework, and permission to write your own. That last option is the one to think about carefully. An unofficial SDK is not a thin client, because it has to speak the same HTTP surface, hold the right token for the frontend or backend API, and apply whatever caching rule the official ones already implement. A team choosing Unleash for a language with no SDK is committing to that maintenance.

Self-hosting to production means a persistent server, and the guides name two providers

The README is direct about the boundary between the local stack and a real deployment: to self-host in production you need a persistent server, and the guides it links cover Heroku and DigitalOcean, with the documentation handling getting started with self-hosting and the configuration options. A team expecting a horizontally scaled control plane should read the documentation before designing around one. Two shortcuts exist for evaluation: a shared live demo instance with core functionality and no signup, and a 14-day Enterprise cloud trial that carries the full feature set.

Editorial conclusion

Adopt Unleash when your team wants a self-hosted flag server it can read, patch and run against Postgres, and when Node 22 plus a database is infrastructure you already have. Do not adopt it if you need role-based access control, change requests, single sign-on or SCIM in the open source tier, since the README assigns those to the Enterprise product, and treat AGPL-3.0-or-later as the deciding constraint before you fork it. Verify two things on day one: that you have replaced the default:development.unleash-insecure-api-token and set POSTGRES_HOST_AUTH_METHOD to something other than trust, and that your SDK points at http://localhost:4242/api/ for backend flags or http://localhost:4242/api/frontend/ for frontend ones.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Unleash/unleash on GitHub