Environments
Fluxify has two fixed environments: production and development.
Every worker belongs to exactly one of them. You pick it with the FLUXIFY_ENV setting when you start the worker:
FLUXIFY_ENV | The worker is a… |
|---|---|
production (or not set) | Production worker. Serves your live routes and runs your live workflows, triggers and schedules. This is every worker you have today. |
development | Development worker. Runs development work only. |
The two are kept apart
A production worker never picks up development work, and a development worker never picks up production work. This holds for everything a worker does: queued background work, workflow runs, schedule fires and test suite runs.
You can run a production worker and a development worker side by side, on the same machine and against the same Fluxify instance, without them stealing work from each other.
INFO
Your triggers are the same in both environments, with the same settings. A development worker does not get its own copy or a renamed one.
What a development worker does
- It serves every project. You don't point it at a project, give it a mode or assign it trigger groups.
WORKER_PROJECT_ID,WORKER_MODEandWORKER_GROUP_IDare ignored on it. - It needs no claim. You start it yourself; the orchestrator does not.
- It does not use a license slot. Community allows one worker, and you can still run one development worker beside it. See Workers per edition.
- Fluxify knows when it is running. Admin can tell whether a development worker is online for a project.
Starting one
Start a worker as usual and set FLUXIFY_ENV=development on that worker only.
You don't have to do this for the usual setups. Each of them starts one for you:
| Setup | Its development worker |
|---|---|
| Kit | Runs inside the container, on port 5602. |
| Production stack | The worker-dev service. |
| Kubernetes | One pod, from the devWorker setting. On by default. |
Running Fluxify from source (bun run dev) | A second worker on port 5602, beside the production worker on 5600. |
INFO
Every time you save, Fluxify publishes your routes, workflows, custom blocks, middlewares, triggers and packages to both environments. For now the development worker and the production worker run the same saved version. What differs between them is the values they run with.
WARNING
Don't put FLUXIFY_ENV=development in a .env file that every Fluxify process reads. That turns your production worker into a development worker, and your live routes stop being served.
Values per environment
Integrations and app config can hold two values: one for production and one for development. The development worker uses the development value, so it talks to your development database, queues and keys, never the production ones.
For each integration and each app config entry you choose one of:
| Setting | What the development worker does |
|---|---|
| Its own value (the default) | Uses the development value you set. If you have not set one, the run fails and says which value is missing. It never falls back to production. |
| Same as production | Uses the production value. |
See App Config and Integrations.
Same as production means development writes to production
With Same as production on, development runs, development triggers and the AI agent read and write your production database, queues and consumer groups. Use it only for things that are safe to share, such as a read-only public API.
Use separate development instances
Do what you would do when coding a backend by hand: point development at its own database, its own queues or topics and its own key-value store.
Triggers have the same consumer group names in both environments. A development value that points at a production queue takes production's messages.
Development access
Every project has one development access token. It lets you call the project's development routes and sandboxes from outside Fluxify, for example from Postman, curl or a frontend you are building.
Send it in the x-fluxify-dev-token header:
curl -H "x-fluxify-dev-token: fxd_..." https://your-host/...| What | Detail |
|---|---|
| Where to find it | Project settings, Development access. It also shows your development URL, ending in /_/dev. If the project has a subdomain, the URL uses it. |
| Who can copy it | Creators and project admins. Viewers don't see the section. |
| Who can rotate it | Project admins only. |
| What it opens | Development routes and sandboxes of that project. Nothing else. |
Rotating gives you a new token and the old one stops working straight away. Anything that still uses the old token, such as a saved Postman request or a frontend, has to be updated.
It never opens production
A production worker ignores this header. The token cannot reach your live routes, whatever you send.
Sandboxes take it today
Sandboxes already accept this token. Development routes arrive with the development routing work.