Supabase Vault + Edge Functions: Secrets Without Env Sprawl
Stop hardcoding API keys. This Supabase Vault tutorial stores third-party secrets encrypted in Postgres and calls them from edge functions — no env sprawl.
Last updated: 2026-10-10 Your .env file is not a secrets strategy. It gets committed by accident, screenshared by accident, and copied into every new service until nobody knows which key lives where — that is env sprawl, and it is how API keys end up in git history. Here is the contrarian take: for Supabase apps, the best place for third-party secrets is not another environment variable. It is Supabase Vault — secrets encrypted with AES-256 inside Postgres itself, readable from SQL, from pg_net , and from edge functions, with per-user keys and rotation that never requires a redeploy. This tutorial stores real API keys in Vault and calls them from edge functions, end to end. New to the stack? Our complete Flutter and Supabase guide covers setup. If the edge function side is new to you, our Dart edge functions guide covers the runtime; here we focus on the secrets. What you'll learn What Supabase Vault is and why it beats env vars for third-party secrets How to store a third-party API key with vault.create_secret The per-user API key pattern ( provider_key_{userId} ) for multi-tenant secrets When to use Vault vs Edge Function secrets vs plain env vars How to read Vault secrets from an edge function without leaking them How to sign outbound calls at call time with pg_net and Vault The four mistakes that leak secrets despite Vault Your .env file is not a secrets strategy Count the copies of your Stripe secret key right now: the .env on your laptop, the one on your teammate's laptop, the dashboard secrets for each edge function, the CI variables, the staging copies. Every copy is a place it can leak, and rotation means hunting all of them down. Environment variables were designed for configuration, not for secrets — they have no encryption at rest guarantees you…