**TL;DR:** Write attempts with the read-only token fail, and SCAN and KEYS are blocked even though they are reads. Confirm Run the same command with the standard token. Fix - Writes from client code: move them server side behind your API, which holds the standard token. - Key enumeration: redesign so clients always know exact keys.

## The fix

# Upstash read-only token -  writes fail, and so do SCAN and KEYS

## What you see

Write commands (SET, DEL, INCR, ...) return permission errors when
authenticated with the read-only token. SCAN and KEYS also fail, which
surprises people because they are reads.

## Why

The read-only token is meant for untrusted environments (browsers,
phones). SCAN and KEYS can enumerate the whole keyspace, so they are
blocked to keep a leaked read-only token from becoming a data
exfiltration tool.

## Confirm

Run the same command with the standard token. If it succeeds, the
token scope is the issue, not the command.

## Fix

- Writes from client code: move them server side behind your API,
  which holds the standard token.
- Key enumeration: redesign so clients always know exact keys. Use
  known key patterns (user:42:cart) instead of scanning.
- If you genuinely need SCAN from a client, you are holding the wrong
  token -  that operation belongs server side.

## Verify

Reads with the read-only token succeed, writes fail closed, and no
client code path depends on SCAN or KEYS.

## When to use this

- This covers exactly what the title says: Upstash read-only token blocks writes, and also blocks SCAN and KEYS.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Upstash; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Upstash behavior.