I spent the last three weeks migrating a fairly standard set of automation workflows from Integromat (now Make) to Flux, and I have to say the experience was about as pleasant as a root canal performed with rusty pliers. The marketing promises a smooth transition and "powerful developer-centric workflows," but the reality is a steep, poorly documented cliff followed by a swamp of unexpected complexity.
Let's be clear: Flux is powerful. Underneath the layers of YAML and custom concepts, it's a solid GitOps engine. But selling it as a direct replacement for a visual, SaaS-based automation tool like Integromat is like selling a lathe to someone who needs a hammer. The paradigms are utterly different, and the migration path is essentially a full rewrite.
Our use case wasn't even that exotic:
* Syncing customer data from a PostgreSQL DB to Salesforce (weekly).
* Processing webhook payloads from Stripe, transforming the data, and dropping it into BigQuery.
* Sending digest emails based on aggregated log entries from Loki.
In Integromat, these were maybe 15-20 modules total. Visual, easy for the team to reason about. Flux demanded we decompose everything into Kubernetes manifests, HelmReleases, Kustomizations, and the almighty Git repository as the single source of truth.
The biggest pain points weren't the core Flux controller—it's fine. The pain came from everything around it:
* **The Mental Model Shift:** You're not building a "workflow" anymore. You're declaring desired state for applications and their dependencies. Want that Stripe webhook processed? First, you need a container image with your transformation logic. Then you need a Deployment for it, a Service, an Ingress, maybe a Secret for the API key. Then you wrap all that in a Kustomization and point a Flux GitRepository at it. For a simple data pipeline, this is massive overkill.
* **The Debugging Hell:** In Integromat, you see the execution flow, you see the data between steps. In Flux, you're staring at kubectl logs for the `flux-system` pods. Did your Kustomization apply? `flux reconcile kustomization my-app --with-source`. Did it fail? Hope you like parsing `kubectl get kustomization -o yaml` and digging into Conditions. The feedback loop is long and opaque.
* **The "Simple" Things:** Need an environment variable from a secret? That's a whole `Kind: Secret` in your Git repo, encrypted with SOPS, or you're tying into a cloud provider's secret manager. In Integromat, it's a field in a module. Need to run something on a schedule? That's a `CronJob` resource you now have to manage, not a scheduler built into the tool.
Here's a taste of what replaced a 4-module Integromat scenario that fetched and emailed a report:
```yaml
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: report-generator
namespace: flux-system
spec:
interval: 10m
path: ./clusters/prod/report-generator
prune: true
sourceRef:
kind: GitRepository
name: flux-system
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: weekly-report
spec:
schedule: "0 9 * * 1"
jobTemplate:
spec:
template:
spec:
containers:
- name: report
image: our-registry/report-builder:latest
env:
- name: DB_CONNECTION
valueFrom:
secretKeyRef:
name: prod-db-creds
key: connection-string
restartPolicy: OnFailure
```
And that's just the tip of the iceberg. You still need the GitRepository source, the actual deployment manifests for that image, the secret manifest, etc.
So, ask me anything. About the struggle of getting notification routing set up with Flux's `Provider` and `Alert` objects. About the joy of managing multi-environment promotion with `Kustomization` dependencies. About whether this was all worth it for the "benefits" of GitOps audit trails and declarative everything.
For the right use case—managing your actual Kubernetes application deployments—Flux is excellent. For replacing business logic automation built in a tool like Integromat? You've been warned.