Why you need a feature flag manager
Continuous deployment assumes a clean separation between shipping a binary and enabling a feature for users. Without that separation, every release is binary: either everyone sees the change, or no one does. When something breaks, the only recovery path is a full deployment rollback — typically 10 to 30 minutes and an incident ticket.
Unleash breaks this coupling. You merge, deploy, then enable the feature manually or through a configurable gradual rollout. If something goes wrong, you flip the toggle off — seconds, not minutes, and no deployment pipeline involved.
The second use case is experimentation. By defining a user segment (beta testers, Pro plan, users from a given country), you can activate a feature for them alone and measure impact before rolling it out to everyone. This is the Experiment flag type: you are A/B testing a real feature in production, not a staging copy.
Unleash open source (Apache-2.0) covers both cases with projects, environments, activation strategies and a full audit log — without any proprietary lock-in.
What you gain with self-hosted Unleash
- Real-time toggles — enable or disable a feature without redeploying your application.
- Gradual rollouts — open to 5 %, 20 %, 50 % of your users, with targeting by userId, email, or custom attribute.
- Separate environments — maintain independent flag states for development, staging and production.
- Multi-language SDK — official clients for Node.js, Python, Go, Java, .NET, Ruby and PHP; local evaluation for zero added latency.
- Full audit log — every flag change records the author, timestamp and reason.
- Zero-downtime updates —
docker compose pull && docker compose up -d, automatic PostgreSQL migrations.
Requirements
Unleash is designed to run on a modest VPS. The minimum recommended configuration is 1 vCPU and 1 GB RAM — the Node.js application uses around 86 MB at idle, PostgreSQL 17 around 46 MB, for a total of roughly 132 MB under test conditions. In production with active SDK traffic, budget 256 MB of headroom; a 1 GB VPS is comfortably sufficient.
No domain is required to get started — Unleash listens on the loopback and is reachable via SSH tunnel. For permanent access from your applications and CI pipelines, attach a domain from your ServOrbit dashboard: nginx will proxy it over HTTPS.
Docker must be installed on the VPS. The ServOrbit template pre-configures it automatically — no manual setup needed.
Deploy Unleash on your ServOrbit VPS
Order from the ServOrbit Marketplace
From your ServOrbit client area, install Unleash in one click from the Marketplace: select the Development category, choose Unleash and confirm your order. The Docker Compose stack (Unleash + PostgreSQL 17) starts automatically on your VPS. You will receive a notification when the healthcheck passes, with the assigned exposure port and the generated admin password.
Log in to the admin UI
Open
https://<your-domain>/in your browser — or, without a domain, open an SSH tunnel:ssh -L 4242:127.0.0.1:<port> root@<vps-ip>then browse tohttp://localhost:4242/. The login page is at/auth/simple/login. Enteradminas the username and the password from your ServOrbit client area.Create a project and your first flag
In the Unleash UI, create a project (e.g.
my-app). Inside that project, click New feature flag. Give it a name (new-checkout), choose the type — Release for a gradual rollout, Kill switch for a safety breaker, Experiment for an A/B test — and confirm. The flag is created but disabled by default in all environments.Configure an activation strategy
Click your flag, then click Add strategy in the environment of your choice (default:
production). Unleash offers several strategies: Standard (on for everyone), Gradual rollout (percentage of users), UserIDs (explicit list), Remote address (by IP). For a gradual rollout, choose Gradual rollout and set the slider to 10 %. Click Save strategy — the flag is now active for 10 % of your users.Connect your application via SDK
Install the SDK for your language:
npm install unleash-client(Node.js),pip install UnleashClient(Python), or the equivalent package in your ecosystem. Initialise the client with your Unleash API URL (https://<domain>/api) and a CLIENT API key (create one in Unleash → Settings → API access → Add new API token, type CLIENT). Then callclient.isEnabled('new-checkout')wherever you want to gate behaviour.Monitor and adjust
The Metrics tab on each flag shows the count of positive and negative evaluations per period. Increase the rollout percentage by editing the strategy, or disable the flag globally from the dashboard if you observe a problem — no redeployment needed. To permanently archive a fully-enabled flag, click Archive in the flag settings.
For Kill switch flags, enable impression data in your SDK (impressionDataAll: true): each evaluation fires an event you can route to your observability stack (Glitchtip, Plausible) to correlate a rollout with changes in your business metrics.
Environment management and promotion
Unleash open source creates two environments by default: development and production. Each flag has an independent state per environment — you can enable a feature in development for the whole team while keeping the production rollout at 0 %. This is the promotion model: the feature is tested in development, then deliberately enabled in production through a UI action.
To add a staging environment, go to Unleash → Settings → Environments → Add environment. Name it staging and save. Each flag will now show three environment tabs. The SDK must be initialised with environment: 'staging' (or 'development') so evaluations land in the correct state.
A common pattern: enable a feature in staging for the full QA team (UserIDs strategy with internal emails), and in production with a Gradual rollout at 5 %. The two strategies coexist in the same flag, in different environments — with no conflict.
API tokens and security
Unleash separates tokens by type and environment. A CLIENT token gives read-only access to flag states for a given environment — this is the token to inject into your applications. An ADMIN token gives full access to the administration API — reserved for deployment scripts or integration tools, never embedded in client code.
Create a CLIENT token: Unleash → Settings → API access → Add new API token. Choose the type CLIENT, select the environment (production) and the project scope. Copy the generated value — it is displayed only once. Store it in your CI secrets (UNLEASH_API_TOKEN environment variable) or in your secrets manager vault.
On ServOrbit, Unleash is bound to 127.0.0.1 and exposed only through nginx. Port 4242 is never directly accessible from the internet — nginx adds TLS, and only the proxied domain responds on port 443. The initial admin password is generated at installation and available in your client area; change it on first login via Unleash → Profile → Change password.
CVE history and why we pin version 8.0.3
Unleash 8.0.3 is pinned in the ServOrbit template for a specific reason: two vulnerabilities were patched between 8.0.0 and 8.0.3. CVE-2026-63004 (CVSS 5.5, SSRF) allowed an authenticated admin to trigger server-side requests to internal network endpoints via the webhook configuration. CVE-2026-63466 (CVSS 4.1, stored XSS via HTML escape bypass) allowed injecting HTML into flag descriptions. Both require authentication, so the blast radius is limited to compromised admin accounts. They are fully patched in 8.0.3 — pinning the exact image tag rather than :latest ensures you always know what version is running and can audit against the CVE registry.
