Part 6 of our Workflows Unleashed series. This week: encryption, environments, and why "it's probably fine" isn't a security policy.
Your automation platform stores your database passwords. Your API keys. Your cloud credentials. Your SMTP login. Your webhook signing secrets. It has access to everything your flows need to talk to — which means it has access to everything an attacker would want.
How seriously does your automation tool take that responsibility?
Most automation tools store secrets in one of three ways:
Every secret in Flomation is encrypted with PGP before it touches the database. The encryption key is configured separately from the database credentials, so compromising the database alone doesn't expose secrets.
Secrets are decrypted at the moment of execution — in the runner's process memory, for the duration of a single action. The cleartext value exists for the milliseconds it takes to make the API call, then it's gone. It's never written to disk, never cached, and never held longer than necessary.
The executor's variable substitution system resolves ${secrets.API_KEY} at the last possible moment and never logs the resolved value. Execution history shows that a secret was used — ${secrets.API_KEY} — but never what it contained.
The editor UI shows that a secret has been set, but not its value. Once saved, the only way to "see" a secret is to update it with a new value. There's no "reveal" button, no export, no "copy to clipboard."
When a flow completes, its execution record includes the inputs and outputs of every node. Secret values are redacted before storage. You can inspect exactly what happened during a run without ever seeing a credential.
Secrets don't exist in isolation. They exist in environments — named collections of variables and secrets scoped to a context.
A typical setup:
A flow that references ${secrets.DATABASE_PASSWORD} gets the right password for the environment it's running in. No conditionals. No feature flags. No "oops, that was the production key in the staging environment."
Environments can inherit from a parent. Define shared settings once in a base environment, then override only what changes per context. The database host might differ between staging and production, but the application timeout and retry settings stay the same.
When you trigger a flow, you select the environment. The executor resolves all variable and secret references against that environment's values. The same flow binary, different configuration, different results — exactly like deploying the same application to different servers.
Role-based access control determines who can do what:
An operator who can trigger flows in production doesn't necessarily see the secrets those flows use. A developer who can edit flows in staging doesn't necessarily have access to production environments.
Every execution is recorded: who triggered it, which environment, which flow revision, what inputs, what outputs (with secrets redacted), and what the result was. When something goes wrong — or when a compliance audit asks "who accessed what and when" — the answer is in the audit trail.
We cover deployment flexibility — SaaS, on-premise, hybrid — and why the architecture that enables it also enables horizontal scaling.
www.flomation.co — free to start, no credit card.