# Using Upstash on Vercel? Rotate Your Secrets After Vercel's April 2026 Incident

> **Source:** https://upstash.com/blog/rotate-upstash-secrets-after-vercel-incident
> **Date:** 2026-04-19
> **Author(s):** Ilter Kavlak
> **Reading time:** 6 min read
> **Tags:** vercel, redis, qstash, vector, search, security
> **Format:** text/markdown — machine-readable content for agents and LLMs

What Vercel disclosed on April 19, 2026, and how Upstash customers should rotate Redis, QStash, Vector, and Search credentials.

---

On **April 19, 2026**, Vercel published a [security bulletin](https://vercel.com/kb/bulletin/vercel-april-2026-security-incident) saying it had identified "unauthorized access to certain internal Vercel systems" and that a **limited subset of customers** had been identified and contacted directly.

Vercel also recommended that customers **review activity logs** and **rotate environment variables**.

If you use **Upstash with Vercel**, that advice applies to your Upstash credentials too.

## What happened

As of **April 19, 2026**, Vercel's public bulletin says:

- there was unauthorized access to certain internal Vercel systems
- services remained operational
- a limited subset of customers had been identified and contacted directly
- all customers should review activity logs and rotate environment variables

That means the safest assumption for Upstash users on Vercel is simple:

**If an Upstash credential existed in Vercel env vars, rotate it.**

## Which Upstash secrets you should rotate

Start with every Upstash credential currently or previously stored in Vercel:

- Redis:
  `UPSTASH_REDIS_REST_TOKEN`, `UPSTASH_REDIS_PASSWORD`, and any custom ACL passwords
- QStash:
  `QSTASH_TOKEN`, `QSTASH_CURRENT_SIGNING_KEY`, `QSTASH_NEXT_SIGNING_KEY`
- Vector:
  `UPSTASH_VECTOR_REST_TOKEN`
- Search:
  `UPSTASH_SEARCH_REST_TOKEN`
- Any internal service-to-service secrets copied from Upstash into Vercel projects, preview deployments, CI jobs, or local `.env` files synced from Vercel

## If you use Upstash via the Vercel integration

This is the simplest case because Vercel and Upstash already have a documented recovery flow for integration-managed credentials.

Vercel's recovery flow is:

1. Open **Vercel Dashboard** → **Integrations**
2. Find **Upstash** and click **Manage**
3. Select the affected resource
4. Click **Open in Upstash**
5. In Upstash, use **Reset Credentials** / **Reset Password**
6. Go back to Vercel and **redeploy**

Important detail: in this setup, **resetting the credential in Upstash is not enough by itself**. You still need to make sure the new values are propagated to the Vercel project and that affected deployments are redeployed. Vercel documents that recovery flow in its guide on [rotating Upstash integration secrets](https://vercel.com/kb/guide/how-to-reset-the-secrets-of-your-upstash-integration).

After that, review older environments too:

- production
- preview
- development
- any older linked Vercel projects that still reference the same Upstash resource

## If you created Upstash manually and added env vars to Vercel yourself

This case is different.

If you created your Redis database, QStash token, Vector index, or Search index directly in **Upstash**, then copied the credentials into **Vercel environment variables manually**, Vercel cannot rotate them for you.

You need to rotate them from the **Upstash side first**, then update Vercel manually.

The safe sequence is:

1. Identify every Vercel project and environment that contains Upstash secrets.
2. Reset or regenerate the credential in Upstash.
3. Replace the old value in Vercel env vars.
4. Redeploy every affected project.
5. Remove stale copies from local `.env` files, CI systems, and secret managers that were seeded from Vercel.

This setup tends to be riskier during incidents because the same token is often copied into:

- multiple Vercel projects
- preview environments
- GitHub Actions or other CI jobs
- developer machines
- incident notebooks, shell history, or internal docs

So for manually managed secrets, you should assume the cleanup surface is broader than just one Vercel project. After rotation, verify the old secret is no longer accepted anywhere.

## Product-specific advanced recommendations

If you want to go beyond immediate rotation, the exact hardening step depends on which Upstash product you use.

### 1. Redis: use the read-only token where writes are not needed

Upstash documents in its [Redis security guide](https://upstash.com/docs/redis/features/security) that the **standard token has full privilege** and should not be exposed publicly. If you have read-only consumers, switch them to the [read-only token](https://upstash.com/docs/redis/troubleshooting/readonly_connection) instead.

### 2. Redis: create ACL users per service

Redis [ACL](https://upstash.com/docs/redis/features/security) lets you stop treating one password as the key to everything.

For example, you can create a dedicated read-only user:

```text
ACL SETUSER myreadonlyuser on >somesecurepassword ~* &* +@read -@dangerous
```

And if you need REST access for that ACL user, generate a [REST token for the ACL user](https://upstash.com/docs/redis/features/restapi) with:

```text
ACL RESTTOKEN myreadonlyuser somesecurepassword
```

That gives you a token with the same permissions as that ACL user, which is much safer than reusing the default full-access credential across multiple apps.

You can narrow access even further by restricting keys, for example `~cache:*` instead of `~*`.

### 3. Redis: enable Credential Protection

If you are on **Prod Pack**, enable [Credential Protection](https://upstash.com/docs/redis/features/credential-protection). With this feature, Upstash does not store your Redis database credentials and shows them only once when generated.

That does not replace rotation, but it does reduce future exposure.

### QStash customers: rotate the token and review signing keys

If you use **QStash** from Vercel:

1. Reset your `QSTASH_TOKEN`
2. Update the token in Vercel
3. Redeploy every project using it

If your app verifies incoming QStash webhooks, also review your [signing keys](https://upstash.com/docs/qstash/howto/roll-signing-keys):

- `QSTASH_CURRENT_SIGNING_KEY`
- `QSTASH_NEXT_SIGNING_KEY`

Upstash supports [rolling signing keys](https://upstash.com/docs/qstash/howto/roll-signing-keys) without downtime, but there is one operational detail that matters:

**Do not roll the keys twice before your applications have been updated**, or your requests may start failing [signature validation](https://upstash.com/docs/qstash/howto/signature). If you need to rotate the main credential itself, start with the [QStash token reset flow](https://upstash.com/docs/qstash/howto/reset-token).

### Vector and Search customers: rotate index tokens too

If you use **Upstash Vector** or **Upstash Search** from Vercel, rotate those credentials as well.

Upstash provides reset endpoints for both:

- Vector: resetting the index password rotates the **regular and readonly tokens**. See [Reset Vector index passwords](https://upstash.com/docs/devops/developer-api/vector/reset_index_passwords).
- Search: resetting the index password rotates the **regular and readonly tokens**. See [Reset Search index passwords](https://upstash.com/docs/api-reference/search/reset-password).

## Setup-based checklist

Choose the path that matches how you connected Upstash.

### Vercel integration users

1. Check Vercel's activity logs and identify affected projects.
2. Open the Upstash integration in Vercel.
3. Reset the credentials in Upstash through the documented flow.
4. Confirm the new values are present in Vercel.
5. Redeploy production, preview, and development deployments.

### Manual env var users

1. Inventory every Upstash secret copied into Vercel.
2. Rotate each credential in Upstash directly.
3. Replace every old Vercel env var manually.
4. Redeploy all affected projects.
5. Remove stale copies from local `.env` files, CI, and any shared internal docs.