Ardent is designed to never put your production data at risk. Here’s how.Documentation Index
Fetch the complete documentation index at: https://docs.tryardent.com/llms.txt
Use this file to discover all available pages before exploring further.
Minimal production footprint
Ardent uses logical replication to sync your table data and does not write to your application tables. During connector setup, Ardent creates one dedicated schema for its own metadata and installs DDL event triggers there so schema changes can be detected and replayed in order on the replica. This has little to no performance impact on production. Normal application reads and writes continue against your database as usual.Encryption and secrets
Ardent encrypts source database credentials, API keys, and connection secrets at rest. Replication components read credentials only at runtime when they need to connect. With BYOC (bring your own cloud), secrets live in your own infrastructure (for example AWS SSM Parameter Store). Ardent reads them directly from your secret store at runtime, and your credentials never leave your network. Every branch gets its own generated connection string. If a branch URL is ever compromised, it has zero access to your original database. This makes it safe to hand branch URLs to AI agents like Claude Code or Cursor without leaking your source database credentials. Branches are controlled through Ardent’s control plane, so you can delete or de-provision them at any time.Branch anonymization
Branches default to a full copy of your production data. When you need realistic schema and relationships but not real PII, you can run connector-scoped SQL on every new branch after it is created. Set it with the CLI:@path).
Your script might UPDATE columns to hashed or synthetic values, redact free-text fields, or trim tables that should never leave production. Execution is idempotent per branch: if Ardent re-runs the hook for that branch, successful runs are not duplicated.
This is the same branch_sql setting documented in CLI settings. There is no separate anonymization toggle: you own the SQL, so you stay in control of exactly what changes.
Each branch is a fully independent copy. Changes on one branch don’t affect production or any other branch. When you’re done, delete it or let it auto-suspend — nothing persists unless you want it to.
Data residency
In fully managed mode, your data lives on Ardent’s cloud infrastructure. In managed, your cloud mode, the entire data plane (read replica, branches, and secrets) lives in your own cloud account. Your data never leaves your network. Ardent still manages everything via the control plane. For teams with data residency or compliance requirements, the managed, your cloud deployment keeps all data and credentials inside your infrastructure while Ardent handles orchestration.Talk to us
Contact vikram@tryardent.com to run the data plane in your cloud.