Stop pasting database passwords into notebooks.
tresor gives every DuckDB user one sign-in through your identity provider, then hands DuckDB exactly the credentials their role allows. Rotate or revoke a secret once, centrally, and every analyst and application gets the change.
The extension is open source and installs from the DuckDB community repository. tresor-server is free in production, embedding included.
DuckDB is everywhere in your company. So are its credentials.
One sign-in. The right secrets. Nothing to paste.
Your identity provider
People sign in once through Keycloak, Okta, Entra ID or any OIDC provider, in the browser or with a device code. Single sign-on through the OS keychain.
Secrets by role
Administrators grant secrets to roles. Each user sees only what their roles allow, and the secrets join DuckDB’s own lookup for S3, Azure, databases and more.
Rotate and revoke centrally
Change a secret once, or reference it where it already lives, in Azure Key Vault, AWS or GCP Secret Manager, Vault or a Kubernetes Secret, so a rotation reaches DuckDB immediately. Remove a grant and access stops.
Applications too
Services that embed DuckDB sign in with managed identities, keys or federated tokens and receive the same role-based secrets. Any parameter can be generated for each caller when it is read: a token from your identity provider, or a session the server gets by logging in to a service. Generated secrets carry their expiry, and S3 credentials refresh by themselves.
Managed in SQL
Store a secret with CREATE PERSISTENT SECRET … IN corp and grant it from DuckDB, the CLI or the admin console. Variables share a bucket, an endpoint or a path with a role the same way.
Every lookup recorded
Logins, secret lookups and grants go to DuckDB’s log and to OpenTelemetry, so your monitoring shows who used which secret.
People, pipelines and servers. One way to get secrets.
Everyone signs in with their own identity, and what they may use is a grant you can read and revoke.
Analysts
Sign in once with your company account, in the browser or with a device code over SSH. Your secrets are there, and DuckDB picks the right one by path.
Pipelines and CI
ETL jobs, dbt runs and scheduled notebooks log in as a service, never as a person: Kubernetes service accounts, GitHub Actions OIDC, Azure managed identity or a key on the machine. Mostly no shared secret to store.
Administrators
Store a secret once, or a reference to your vault, and grant it to a role. Revoke it the same way. Only administrators place secrets where lookups find them.
Servers that act for users
A DuckDB server behind a gateway acts for each signed-in user. Every user gets exactly their own secrets, never the server’s, and the audit names the person. Which servers may act for users is set by name or by role.
Web applications too: tresor runs in DuckDB-wasm 2.0 and attaches as the user signed in to the application. It is ready for the day DuckDB publishes DuckDB-wasm 2.0 on npm. How it works
Built for Azure tenants.
People sign in with their Entra accounts, and your MFA and device policies apply. App roles and groups become tresor roles. Jobs and servers authenticate with managed identities or federated credentials, so no secret is stored.
- App roles such as analysts or secrets_admin map straight to tresor roles
- Managed identities for VMs, App Service, Functions and Container Apps
- On-Behalf-Of: a server acts for a user, and access is attributed to that person
- “Assignment required” limits who can get a token at all
An open standard, and a production server for it.
The extension speaks an open protocol. Anything that implements it can sit behind DuckDB. tresor-server is our implementation for organisations.
tresor and duckdb-secrets/1
The DuckDB extension and the open specification of the secrets service behind it. Build your own server if you want: a conformance suite tells you when it is right.
- DuckDB extension, free for everyone
- Open, documented protocol: no lock-in
- Conformance suite for any implementation
tresor-server
The production implementation: encrypted state, your key management, no passwords of its own. The conformance suite runs against it in CI on every state store.
- Free in production, embedding included
- Container image, Helm chart, recipes for Azure Container Apps, AWS ECS and GCP Cloud Run
- Admin console, token exchange, observability
Up and running in an afternoon.
Deploy tresor-server
One container or the Helm chart. Connect your identity provider and a key in Azure Key Vault, AWS KMS, GCP Cloud KMS or OpenBao and Vault.
Store and grant
Administrators add secrets, or references to values in your vault, and grant them to roles.
Attach and work
Analysts and applications run one ATTACH. From then on, DuckDB finds the right secret by itself.
Built so that nobody holds a master password.
Your key, your KMS
Secrets are sealed under a key in Azure Key Vault or Managed HSM, AWS KMS, GCP Cloud KMS, or OpenBao and Vault Transit. Only wrapped data keys are stored.
Values can stay where they are
Reference a secret in Azure Key Vault, AWS or GCP Secret Manager, Vault KV or a Kubernetes Secret instead of copying it. It is read at each fetch, only from sources you allow.
No passwords of its own
tresor-server runs with a managed or workload identity and signs in to its database and key service with Entra ID or IAM.
Your choice of state
SQLite for one replica, PostgreSQL or SQL Server for several, or custom resources in your Kubernetes namespace.
Users cannot plant secrets
Users only use what they are granted; their own secrets stay local. Admin rights do not include use: an administrator needs a grant like anyone else.
Audit without leaks
Every login, lookup, write and grant is an event, with the caller and the outcome. Events never contain secret material, tokens or statement text.
Run it yourself, or let us run it in your cloud.
The extension and the protocol are always free. For tresor-server you choose who operates it.
Self-hosted
Available nowRun tresor-server yourself, in production too, or build it into your product. A commercial licence is needed only to sell access to it in the cloud, on its own or as part of your product.
- Container image and Helm chart for Kubernetes
- Recipes for Azure Container Apps, AWS ECS and GCP Cloud Run
- Azure, AWS, GCP, OpenBao or Vault for keys and references
- Community support on GitHub
Managed in your cloud
From November 2026We install, update and monitor tresor-server inside your Azure tenant. Your secrets and keys never leave it.
- Set up with your identity provider and Key Vault
- Updates and security patches
- Support with agreed response times
- Open Telekom Cloud and STACKIT to follow
tresor-server is source-available under the Business Source License 1.1. Selling access to it in the cloud, as a hosted or managed service on its own or as part of another product, needs a commercial licence; talk to us. Each version becomes Apache-2.0 four years after its release.
Before you roll it out
Does tresor replace our vault?
No. tresor is how DuckDB gets secrets. tresor-server encrypts them with your key management, or reads them where they already are: Azure Key Vault, AWS or GCP Secret Manager, Vault or Kubernetes Secrets.
Can we build our own server?
Yes. duckdb-secrets/1 is an open protocol, and tresor’s conformance suite checks any implementation. tresor-server is the one we build and support.
Which identity providers work?
Any OIDC provider: Keycloak, Okta, Entra ID and others. Services can use managed identities, keys or federated tokens.
What does it cost?
The extension and the protocol are free under MIT. tresor-server is free in production, embedding included; selling access to it in the cloud, on its own or as part of your product, needs a commercial licence. The managed service is a subscription from November 2026.
Which DuckDB versions are supported?
DuckDB 2.0.0, with tresor 0.1.1. Each new DuckDB release gets a build.
Give your analysts one sign-in instead of ten passwords.
Start with the docs, or tell us about your setup and we will plan the rollout with you.