Secrets are the surface where migrations most often break — and where automation should be the most careful. This guide covers why source secret values cannot be exported and how teams should safely set up destination secrets.
Why secrets are protected
Secret values give whoever holds them the ability to act as your app. Platforms deliberately do not expose them for read after they are set, so a leak cannot become a full compromise.
Secret names versus secret values
Secret names — like STRIPE_SECRET_KEY or RESEND_API_KEY — can be inspected. Secret values cannot. A migration tool can help with the names and let the team supply the values.
Why source secret values cannot be exported
Source platforms treat secret values as write-only after creation. This is a security feature: the platform itself cannot show them back to a caller, so no external tool can export them either.
Destination secret setup
Teams supply destination secret values during setup. Miglify can detect required secret names and lets users provide destination values during setup. Supabase Management Access Tokens and secret values are not stored.
One-time Supabase Management Access Token
Applying secrets on the destination uses a Supabase Management Access Token supplied only for that operation. The token is used to make the API call and then discarded.
Why tokens and secret values should not be stored
Storing tokens or secret values creates a persistent risk that is disproportionate to the one-time setup task. Treat them as one-shot inputs, not saved credentials.
Manual setup confirmation
After the destination secrets are set, confirm each one with a targeted call — a small test invocation, a signed webhook, or a checkout in test mode. Confirmation is what turns "we set it" into "it works."
Common secret types
Supabase keys
Publishable, anon, and service role — each with different scopes.
API keys
Third-party SaaS keys — email, analytics, error reporting, feature flags.
OAuth credentials
Client IDs, client secrets, and redirect URIs for every provider.
Webhook secrets
Signing secrets for verifying incoming webhooks from third parties.
Payment provider keys
Stripe, Paddle, or other providers — usually with separate test and live keys.
How Miglify helps
Miglify detects the required secret names from the source project, prompts for destination values at setup time, and applies them via the Management API when the user provides a token. Neither the token nor the secret values are retained. See also the Secrets and Environment Variables Migration and Edge Functions Migration guides.
Final thoughts
Treat secrets as a manual step with automated assistance, not as data to be copied. That framing keeps migrations safe and destinations clean.
Miglify keeps every step observable — analyze source, validate destination, and prepare rollback-aware runs before you cut over.