Generate a Flux API key
In Flux Settings, create an API key with read and write scopes. Store it as a GitLab CI/CD variable (e.g., FLUX_API_KEY) so your pipelines can authenticate against the Flux REST API.
// GitLab + Flux
Connect GitLab to Flux via the REST API. Create cards from issues, update status on merge, and keep your kanban board in sync with your GitLab project. CI/CD pipelines or webhooks handle the automation.
In Flux Settings, create an API key with read and write scopes. Store it as a GitLab CI/CD variable (e.g., FLUX_API_KEY) so your pipelines can authenticate against the Flux REST API.
Add a job to your .gitlab-ci.yml that triggers on issue events or merge request merges. Use curl or a script to send HTTP requests to the Flux API with your stored API key.
When a new issue is created, POST to /api/cards to create a corresponding Flux card. When a merge request is merged, PATCH the linked card to move it to your Done or Deployed column.
For instant updates, configure GitLab project webhooks to POST to a lightweight receiver that forwards events to the Flux API. This covers events that CI/CD pipelines do not trigger on, like issue label changes.
Yes. The integration uses HTTP requests from GitLab to the Flux API. As long as your GitLab instance can reach your Flux instance over the network, the connection works the same for GitLab.com and self-hosted GitLab.
Yes. GitLab supports project-level and group-level webhooks that fire on issue, merge request, pipeline, and other events. Point the webhook URL at a small receiver service that parses the payload and calls the Flux API. This is faster than CI/CD for real-time updates.
Include the GitLab issue URL in the Flux card description when creating it via the API. You can also add a comment on the GitLab issue with the Flux card URL. There is no automatic two-way linking. You manage the references in your webhook or CI/CD logic.
// DevOps meets kanban
Flux REST API + GitLab CI/CD. Keep code and cards in sync.