Editions and Licensing

Fluxify comes in two editions. Both run from the same images; what you get is decided by the edition you pick — in the admin UI, or with the LICENSE_KEY setting.

What is in each edition

Feature	Community	Enterprise
Routes, blocks, the visual editor	✅	✅
Workflows	✅	✅
Schedules (cron, intervals, one-shot)	✅	✅
Batching	✅	✅
The Trigger Workflow block	✅	✅
Message queue triggers & Send Message blocks (Kafka, NATS, SQS, RabbitMQ, Redis Streams)	✅	✅
Single sign-on (OIDC and SAML)	—	✅
Audit Logs, a record of who changed what	—	✅

A license key says which Enterprise features it includes. Most include all of them; the License page shows exactly what yours unlocks.

Workers per edition

On the Admin + Workers setup (Docker or Kubernetes), the edition also caps how many workers run at once, across every claim and every project:

Edition	Workers	What they can be
Community	1	One worker that serves every project and does both jobs (both).
Non-commercial	2	Any type, for any project. For example one route worker for your APIs and one workflow worker for background work, or one both worker per project.
Enterprise	No limit	Any type, for any project, and claims can autoscale.

A second cap applies too: the node pool, in Instance settings → Orchestration. It is how many workers this instance is willing to run, and it starts at 2. The smaller of the two wins, so raise the pool when an Enterprise license should run more.

Workers that serve the development environment are outside the edition entirely: a development worker, or a development claim, takes no license slot, on any edition. So Community's one slot can run one production worker and as many development ones as you ask for.

The edition's other rules are about production capacity too, and they do not apply to a development claim either: it may be any worker type and belong to a single project even where the edition allows neither — on Community, a project's development claim is created where the same claim in production is refused.

The node pool is the limit a development worker does answer to, because it is a real worker on your machine. Raise it (see above) if development work needs room of its own.

A claim that asks for more than fits is kept, and its workers wait as pending until room frees up. A new instance runs non-commercial, so it can run two workers from the start. An Enterprise license that expires keeps its workers through the grace period, then drops to the Community limit.

Development workers are free. A worker started with FLUXIFY_ENV=development is not counted against these limits, on any edition, so Community can run its one worker plus a development worker beside it. It never serves your production traffic or runs production work. The Kit, the compose file and the Helm chart each start one for you. See Environments.

The Kit image has no workers to cap: it always runs its one built-in worker, plus a development worker.

Picking your edition

System admins manage the edition under Instance Settings → License. The page shows the edition that is running, whether it is active or expired, and which features it unlocks. There are three choices:

Edition	What you do	What you get
Community	Pick it	Free for any use, including commercial.
Non-commercial	Pick it and confirm your use is personal, education, or non-profit	Every Enterprise feature, at no cost
Enterprise	Paste the license key you were issued	The features your key includes, until it expires

The change takes effect on the admin and every worker within a few seconds. Nothing needs to restart.

A new Fluxify instance runs the non-commercial edition until you pick another one. See Licenses and Contributions for exactly who qualifies for non-commercial use.

Enterprise keys before the 1.0 release

Fluxify does not issue license keys yet, so no key you can be given will verify. Non-commercial unlocks every enterprise feature in the meantime; to test a signed key — an expiry date, a licensee name, a feature subset — sign one yourself, see Self-signed licenses.

When you paste a license key, Fluxify checks it before saving it. A key that is mistyped, cut off, edited, or already expired is refused with the reason, and the edition you had stays as it was.

Your key stays private

Once saved, a license key is stored encrypted and is never shown again — not in the UI, not in any API response, not in the logs. The page shows only a short fingerprint, so you can tell which key is active without seeing it.

Setting the license with LICENSE_KEY instead

You can also set the license in the .env of your admin container (or the Kit container). It then takes priority over the UI.

LICENSE_KEY value	Edition you get
Not set	Whatever is picked in the UI
NON_COMMERCIAL	Enterprise, for non-commercial use
A license key you were issued	Enterprise, until the key expires

# .env
LICENSE_KEY=NON_COMMERCIAL

While LICENSE_KEY is set, the License page is read-only and says the license is managed by the environment. To manage it from the UI again, remove the line and restart the admin container. Changing LICENSE_KEY always needs a restart; changes made in the UI never do.

You do not need to set it on workers. They learn the edition from the admin container automatically.

A key that doesn't work never stops Fluxify

If LICENSE_KEY holds something that is not a valid key — a typo, a key cut off when it was pasted, or an edited key — Fluxify still starts. It runs as Community, the License page shows the key as invalid with the reason, and the admin log records the error.

Checking which edition is running

Open Instance Settings → License. The admin log also includes one line like this when it starts, and whenever the edition changes:

edition: enterprise (license active)

Workers write the same line when they start.

What happens when a license expires

An expired license does not take anything down straight away. You have a 30-day grace period to renew.

	Before expiry	Expired, within 30 days	After the 30 days
Audit logs keep recording	✅	✅	❌
You can change project audit settings	✅	❌	❌
People can sign in with SSO	✅	✅	✅
You can change the SSO configuration	✅	❌	❌
Community features	✅	✅	✅

• During the grace period, the dashboard shows a banner with the number of days left, so you find out before anything stops.
• After the grace period, Enterprise features stop until the license is renewed. Everything in the Community edition keeps working.

SSO sign-in is the one thing that never stops

On an instance that enforces SSO, most administrators have no password. Taking SSO away with the license would lock every one of them out, so it never happens: people keep signing in through the identity provider whatever the license says. What the license gates is changing the configuration — an unlicensed instance cannot turn SSO on, edit an existing connection, or rotate its secret. The login page says so, with the days of grace left.

Upgrading? If your instance already uses SSO and you are on Community, set LICENSE_KEY=NON_COMMERCIAL (or paste a key) to keep it editable. Sign-in is unaffected either way.

To renew, paste your new key on the License page. If you use LICENSE_KEY, replace it with the new key and restart the admin container.