--- title: Rotating Secrets for Vercel Marketplace Integrations description: Rotate the Supabase service role key, JWT secret, and database password from your Vercel integration, then apply the new values with a redeploy. url: "https://vercel.com/kb/guide/how-to-reset-the-secrets-of-your-supabase-integration" published: 2025-12-07 last_updated: 2026-09-02 authors: TMO install_vercel_plugin: npx plugins add vercel/vercel-plugin --- ## How to rotate the Supabase service role key and other Vercel integration secrets Rotating a credential means issuing a new one and retiring the old value, so anyone still holding the old secret loses access. When your Supabase database comes from the [Vercel Marketplace](https://vercel.com/marketplace/supabase), Vercel manages those credentials for you and keeps them in sync as environment variables across every linked project. Each deployment reads the values available when it was built, so a redeploy is what puts the new credential into service. Here's how to rotate each Supabase credential, apply the change in Vercel, and do the same for an Upstash resource. ## What is the Supabase service role key? Supabase issues several API keys per project, and they differ in the access they grant. The `service_role` key sits at the top of that range. A request that carries it runs as the `service_role` Postgres role, which holds the `BYPASSRLS` attribute and ignores every Row Level Security policy on your tables. A `service_role` request can therefore read and write any data in the project. Supabase is also moving off `service_role`. New projects use opaque publishable (`sb_publishable_...`) and secret (`sb_secret_...`) keys instead. Supabase has scheduled the [legacy pair](https://supabase.com/docs/guides/getting-started/api-keys) of `anon` and `service_role` for deprecation at the end of 2026. Because `service_role` ignores Row Level Security. It belongs only where you control the runtime. Three kinds of workload qualify: - **Backend services:** Servers, microservices, and admin tools that authenticate the caller before they reach Supabase. - **Scheduled work:** Cron jobs, queue workers, and event subscribers that run without a signed-in user. - **Data pipelines:** Analytics, reporting, backup, and synchronization jobs that read or write in bulk. Everywhere else is out of scope, including browser code, client bundles, and build artifacts. Anyone can read a key from those, which is why a `service_role` key committed to source control is worth rotating the moment you find it. ### When to rotate the Supabase service role key Rotate the service role key when any of these apply: - A team member with access to the credentials leaves. - You suspect the key has been exposed in source control, logs, or a client bundle. - Your security policy sets a fixed rotation interval. - You are moving off the legacy keys ahead of the 2026 deprecation. If you are still on the JSON Web Token (JWT) based `service_role` key, Supabase's guidance is to replace it with a new secret key rather than reissue it. That is the path this guide follows. ## What you need before you rotate Supabase integration secrets A rotation replaces a credential that live deployments depend on, so a pass you cannot finish leaves traffic broken. Confirm three things before you start: - **A native integration:** You provisioned the Supabase database from the Vercel Marketplace rather than adding its credentials by hand. - **Resource permissions:** You can manage your Vercel team's resources, including the Supabase integration. - **An inventory of consumers:** You know which Vercel projects, environments, and outside systems read the credentials. Order matters once you start. Create the new credential first, get it into Vercel, redeploy, and invalidate the old credential only after the new deployment is confirmed working. Reversing that order breaks running deployments. The same sequence applies to [rotating secrets](https://vercel.com/docs/environment-variables/rotating-secrets) held in environment variables. ## How to rotate the Supabase service role key Rotation happens in the Supabase dashboard, which you reach through the integration, so you land on the right project. ### Open Supabase from your Vercel integration Start from the Vercel side: 1. From your Vercel [dashboard](https://vercel.com/dashboard), select **Integrations** in the sidebar. 2. Next to the integration, select **Manage**. Native integrations appear with a billable badge. 3. Find and select the database whose secrets you want to rotate. 4. Select **Open in Supabase**. You now have the Supabase project that backs the Vercel resource. ### Create a new secret key and retire the old one Supabase rotates API keys by addition rather than by regeneration, so the old and new keys overlap while you migrate: 1. Go to **Project Settings**, then **API Keys**. 2. Select **New secret key**, enter a name, and select **Create API key**. 3. Copy the new value into every consumer of the old key, including your Vercel environment variables. 4. Redeploy the affected projects and confirm they work against the new key. 5. Return to **API Keys**, select the three dots next to the old key, and select **Delete the API key**, then enter the name to confirm. Deleting a secret key is permanent, so run step 4 before step 5. The legacy `anon` and `service_role` keys work differently. You disable them from the same **API Keys** screen rather than deleting them, and you can turn them back on if you find a consumer you missed. ## How to rotate the Supabase JWT secret Supabase signs every user access token with a separate key, so rotating an API key leaves user sessions untouched. Rotating the signing key is the part that can log people out. Which of Supabase's two signing systems your project uses decides whether that happens. The [legacy JWT secret](https://supabase.com/docs/guides/auth/signing-keys) is a single shared secret that signs all JWTs, including the `anon` and `service_role` keys. Changing it invalidates active sessions and forces every signed-in user to log in again. JWT signing keys replace that shared secret with an asymmetric key pair and let each rotation step happen independently, with no forced sign-outs. To move to signing keys and rotate without downtime: 1. Go to **Project Settings**, then **JWT Keys**. 2. Select **Migrate JWT secret** to import the existing secret into the signing keys system. Supabase creates a standby key alongside it. 3. Confirm your application verifies tokens with `supabase.auth.getClaims()` rather than checking every JWT against the legacy secret directly. 4. Select **Rotate keys** to start signing new access tokens with the standby key. Existing tokens stay valid until they expire. 5. Wait for your configured access token lifetime plus roughly 15 minutes, then revoke the previously used key. Supabase throttles most signing key state changes for about five minutes, so the sequence takes longer than the clicking suggests. Revoking the legacy secret has one prerequisite. The `anon` and `service_role` keys are themselves JWTs signed by that secret, so Supabase requires you to disable both before it will let you revoke it. If you need to change the legacy secret directly instead, that control stays under **Legacy JWT Secret** on the same screen, along with the forced sign-out it causes. ## How to rotate the Supabase database password The API keys and the signing key both control access through Supabase's API. Your Postgres password controls direct connections to the database, from a migration tool, a database client, or a `psql` session, and it rotates on its own path. To issue a new password: 1. Go to **Database**, then **Settings**. 2. Find the **Database password** section and select **Reset database password**. 3. Select **Generate a password**, then **Reset password**. 4. Update the connection string wherever your application stores it, then redeploy. Resetting the password terminates every open database connection, and your application loses database connectivity until it redeploys with the new value. Schedule this one for a window where a short interruption is acceptable. ## How to rotate your Upstash integration secrets Upstash gives you two kinds of credentials, and only one of them runs through the Vercel integration. Database tokens authenticate your application against a specific Redis database, queue, or index, and Vercel stores them as environment variables. The Upstash API key authenticates you against your whole Upstash account, and it lives outside Vercel entirely. ### Reset your Upstash database credentials To rotate the credentials that the integration wrote into your projects: 1. From your Vercel dashboard, select **Integrations** in the sidebar. 2. Next to the integration, select **Manage**, then find and select the database. 3. Select **Open in Upstash**. 4. In the Upstash console, scroll to **Reset Credentials** and select **Reset**. 5. Type your database name and select **Reset Password**. For a Redis database, this issues new values for `UPSTASH_REDIS_REST_TOKEN` and `UPSTASH_REDIS_PASSWORD`, and the old ones stop working at once. Vercel receives the new values and stages them for your linked projects, so redeploy before the reset reaches production traffic. The reset covers one resource. A team running Redis alongside QStash, Vector, or Search holds a separate token for each, and those tokens are unrelated. A Redis reset leaves a leaked QStash token live. Work through every resource on the integration page rather than treating one reset as an account-wide rotation. ### Rotate an Upstash API key The Upstash API key is a management credential for the Developer API and the Upstash CLI, and the Vercel integration neither stores nor rotates it. The [Developer API](https://upstash.com/docs/devops/developer-api/introduction) is also restricted to native Upstash accounts, so an account created through Vercel cannot create one. For a native Upstash account, rotate the key from the console: 1. In the left menu, select **Account**, then **Management API**. 2. Select **Create API Key** and enter a name that no existing key uses. 3. Copy or download the value immediately, because Upstash does not store it and cannot show it again. 4. Update your CLI configuration, build pipelines, and any automation that reads the old key. 5. Delete the old key from the **Account** > **API Keys** screen. One account can hold up to 37 API keys by default. That is enough to give each application its own key and retire them one at a time. ## How to apply rotated Supabase and Upstash secrets in Vercel Both providers stage new credentials back to your Vercel team, and a redeploy puts them into service. You have two ways to run the rotation from the Vercel side. The first starts the rotation in Vercel rather than the provider dashboard: 1. From your Vercel dashboard, select **Integrations** in the sidebar, then open the provider. 2. Under **Installed Products**, select the product for the resource you want to rotate. 3. In the sidebar, select **Settings**, then scroll to **Secure This Resource**. 4. Select **Rotate Secrets**, enter the rotation reason, and confirm by typing the project name. The second is a reset in the provider dashboard, after which Vercel picks up the new secrets for linked projects. Either way, finish with a redeploy: 1. From your Vercel dashboard, select your project. 2. Go to the **Deployments** tab. 3. Find your latest production deployment. 4. Select the three dots, then select **Redeploy**. Redeploy your preview and development deployments as well if they read the same resource, since environment variable changes only reach new deployments. An older deployment you visit by URL keeps using the credential it was built with, and it will start failing once you invalidate that credential. ## How to rotate secrets for other Vercel integrations Every native integration rotates the same way. You open the provider from **Integrations**, rotate the credentials there or through **Rotate Secrets** in Vercel, and redeploy the linked projects. Provider-specific steps are covered in their own guides: - [How to rotate the secrets of your Neon integration](https://vercel.com/kb/guide/how-to-reset-a-secret-for-a-neon-integration) - [How to rotate the secrets of your Redis integration](https://vercel.com/kb/guide/how-to-reset-the-secret-for-your-redis-integration) - [How to rotate the secrets of your Hypertune integration](https://vercel.com/kb/guide/how-to-reset-the-secrets-of-your-hypertune-integration) For credentials you added to Vercel by hand rather than through an integration, you own the rotation end-to-end. The guide to [rotating environment variables](https://vercel.com/docs/environment-variables/rotating-secrets) covers the project-level and team-level cases. ## Next steps With the credential rotated and your deployments running on the new value, mark the old key as retired in whatever inventory you keep. [Start a new Vercel project](https://vercel.com/new) with the integration already connected, or [browse the Vercel Marketplace](https://vercel.com/marketplace) to see which providers support native secret rotation. ## Related resources - [Rotating environment variables](https://vercel.com/docs/environment-variables/rotating-secrets) - [Integrations](https://vercel.com/docs/integrations) - [Secure your resource](https://vercel.com/docs/integrations/install-an-integration/secure-your-resource) - [Sensitive environment variables](https://vercel.com/docs/environment-variables/sensitive-environment-variables) - [How to add and manage environment variables on Vercel](https://vercel.com/kb/guide/how-to-add-vercel-environment-variables) ## Frequently asked questions ### What is the difference between rotating and resetting a Supabase key? Resetting regenerates a credential in place, so the old value stops working the moment the new one exists. Rotating creates a second credential, moves your consumers onto it, and retires the first afterward. Supabase secret keys and JWT signing keys support rotation, while the database password and legacy JWT secret are reset. ### What should I do if my Supabase service role key is exposed? Remediate the exposure first, such as removing the key from source control or fixing the bundle that leaked it. Then create a new Supabase secret key, update every consumer, including your Vercel environment variables, redeploy, and confirm traffic works. Delete the exposed key last, since deletion is permanent. ### Does rotating the Supabase service role key sign users out? No. API key rotation and user sessions are separate. Creating a secret key and deleting the old one affects server-side callers only. Sessions break when you change the legacy JWT secret, because that secret signs user access tokens. Migrating to JWT signing keys avoids the forced sign-out entirely. ### Where do I find the Upstash API key? The Upstash API key lives under **Account** > **Management API** in the Upstash console, separate from the database tokens the Vercel integration manages. Upstash shows the value once and does not store it. Accounts created through Vercel or another third-party platform cannot use the Developer API. ### Do I need to redeploy after rotating a Vercel Supabase integration secret? Yes. Vercel applies environment variable changes to new deployments only, so your running production deployment keeps the old credentials until you redeploy it. Redeploy every environment that reads the resource, including preview and development, before you invalidate the previous secret.