Straight answers for the person told to “check this Entrilla thing”.

Each customer gets their own single-tenant instance — their own application and their own database, hosted in Sydney, Australia. There is no shared database and no shared application: each customer's workspace is a separate deployment, so a fault in another customer's instance stays in theirs.

The account service (app.entrilla.com) holds accounts, subscriptions and billing, never workflow content; counts (people, departments, workflows and AI use) do flow to it. Our infrastructure automation, which runs in the account service, can operate any instance (start, stop, restore, delete, and in principle open a shell), as any hosting operator can. The account service has no code path that reads instance content, and every action it takes is written to an audit log.

Inside the product, a five-level permission ladder controls who sees what, including who sees pay rates. Entrilla support sees inside your Entrilla only when one of your admins turns on “Let Entrilla support in”, for 1, 4, 24 or 72 hours, at viewer level unless they choose higher (never admin). Everyone in your organisation sees a banner while it is on, and your admins see everything support opens. People, keys, sign-in settings, passwords and the export stay refused to support whatever the level.

The founder runs the platform. His admin console has two locks: Cloudflare Access, with his Microsoft sign-in and multi-factor authentication, then a 6-digit code from an authenticator app, asked again before anything destructive. Every console action is written to an audit log under his name.

Operator commands run over the hosting provider's SSH with his own named login, not a shared account, and each one is written to the audit log with its full command line. The honest gap: a shell opened directly on a server isn't tied to a named person in our own logs. Today the founder is the only person with that access.

The AI never changes a live workflow on its own. It edits one only when a person in your organisation asks it to, saving a version first so the change can be put back, and its recommendations change nothing until someone accepts them.

The AI runs in the United States, not Australia, for now. Your instance and its backups are in Sydney; the AI model is not.

Workflow content is sent to Anthropic's API to answer each request. AI by Anthropic, processed in the United States, not used to train models, under Anthropic's commercial terms. Anthropic may keep requests for a limited period under those terms; we have no zero-data-retention arrangement. Answers come back to your instance, and Entrilla stores them only there. Your data is never used across customers.

TLS on every connection; encrypted at rest. Backups every 6 hours, encrypted with a key unique to your instance, stored in Sydney and locked against deletion for 30 days. Each week we restore one instance's newest backup as a drill. The last passing restore test was on 17 October 2026.

One-click export of every workflow, anytime. After your plan ends, your instance stays read-only for 37 days, then is paused with export still open. It is deleted within 60 days of your plan ending (within 7 days on written request), and the locked, encrypted backup copies are purged by 36 days after deletion. We confirm the deletion in writing.

Starter plans and above sign in with Microsoft or Google, built in, or with Okta on request (set up in your own Okta organisation), so there are no separate passwords to manage. SAML single sign-on with automatic provisioning is planned for Enterprise, built when the first Enterprise customer needs it.

Additions are announced 30 days ahead by email to account owners. The website's own analytics are covered in the privacy policy. Security researchers and reviewers: security@entrilla.com.