Aurabase Logo
aurabasedocs
docs›Services›Vault

Vault

Field-level encryption for sensitive Aurabase data. AES-256-GCM with record-derived key (HKDF-SHA256), or HashiCorp Vault transit backend in production — the same primitive protects your Edge Functions secrets and internal platform secrets.

6 min read·Level intermediate·Revised on Aug 15, 2026
This English text was generated automatically from the French original and has not been reviewed yet.
#
Overview

An encryption service, not a separate product

“Vault” is not a separate HTTP service on the gateway: it is a field-level encryption engine that automatically protects your sensitive data before writing to the database — MFA secrets, OAuth provider tokens, project connection strings, and the secrets of your Edge Functions.

What you actually manipulate, as a developer, are the secrets per function: key/value pairs defined via the CLI or the REST API, injected as environment variables into the worker that executes your function.

Info

The name “Vault” also refers to the HashiCorp Vault infrastructure product, deployed in production as an optional backend of this service (management of the root encryption key, rotation, Postgres credentials with a limited lifespan). The two meanings coexist: the application primitive documented here, and the infrastructure tool that can support it.

#
Mental model

Two backends, one reading format

On write, the service chooses a backend: Vault transit if configured (preferred — the root encryption key never leaves Vault), otherwise a fallback AES-256-GCM local with a key derived by registration via HKDF-SHA256. When read, the format of the ciphertext indicates which backend produced it — no forced migration is needed to switch from one to the other.

ciphertext formattext
vault:v1:AbCdEf...     # backend transit — decrypted via Vault (KEK never exposed)
{"key_id":"v1",         # local AES-256-GCM backend (fallback/dev)
 "nonce":"…","data":"…"}
sk_live_51J2x...       # unencrypted historical value (before encryption activation)
Astuce

The derivation context (functions side) is project_id:function_name — the same secret encrypted twice for two functions produces two different ciphertexts, and removing/renaming the function makes the old ciphertext unreadable by construction.

#
Primitives

What the service provides

AES-256-GCM

32-byte key derived by registration via HKDF-SHA256 (context = project_id:function_name). 96-bit nonce per write.

§ local encryption

Backend Vault transit

In production, the KEK never leaves Vault: encryption/decryption delegated to transit/encrypt|decrypt, versioned ciphertext vault:vN:....

§ production backend

Seamless migration

Decryption detects stored format (vault: → transit, {...} → local AES, plain text → unencrypted history): backend failover without forced rewriting.

§ dual-read

Scope by Function

The application secrets documented here are scoped to a function (project_id + name), injected to the Deno worker via Deno.env.get('CLE').

§ scope

Dedicated CLI

aura secrets list/set/unset --function <name>. The values ​​are never re-displayed in plain text by list.

§cli

Reused by the platform

The same encryption service also protects, on the server side, MFA secrets, OAuth tokens and connection strings (db_url_encrypted, anon_key_encrypted).

§ platform

#
Examples

Three ways of writing, one way of reading

functions/echo.tstypescript
// Once written (CLI or REST), the secret is injected as a variable
// environment of the worker who executes the function.
Deno.serve(async (req) => {
  const cle = Deno.env.get('STRIPE_SECRET_KEY')
  // ...
})
Astuce

The CLI (aura secrets) and the dedicated REST endpoint (/env) manipulate the same data — the secrets of a function — but not necessarily through the same write path. See point of attention below.

#
Point of attention

Encryption depends on the write path taken

aura-functions exposes two ways to modify the environment variables of a function: the dedicated PUT /v1/functions/:projectId/:nom/env endpoint (which systematically encrypts via EncryptionService before writing), and the generic PATCH /v1/functions/:projectId/:nom endpoint used to update an entire function — code, runtime, env_vars included — without going through this encryption.

Encrypting environment variables

Environment variables configured via /env are encrypted at rest via AES-256-GCM before being stored. In local development as well as in managed production, this encryption is performed transparently for the developer.

Last updated · Aug 15, 2026