Deployment
Deployment Overview
Once a workflow is ready, you have two different paths to a running backend — pick the one that matches how much you want to own versus how fast you want to ship.
Why there are two deployment paths
Not every team wants the same tradeoff between control and speed. Fimaflow doesn't force a choice between "visual builder toy" and "real backend" — it gives you both, from the same workflow:
- • Framework Export — generate a standard project in the framework of your choice, take the source code, deploy it wherever you already deploy backends. Full control, your own infrastructure, your own CI.
- • Runtime — skip the export step entirely and let Fimaflow host the workflow directly, with automatic deploys, previews and rollbacks. Fast, zero infrastructure to manage.
Both start from the same workflow and produce equivalent behavior — the choice is purely about who runs the resulting service.
What export actually produces
Exporting analyzes your workflow's nodes and edges and generates a complete, standard project for the backend framework you chose: routes, database access, business logic, and a Dockerfile — all as plain, readable source files. There is no runtime dependency on Fimaflow in the generated code — once it's exported, it runs the same whether or not your Fimaflow account still exists.
See Framework Export for supported frameworks and exactly what gets generated, and Docker Export for what ships in the container.
Choosing a path
- • Already have infrastructure, a CI pipeline, or compliance requirements around where code runs → export, and deploy the generated project through your existing process.
- • Want to go from workflow to a live, public URL in minutes, with no server to provision → Runtime.
- • Not sure yet → start on Runtime for speed, export later once you know you need your own infrastructure. Both are always available for the same workflow — trying one doesn't commit you to it.
No vendor lock-in
The exported project is a normal codebase — commit it to your own repository, run it locally, edit it by hand, and deploy it anywhere that runs the framework you picked: your own server, a container platform, or any standard hosting provider. You never need Fimaflow running to keep your backend alive. This holds even if you start on Runtime: export is available at any time, so choosing the managed path first doesn't trap you there.
Exporting again after changes
Keep iterating on the canvas and re-export whenever you want a fresh snapshot of the generated project. Export doesn't modify your workflow — it's always safe to run, as many times as you need. It also doesn't merge into a previously exported project; each export is a clean generation from the workflow's current saved state, so hand-edits made to an earlier export won't appear in the next one — see Framework Export limitations.
Interactions with the rest of the platform
- • Environment variables set in the builder become
.env.examplekeys on export, and configured directly per-environment on Runtime — see Environment Variables. - • Both paths can be triggered from a script or CI job — see CLI.