The Managed Plan
How dbtrail Managed works. The trust boundary, security model, and what dbtrail stores when it operates the index for you
On the Standard plan, you run dbtrail EE yourself. On Managed, dbtrail operates it end-to-end: we provision, size, upgrade, back up, and monitor the index infrastructure (the store where your change history lives) so the history is there the day you need it. This page covers the parts worth understanding before you hand that over: the trust boundary, the security model, and exactly what dbtrail's side stores.
Read-only by design
dbtrail never executes write operations against your MySQL databases, Managed included. All connections to your source use replication-level access to read binary logs, the same footprint as one MySQL replica. Recovery always produces dry-run SQL for a human to review; dbtrail will never run SQL against your data on your behalf.
The trust boundary
Managed operates our side, never yours:
- Your production database stays yours. The capture side connects as a read-only replication client. There is no inbound path into your network: connectivity from your side is outbound-only.
- The index runs on dbtrail-operated infrastructure, inside a private VPC. The machines that hold your change history have no public IP addresses and are not directly reachable from the internet.
- With BYOS on (included; it's part of dbtrail EE), the split goes further: full row images (the before/after values) are written as Parquet to an S3 bucket you own: you control the KMS key, bucket policy, and lifecycle, and you can revoke access at any time. dbtrail's side holds the metadata index (schema, table, event type, primary key, timestamp; no row values), which is what powers search, status, and the recovery flow.
Security model
In transit. All external traffic is TLS; S3 operations are HTTPS with IAM role-based authentication (no static credentials); internal communication stays within the private VPC and is authenticated.
At rest. Stored credentials (MySQL passwords, DSNs, SSH keys) are encrypted with Fernet symmetric encryption (AES-128-CBC + HMAC integrity) before they touch a database, with the key held separately; volumes are encrypted; backup objects use S3 server-side encryption.
Secrets hygiene. Secrets live in environment configuration only, never in code or images; sensitive values are excluded from logs; processes run as dedicated non-root users.
Access control and audit. Access on dbtrail's side is role-scoped, and mutating operations are audit-logged (who, what, when, result). Column redaction and per-table/per-column RBAC from dbtrail EE apply to what your own users can see and recover.
What dbtrail stores, and what it never stores
With BYOS enabled, dbtrail's side stores at rest:
- Server connection metadata (hostnames, ports, replication positions)
- Encrypted credentials in the vault
- The metadata index: schema names, table names, event types, primary keys, timestamps, event counts. No row values.
- Audit logs (who did what, when)
Row-level data lives in your S3 bucket. When you query or recover changes, dbtrail processes matching events in memory (decoding, column redaction, recovery-SQL generation) and does not persist them after the response is delivered.
Without BYOS, the full index (including row images) lives on the dbtrail-operated index store described above: encrypted at rest, private VPC, never your production database.
Compliance
The controls above (encryption in transit and at rest, RBAC, audit logging, and secrets management) are what you'd map into a vendor security review; the compliance page maps dbtrail's capabilities to SOC 2, HIPAA, PCI-DSS, and GDPR controls. If you're completing a security questionnaire, contact us and we'll help you fill it in.
Getting Managed
Managed isn't self-serve. Talk to us or join the waitlist from the pricing page. See dbtrail EE & Plans for how Managed compares to the self-hosted paid plans.