Security
The invariants Norvane is built on, in the order agencies ask about them.
Norvane encrypts every n8n instance API key at rest with AES-256-GCM, decrypts it only in server-side code at the moment a request is made, and never sends it to the browser or writes it to a log. Monitoring is read-only: the product lists your workflows and executions and can change nothing on your instances.
Where are my n8n API keys stored?
Encrypted, in our database, and never anywhere else. Each instance API key is encrypted server-side with AES-256-GCM before it is ever written down. We store three things — the ciphertext, the initialisation vector, and the authentication tag — and never the key itself. Decryption happens only in worker and server code, in memory, at the moment a request to your n8n instance is made.
The decrypted key is never sent to the browser. No page, no API response, and no client bundle in the operator app can read it back — not even for the person who entered it.
The decrypted key is never logged. It does not appear in request logs, error traces, or alert payloads.
Can Norvane modify my workflows?
No. Monitoring is strictly read-only. The worker calls two n8n endpoints, both of them reads: it lists workflows, and it lists executions. There is no code path that creates, updates, activates, deactivates, triggers, or deletes anything on your instance.
Because monitoring is external, there is nothing to install inside a client's n8n either — no node, no error workflow, no webhook to maintain in every instance you run.
Where your n8n version supports scoped API keys, issue a read-only key. It is the tighter grant, and nothing in the product needs more than that.
What happens when I delete an instance?
Its key row is hard-deleted immediately. Not soft-deleted, not flagged, not queued for a nightly job — the row holding the ciphertext, initialisation vector and tag is removed at the moment you delete the instance, along with the workflow and execution data mirrored from it.
Rotating a key works the same way: the new ciphertext replaces the old row, so the previous key stops existing in our database at the point of the change.
Who can read my organisation's data?
Only your organisation. The web app talks to the database with an anonymous key under row-level security, so every query is scoped to the organisation of the signed-in user by the database itself rather than by application code that could forget. The service-role key, which bypasses row-level security, exists only in the worker process and is never present in anything the browser loads.
Client status pages are rendered server-side and filtered to exactly what the status page configuration allows. They show workflow names, status and uptime — never error contents, never your internals.
How do I report a security problem?
Write to hello@norvane.dev with what you found and how to reproduce it. Reports get a human reply. If the report involves a key you believe was exposed, rotate it in n8n first and reconnect the instance — that invalidates the old key at the source, which is faster than anything we can do on our side.
For what each plan covers and what monitoring actually watches, see Norvane plans and pricing.