Why we chose Turso to secure AI credentials

Eden is a gateway and control plane for infrastructure access. It routes traffic, applies policy, resolves credentials, records telemetry, and gives teams one place to understand what their applications and agents are doing. That kind of system belongs near the workload.

If Eden is routing Redis traffic, it should live near Redis. When it's governing an internal API, it should run inside the same private network. For AI traffic, it should sit close to the model endpoint, tool server, or application path where the request is actually happening.

A gateway that sits between applications and databases, APIs, or AI providers has to care about latency, data residency, network boundaries, failure domains, and the number of moving parts required to run it. Every extra hop matters. Every cross-region call matters. Every required service adds operational overhead. Every dependency on an external control-plane database makes the deployment harder for on-prem, air-gapped, or low-latency environments.

That's why we built Eden's embedded deployment path.

The goal is simple: let teams run Eden as close as possible to the database, API, or AI endpoint they need to govern, without forcing them to stand up Postgres or operate a bundle of supporting services just to get the control plane working.

Turso is the foundation that makes that possible.

#Why gateway placement matters

Eden is designed to run wherever the traffic path needs it.

For a database gateway, the gateway shouldn't add avoidable network distance between the application and the database. When an app is talking to Redis in a private subnet, Eden should be deployable in that same network path. For customers running databases on-prem, the gateway should be able to run on-prem too. When an AI workload calls a local model endpoint or internal tool API, the control point shouldn't require traffic to leave the environment just to make a policy decision.

The same pattern shows up across use cases:

Low latency: keep the gateway close to hot database and API paths so Eden can enforce policy without adding unnecessary round trips.
On-prem and private networking: deploy Eden inside the customer environment when data, credentials, or endpoints can't leave.
Data residency: keep control-plane state and gateway traffic within the boundary required by the customer.
Operational simplicity: run one Eden binary with embedded control-plane state instead of provisioning a separate Postgres service for small, local, embedded, or edge-adjacent deployments.
Resilience: let gateway deployments keep their local configuration and state close to the runtime they serve.

The managed Eden service is still the right shape for teams that want a shared control plane. But it can't be the only shape. Infrastructure products need to meet workloads where they are.

#Why embedded Eden exists

The easy version of embedded mode is a demo.

You wire a few tables into SQLite, skip the hard paths, accept that local behavior is different from production, and call it good enough for evaluation. That wasn't good enough for Eden.

Embedded Eden exists for a more practical reason: some gateway deployments should be one binary, not multiple services. When the gateway needs to run next to a database, API, or AI endpoint, it shouldn't drag a separate Postgres deployment into that environment unless the operator wants one.

At the same time, Eden's value comes from the consistency of its governance model. Credentials, endpoint records, gateway keys, policy snapshots, identity state, route metadata, and audit-relevant state all need to behave predictably. An embedded Eden using a totally separate persistence model would drift from the managed product almost immediately.

We wanted embedded deployments to preserve the same core architecture:

the same service APIs
the same endpoint registry concepts
the same LLM credential model
the same gateway keys and policy records
the same organization and identity primitives
the same database method layer

The deployment shape should change. The product contract should not.

That meant embedded Eden needed a real local control-plane database, not just a development shortcut.

#Why Turso

We needed an embedded database that matched four constraints:

it had to run in-process
it had to work in a Rust service without a separate database daemon
it had to support durable local control-plane state
it had to encrypt file-backed deployments at rest

Plain SQLite gets close on the operational model, but it wasn't enough for our security and deployment goals. Eden stores sensitive control-plane state: provider credentials, endpoint records, gateway policy, agent metadata, route configuration, and local service state. That information shouldn't be sitting in a plaintext local database file.

Column-level encryption was possible, but fragile. Every new sensitive field would need to be classified correctly. Every migration would need to preserve the encryption boundary. Developers would need to know which helpers to call and which fields are safe to log. Even done right, the database file could still reveal schema shape, table names, row counts, and metadata.

Turso gave us the model we wanted: SQLite-compatible embedded storage, a Rust-native integration path, and AES-256-GCM database encryption for file-backed deployments.

That combination is what makes embedded Eden practical. The gateway can run close to the workload, and the control-plane state it needs can live beside it without becoming a plaintext credential store.

#What we built

The embedded deployment path starts in DatabaseManager::new_local.

When Eden runs with the embedded-db feature, Turso backs the control-plane database instead of Postgres. The service still initializes the same high-level database manager, but the Postgres slot is filled by a Turso-backed implementation.

At startup, Eden:

creates the parent directory for a file-backed local database
requires EDEN_DB_ENCRYPTION_KEY for file-backed embedded deployments
validates that the key is a 64-character hexadecimal value
enables Turso local encryption with AES-256-GCM
enables SQLite foreign-key enforcement
enables WAL mode for file-backed databases
sets synchronous=NORMAL as the durability/performance tradeoff
initializes the Eden schema through the embedded backend

The encryption setup is intentionally strict. When the deployment is file-backed and no encryption key is provided, Eden refuses to start.

The core looks like this:

let mut builder = turso::Builder::new_local(&effective_path);

builder = builder.experimental_encryption(true);
builder = builder.with_encryption(turso::EncryptionOpts {
    cipher: "aes256gcm".to_string(),
    hexkey: key.to_string(),
});

That gives embedded Eden a clean deployment shape: one service, local encrypted control-plane state, no external Postgres dependency.

For low-latency or on-prem gateway deployments, that matters. The gateway can be placed near the Redis cluster, database, private API, model endpoint, or tool server it governs. The local service can still persist configuration and credential state. The customer doesn't need to introduce another networked database dependency just to put Eden in the right place.

#Replacing Postgres without forking Eden

The hard part wasn't opening a Turso database.

The hard part was making embedded Eden use the same database method layer as the managed product.

Most of Eden's control-plane code was already written against a Postgres-shaped interface. The service expected a pool. Call sites expected methods like query_one, query_opt, query, execute, batch_execute, and transactions. SQL files used Postgres bind syntax, type casts, NOW(), conflict clauses, row-locking syntax, and aggregation patterns.

We didn't want to duplicate all of that logic for embedded mode.

So we built a compatibility layer:

TursoPool acts as the pool-equivalent for embedded deployments
TursoConnection exposes the method surface Eden expects from tokio_postgres::Client
transactions are wrapped with the same query and execute methods
result rows are normalized through Eden's shared row abstraction
SQL is rewritten at the connection layer before Turso sees it

That keeps existing Eden database call sites largely unchanged. The service asks for the database manager; the embedded backend handles the translation.

This is where Turso is especially useful. It gives us the operational simplicity of embedded storage while still being capable enough to host the control-plane state that Eden needs to run close to the workload.

#Making Postgres-shaped SQL run on Turso

The embedded backend rewrites Postgres-oriented SQL into SQLite/Turso-compatible SQL as close to the database boundary as possible.

Some examples:

$1, $2, and other Postgres bind parameters become ?1, ?2
NOW() becomes datetime('now')
FOR SHARE and FOR UPDATE row-level locks are stripped because SQLite doesn't implement them
INTERVAL arithmetic is translated into SQLite datetime modifiers
array_agg, json_agg, and related patterns become SQLite JSON aggregation
Postgres casts like ::uuid, ::jsonb, ::text, and sized casts are removed where SQLite doesn't need them
tuple comparisons are rewritten into equivalent boolean expressions
partial-index predicates in ON CONFLICT clauses are removed so SQLite can match the conflict target
ALTER TABLE ... ADD COLUMN IF NOT EXISTS is handled by checking table metadata first

This layer is deliberately scoped. We're not building a generic Postgres emulator. We're making Eden's own control-plane state portable enough to support embedded gateway deployments without creating a second product.

That's the architectural payoff: embedded Eden stays close to managed Eden, while Turso lets it run in the environments where gateways often need to live.

#Security at the gateway edge

Embedded deployments are often used in exactly the environments where security requirements are strongest.

An enterprise might want Eden inside a private VPC because model traffic can't traverse a public control plane. A healthcare or financial-services customer might want the gateway on-prem because data residency rules are strict. A team evaluating AI agents against internal systems might want every credential and endpoint record to stay local.

In those deployments, Eden's local database may contain sensitive control-plane state: provider credentials, endpoint records, policy configuration, gateway keys, user and agent metadata, and audit-relevant state.

The model shouldn't receive raw credentials. The local database shouldn't store them in plaintext. The service layer should remain responsible for resolving secrets, applying policy, and sending requests to the target system.

Turso helps us preserve that boundary in embedded mode.

Whole-database encryption means the file-backed control-plane database starts from a safer default. When the file is copied, synced, backed up, inspected, or accidentally exposed, the contents aren't readable without the key.

That doesn't replace the rest of Eden's security model. Eden still keeps credentials out of model-facing prompts and tool responses. It still injects authentication after the model composes a request. It still relies on the target system's own authorization for real enforcement.

But it gives embedded gateway deployments the storage baseline they need.

#Testing the guarantee

We added tests for the parts of this system where vague assurances aren't enough.

One test opens a file-backed Turso database with encryption enabled, then reads the database file directly from disk. The assertion is intentionally concrete: the file shouldn't have a plaintext SQLite header. In the encrypted Turso path, the file starts with Turso's encrypted file marker instead.

Another test reopens the same file-backed database with the same key and verifies that data persists across process lifetimes.

We also keep embedded-db database-method tests running against the Turso path. That matters because the embedded backend isn't just a storage convenience. It's a compatibility layer for Eden's control-plane behavior.

If Eden is going to run near customer databases, APIs, and AI endpoints, embedded mode has to be boring in the best possible way: encrypted, durable, predictable, and close to the production control-plane path.

#How Eden leverages it

The Turso-backed embedded deployment gives Eden a smaller runtime shape without changing the architectural center of gravity.

With embedded-db mode, Eden can run with local encrypted control-plane storage while still supporting the concepts the rest of the platform expects:

organizations and identity state
endpoint registration and metadata
LLM provider credentials
gateway API keys and policy snapshots
route and usage accounting foundations
agent and tool configuration
local development and evaluation workflows

The immediate value is deployment flexibility.

Eden can be placed next to a Redis deployment for low-latency gateway traffic. It can run inside an on-prem network where the database or API can't be exposed externally. It can sit beside internal model endpoints and tool servers so AI traffic stays inside the customer's boundary. It can be used for local evaluation without requiring a separate Postgres service.

Adam Local benefits from this, but it's not the whole story. Adam is one product surface on top of Eden. The more important point is that Eden itself can now run in a compact embedded deployment while preserving the same governance model.

#The bigger pattern

We chose Turso because it solved an immediate storage problem, but the larger value is architectural.

Eden is increasingly designed to run in multiple shapes:

managed deployments for teams that want a shared control plane
gateway/runtime deployments for production infrastructure paths
embedded deployments for low-latency, on-prem, private-network, and local environments

Those shapes should share as much of the same product architecture as possible.

Turso gives us a way to keep the embedded control plane close to the production control plane. The compatibility layer lets Eden keep a Postgres-shaped database interface while using encrypted embedded storage underneath. The file-backed encryption requirement gives us a responsible default for sensitive local state.

The first-order benefit is simple: Eden can run as a gateway close to the systems it protects without requiring an external Postgres service.

The second-order benefit is more important: Eden can keep the same governance and credential model across managed, gateway, and embedded deployments.

#Try it

The embedded deployment path is built into Eden's feature system. For a focused Redis gateway build with embedded control-plane storage:

cargo build -p eden-service --release --no-default-features \
  --features "redis embedded-db telemetry-export" --locked

For a file-backed embedded deployment, set a Turso path and encryption key before starting the service:

export EDEN_TURSO_PATH="./eden.local.db"
export EDEN_DB_ENCRYPTION_KEY="$(openssl rand -hex 32)"

From there, Eden initializes the encrypted local control-plane database, applies the schema, and runs without requiring a separate Postgres service.

This is still the beginning of the embedded story. We're continuing to improve first-run setup, local credential flows, OAuth handling, and persistent agent memory on top of the same encrypted foundation.

If you're building AI infrastructure that touches real systems, embedded mode shouldn't mean "less secure" or "less real." For us, Turso made a better answer possible: one encrypted local control plane, one Eden architecture, and a deployment shape that can run close to the database, API, or AI endpoint it governs.

Turso is an embedded SQL database built for local and distributed applications. Learn more at turso.tech or read the Turso docs.