Rotating Secrets for Vercel Marketplace Integrations

Copy link to headingHow 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, 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.

Copy link to headingWhat 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 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.

Copy link to headingWhen 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.

Copy link to headingWhat 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 held in environment variables.

Copy link to headingHow 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.

Copy link to headingOpen Supabase from your Vercel integration

Start from the Vercel side:

From your Vercel dashboard, select Integrations in the sidebar.
Next to the integration, select Manage. Native integrations appear with a billable badge.
Find and select the database whose secrets you want to rotate.
Select Open in Supabase.

You now have the Supabase project that backs the Vercel resource.

Copy link to headingCreate 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:

Go to Project Settings, then API Keys.
Select New secret key, enter a name, and select Create API key.
Copy the new value into every consumer of the old key, including your Vercel environment variables.
Redeploy the affected projects and confirm they work against the new key.
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.

Copy link to headingHow 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 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:

Go to Project Settings, then JWT Keys.
Select Migrate JWT secret to import the existing secret into the signing keys system. Supabase creates a standby key alongside it.
Confirm your application verifies tokens with supabase.auth.getClaims() rather than checking every JWT against the legacy secret directly.
Select Rotate keys to start signing new access tokens with the standby key. Existing tokens stay valid until they expire.
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.

Copy link to headingHow 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:

Go to Database, then Settings.
Find the Database password section and select Reset database password.
Select Generate a password, then Reset password.
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.

Copy link to headingHow 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.

Copy link to headingReset your Upstash database credentials

To rotate the credentials that the integration wrote into your projects:

From your Vercel dashboard, select Integrations in the sidebar.
Next to the integration, select Manage, then find and select the database.
Select Open in Upstash.
In the Upstash console, scroll to Reset Credentials and select Reset.
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.

Copy link to headingRotate 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 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:

In the left menu, select Account, then Management API.
Select Create API Key and enter a name that no existing key uses.
Copy or download the value immediately, because Upstash does not store it and cannot show it again.
Update your CLI configuration, build pipelines, and any automation that reads the old key.
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.

Copy link to headingHow 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:

From your Vercel dashboard, select Integrations in the sidebar, then open the provider.
Under Installed Products, select the product for the resource you want to rotate.
In the sidebar, select Settings, then scroll to Secure This Resource.
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:

From your Vercel dashboard, select your project.
Go to the Deployments tab.
Find your latest production deployment.
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.

Copy link to headingHow 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:

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 covers the project-level and team-level cases.

Copy link to headingNext 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 with the integration already connected, or browse the Vercel Marketplace to see which providers support native secret rotation.

Copy link to headingFrequently asked questions

Copy link to headingWhat 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.

Copy link to headingWhat 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.

Copy link to headingDoes 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.

Copy link to headingWhere 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.

Copy link to headingDo 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.