A private environment for every customer
Most integration platforms put every customer into one shared database and keep them apart with a tenant column. We do not. Each paying customer gets their own environment: their own database, their own queue, their own background worker, and their own encryption key.
What a dedicated environment includes
Going live on a paid plan provisions a complete environment that belongs to you alone, not a slice of a shared one:
- Its own PostgreSQL database, holding only your flows, mappings, credentials, run history, and audit trail
- Its own Redis queue, so your jobs never sit behind another customer's backlog
- Its own background worker process, running only your scheduled and triggered syncs
- Its own encryption key and its own environment secrets
There is no tenant column to get wrong
The per-customer database schema has no organisation id and no tenant id anywhere in it, because there is only ever one tenant inside it. This removes an entire class of failure. The classic multi-tenant bug, a query that forgets its tenant filter and quietly returns someone else's rows, has nothing to leak into here. Isolation is a property of the architecture rather than a condition in a WHERE clause that a future change might drop.
What the shared layer holds, and what it never holds
A shared control plane handles the things that genuinely span customers: sign in, workspace and user records, subscription status, support, and a pointer to where your environment lives. It never holds your integration data, your system credentials, or the records we move on your behalf. Those exist only inside your own environment.
Failures stay where they happen
Separation buys operational safety as well as data safety. A heavy sync in another customer's environment cannot exhaust your queue. Another customer's schema migration cannot lock your tables. An incident in one environment does not spread to the others, because there is no shared component for it to spread through.
Both directions of access are authenticated
The control plane reaches your environment over a bearer token issued for that environment alone, compared in constant time so a failed attempt leaks nothing through timing, and rotated on a schedule. Traffic does not flow the other way: your environment has no route into the shared database and no credentials for it.
The free sandbox is different on purpose
Free workspaces live in the shared control plane and have no environment of their own. That is deliberate: the free tier is a sandbox for testing against your real systems, with manual test syncs, not a production runtime. A dedicated environment is provisioned when you move to a paid plan.
Common questions
- Is my data ever in the same database as another customer's?
- Not on a paid plan. Your flows, mappings, credentials, run history, and audit trail live in a database provisioned for you alone.
- What about the free tier?
- Free workspaces live in the shared control plane and do not run production syncs. They are a sandbox for testing whether we fit before you commit.
- Do customers share an encryption key?
- No. One key per environment, so a key can only ever open the data of the customer it belongs to.
- Can another customer's traffic slow my syncs down?
- No. Your queue and your worker process are yours. There is no shared job runner for a noisy neighbour to saturate.
- What happens to my environment if I close my account?
- The workspace and its environment are removed, subject to any records we are legally required to retain. See our data retention page for the specifics.
Keep reading
Still have a question?
Start a chat and a real person will answer it. No ticket queue.