Contributing to Fluxify
Fluxify is open source, and contributions of every size are welcome — a typo fix, a new workflow block, a security improvement, or a whole feature.
IMPORTANT
The full contributor guide lives in the repository, next to the code it describes, so the two can never drift apart:
👉 CONTRIBUTING.md
It covers prerequisites, step-by-step local setup, the fast inner-loop commands, where to put your change, testing, and pull request guidelines.
What you'll need
| Tool | Minimum version |
|---|---|
| Bun | v1.4.2+ |
| Docker | v20.10+ |
| Git | v2.30+ |
GitHub CLI (gh) | v2.0+ (recommended) |
Getting set up, in brief
git clone https://github.com/YOUR_USERNAME/Fluxify.git && cd Fluxify
bun install
docker compose up -d
cp env.example .env
bun run db:migrate
bun run devThen open http://localhost:8080/_/admin/ui and log in with [email protected] / admin@123. The defaults in env.example work as they are — the request worker serves every project (WORKER_PROJECT_ID=*), so there is nothing to create first. CONTRIBUTING.md has the detailed walkthrough.
Ways to contribute
| Kind | Good first place to look |
|---|---|
| Bug fixes | Open issues labelled bug |
| New workflow blocks | The Blocks reference, to see what already exists |
| Documentation | Anything on this site that confused you |
| Integrations | The Integrations section |
| Testing & bug reports | Try the Kit deployment and tell us what breaks |
WARNING
Alpha software. Platform architecture and internal APIs still change between releases. For anything large, open an issue or discussion first, so your work doesn't collide with something already in flight.
Enterprise code is licensed differently
Code in an ee folder, or in a file with .ee. in its name, is under the Enterprise Edition License, not Apache 2.0. Contributing to it gives Fluxify full rights to use and sell your change. See Licenses and Contributions.
Writing documentation
Docs on this site are written for everyone — junior developers, people evaluating Fluxify, and non-technical readers. When you edit them:
- Explain what happens and what to expect, not how it's built internally.
- Use concrete examples with realistic inputs and outputs.
- Reach for tables and callouts (
::: tip,::: info) to keep pages scannable. - Diagrams are supported — use a
```mermaidcode fence.
Every page should make sense to someone reading it cold.
Cutting a release
For maintainers. A release is a tag and nothing else — pushing an annotated v* tag to main runs the whole test suite, then builds and pushes the three images and publishes the GitHub release.
git tag -a v0.1.0-alpha.1 -m "v0.1.0-alpha.1"
git push origin v0.1.0-alpha.1| Images published | fluxify-admin, fluxify-orchestrator, fluxify-worker, all three on every release |
| Tags they get | The version tag, plus alpha/beta/rc for a pre-release or latest for a stable one |
| Release notes | Generated from the commits since the previous tag, with the pull commands prepended |
| A pre-release | Any tag with a hyphen (v0.1.0-alpha.1). Marked as a pre-release, and never becomes the repo's "Latest release" |
Nothing is published if any test fails, and nothing is announced unless all three images pushed. To redo a release, delete the tag and the GitHub release, then tag again — the workflow leaves an existing release alone.
Do not tag a pre-release as stable
latest is what an unpinned docker pull gets. The first tag without a hyphen creates it, so don't tag v1.0.0 until it really is.
Getting help
- 💬 GitHub Discussions — questions and ideas
- 🐛 GitHub Issues — bugs and feature requests
- 📖 Architecture — how the platform actually works
Thank you for helping build Fluxify! 🚀