Secrets vault

Why a vault at all

Most apps end up needing a credential they cannot expose. To charge a card you need your Stripe secret key. To send a transactional email you need a Resend key. To send an SMS you need a Twilio token; to synthesize speech, an ElevenLabs key. None of these can ship to the browser — anyone who opens dev tools would have them, and could spend your money or send mail as you.

The vault solves this by giving each private key a home on the server. You store it once, your server-side code reads it at run time, and it never crosses the wire to the client. That's the whole idea: the value lives in exactly one place the browser can't see.

How it works

Each secret is stored under an env-var-style NAME (uppercase letters, digits, and underscores — for example STRIPE_SECRET_KEY) and a value. The value is encrypted at rest with AES-256-GCM. The encryption master key lives in the server environment, not in the database, which has two consequences worth internalizing:

• A database dump alone can't reveal your secrets — the ciphertext is useless without the master key, and the master key isn't in the database.
• Tampered ciphertext fails authentication — GCM carries an authentication tag, so a modified value won't decrypt; it errors instead of silently returning garbage.

Setting secrets

Secrets are managed from the Cloud console — owner only — at lingcode.dev/backends.html → your backend → Secrets. From there you can add, update, and delete secrets.

One thing to expect: listing shows the names only. Values are never returned once stored — you can overwrite a secret, but you cannot read it back. If you forget what a value was, set it again rather than trying to recover it.

Under the hood these are owner-authenticated endpoints, in case you script against them:

GET    /api/cloud/account/backends/<backend-id>/secrets          # list NAMES only
PUT    /api/cloud/account/backends/<backend-id>/secrets/<KEY>    # add or update
DELETE /api/cloud/account/backends/<backend-id>/secrets/<KEY>    # delete

# PUT body:
{ "value": "sk_live_..." }

Reading secrets from functions

Setting a secret is only half the story — the point is to use it. Secrets are read server-side from functions, and never anywhere else. There are three ways that plays out.

Builtins

Each builtin declares which secret names it needs, then reads them server-side when you invoke it. You set the secret, then call the builtin — you never pass the key yourself. For example:

• stripe-checkout needs STRIPE_SECRET_KEY
• resend-byo needs RESEND_API_KEY
• elevenlabs-tts needs ELEVENLABS_API_KEY
• twilio-sms needs TWILIO_ACCOUNT_SID and TWILIO_AUTH_TOKEN

So the end-to-end loop for taking a payment is: set STRIPE_SECRET_KEY in the console, then invoke the stripe-checkout builtin. The builtin reads the secret on the server; your client only ever sees the checkout URL it returns.

Custom functions

If you write your own custom function, the secrets arrive on the handler's context as ctx.secrets:

export default async function handler(input, ctx) {
  const key = ctx.secrets.STRIPE_SECRET_KEY;
  // call the vendor API with key …
  return { ok: true };
}

Same model as the builtins, just hand-written: you set STRIPE_SECRET_KEY in the console, and it shows up as ctx.secrets.STRIPE_SECRET_KEY when the function runs on the server. The value never leaves the sandbox.

The http-fetch builtin

The http-fetch builtin can interpolate a secret into request headers or body using the {{SECRET_NAME}} placeholder syntax. That lets you call an arbitrary allow-listed API with an authenticated request — without writing a custom function at all:

{
  "url": "https://api.example.com/v1/things",
  "method": "GET",
  "headers": {
    "Authorization": "Bearer {{EXAMPLE_API_KEY}}"
  }
}

The {{EXAMPLE_API_KEY}} placeholder is replaced server-side with the secret's value before the request goes out. The browser sends the request shape, never the key.