Veefore-managed n8n
Deploy n8n from Veefore's hardened profile, where the controls that stop a workflow acting around Veefore are in the deployment and verified independently.
A managed deployment is n8n started from a profile Veefore issues. The difference from your own n8n is not a setting in Veefore: it is a set of controls in the deployment that workflows cannot change, each verified on its own.
| Control | How it is enforced | How Veefore verifies it |
|---|---|---|
| Node allowlist | NODES_INCLUDE loads only triggers, control flow, AI plumbing and the Veefore node. HTTP Request, Code, Execute Command, provider and community nodes do not exist in the process. |
n8n's own security audit reports the allowlist it loaded, and a canary workflow with an HTTP Request node must fail to activate. |
| Runtime hardening | Env access in nodes blocked, community packages off, file access confined, telemetry and templates off, MFA enforced. | Attested hash of the hardening values. |
| Egress | Default-deny NetworkPolicy; out only through an allowlisting proxy to the gateway and declared model hosts. |
The probe beside n8n attests the gateway is reachable and a public canary is not, directly or through the proxy. |
| Credentials | Provider secrets live only in the broker. | The n8n credential list contains no provider credentials. |
| Administration | The instance owner is the Veefore service account; tenant users are members. | User roles from the n8n API. |
| Configuration | The running profile equals the one issued. | Attested profile hash. |
A managed runtime always fails closed: the gateway refuses its agent's protected actions while it is Unverified or At risk, and refuses any workflow that has not passed verification unchanged.
#Isolation model
One n8n instance per tenant deployment, in its own Kubernetes namespace (or compose project), with its own encryption key, database volume, quota and egress proxy. A shared n8n process is not a tenant boundary and is not offered.
#Deploy
Register
Integrations → n8n — Veefore-managed → Add: name, agent, model-provider hosts the workflows may reach. Veefore shows an attestation private key once.
Apply the bundle
On the runtime's Managed deployment tab, take the Kubernetes or compose
bundle. Create the secret it names (N8N_ENCRYPTION_KEY, ATTEST_PRIVATE_KEY)
and the two code ConfigMaps (deploy/managed-n8n/attestor.mjs and the built
n8n-nodes-veefore). Apply with your platform credentials. Veefore does not
hold cluster credentials.
Hand Veefore the API
Create the owner as the Veefore service account. Issue an API key with
workflow:list, workflow:read, workflow:create, workflow:activate,
workflow:delete, credential:list, user:list and
securityAudit:generate, and add it with the internal URL. The write scopes
are for the allowlist canary only.
Verify
Verify now. The status reaches Enforced within scope only when the allowlist is proven, no provider credential is in n8n, tenant users are not owners, and a fresh attestation shows closed egress and a matching profile.
#Pause, disable and recover
On the Managed deployment tab. Each needs runtime:operate, step-up and a
reason, and writes a critical audit event. Agents and workflows cannot reach
these endpoints; they are on the control plane.
- Pause / Disable — every protected action from the deployment's agent is refused from that moment, in every mode. Actions already executed are not reversed. Pending approvals stay pending; executing one later re-runs the pipeline and is refused while the deployment is blocked.
- Recover — sets the deployment back to connected and re-verifies at once. If the evidence still fails, the gateway keeps refusing. Recovery is not a bypass.
#Backup, upgrade, migration
- Backup the n8n volume and keep
N8N_ENCRYPTION_KEYwith it; without the key, n8n's stored data cannot be decrypted. Veefore stores no n8n data. - Upgrade by changing the n8n version on registration of a new profile, or the image tag in the bundle, then re-verify. A changed profile hash is reported until a new attestation matches.
- Migrate by restoring the volume and secret into a new namespace, applying the same bundle, and recovering the deployment.
#Residual risk
What is not covered
- Model-provider hosts on the allowlist receive workflow data. They are not protected actions.
- DNS from the n8n pod reaches cluster DNS; exfiltration over DNS is not prevented by the HTTP proxy.
- The attestation is signed by a process on the same host. A compromised host could forge it.
- Change detection runs every two minutes. A workflow edited in between keeps its previous verification until the next sweep, unless it changes node types the allowlist refuses anyway.