Security

Your credential is used only to read. Every request Everrun makes to n8n or Make goes through a single request path per platform, and that path only issues GET requests — there is no code that can write to, edit, or trigger anything in your instances. Redirects are refused rather than followed, and connection URLs are validated against private and internal addresses before any request is made.

Your side of it: the Terms require the credentials you supply to be read-only and scoped as narrowly as your platform allows. Everrun never exercises more than read access either way, but a narrowly-scoped key is the right starting point.

Concretely, for each run we keep a status, timestamps, a duration, and — on failure — an error message that has first passed through a sanitiser. The sanitiser strips credential-shaped content: bearer and token headers, API-key and password assignments, JWT-shaped strings, credentials embedded in URLs, and the connection’s own key wherever it appears. What remains is truncated to 500 characters before storage.

One honest qualifier: error text is authored by your own workflows, so it may incidentally contain personal data. If a workflow writes personal data into its error message, a fragment of it can survive sanitisation and appear in the stored message and in the alert email about that failure. We strip credentials and secrets; we do not rewrite the remaining words.

Connection credentials are encrypted with AES-256-GCM at the application layer before they reach the database, and the encryption key is held in the hosting environment, not in the database — so a leaked database dump yields ciphertext, not working credentials. Your stored credentials are decrypted only when Everrun polls your platforms, and the plaintext is never persisted anywhere.

Zapier tokens are never decrypted at all: the inbound route recognises them by a one-way hash, so nothing that can be replayed sits readable in the database.

Every tenant table carries the agency it belongs to, and Postgres row-level security is enabled on all of them. Every query runs scoped to the calling agency — the database itself refuses cross-agency reads, rather than leaving it to application code to remember.

Everrun never connects to your Zapier account — there is no Zapier credential to hand over, store, or leak. Your Zaps send Everrun a heartbeat, authenticated by an inbound token that works in one direction only: it lets your Zaps talk to us, and it grants access to nothing of yours.

Application data is processed and stored in the EU (Frankfurt): the database and authentication run in Supabase’s Frankfurt region, and our application functions are pinned to Vercel’s Frankfurt region. Stated plainly rather than hidden: static page assets and the session-check layer of the web app run on Vercel’s global edge network — that layer reads session cookies and never touches the database.

Signing up requires confirming your email address. New passwords must be at least 12 characters. Google sign-in requests only your email and basic profile. A password reset signs out every other session, so a stolen session does not survive the reset that was meant to remove it.

Card details are collected on Stripe-hosted pages and held by Stripe. No payment-instrument data of any kind touches Everrun’s code or database.

Database backups are encrypted on our own equipment before they are stored anywhere — no storage provider ever holds a readable copy — and are retained for up to 90 days.

The complete list of third parties that handle data to run Everrun — and what each one actually receives — lives in the Privacy Policy’s sub-processor table, so there is exactly one list to keep true.

Everrun does not currently hold a third-party certification such as SOC 2 or ISO 27001. No external penetration test has been performed.

If you believe you have found a vulnerability, email privacy@everrun.dev with what you found and how to reproduce it.