Environment Variables

The .ENV node

Drop a .ENV node onto the canvas and add as many key/value pairs as you need — a database URL, an API key, a feature flag. A workflow can use several .ENV nodes if you want to group variables by concern.

• • DATABASE_URL = postgres://localhost/db
• • API_KEY = sk-abc123xyz

Referencing a variable

Any text field on any node can reference a variable with {{KEY_NAME}}. At execution time, Fimaflow resolves it against your workflow's variables — if nothing matches, it falls back to the incoming input, and if still nothing matches, the placeholder is left untouched so you notice the typo immediately instead of silently sending the wrong value.

Keeping secrets safe

Values that look like credentials — anything named like a password, token, secret or API key — are automatically masked wherever execution logs would otherwise show them. You can debug a run in full detail without ever leaking a secret. See Debugging.

Exporting to production

When you export a workflow to a backend framework, its variables travel with it — ready to be filled in as real environment variables on wherever you deploy the generated project, without touching a single line of the generated code.

Example: fixing the "Create Order" workflow

In Debugging, the SQL node failed because DATABASE_URL was never set. The fix is a single .ENV node:

.ENV
  DATABASE_URL = postgres://prod-user:••••••@db.internal:5432/orders

SQL node → connectionUrl: {{DATABASE_URL}}

Re-run the workflow and the SQL node resolves {{DATABASE_URL}} against the .ENV node, connects, and the request completes end to end — and the password never appears in plain text in any log, on the canvas or during export.