Anyone who has shipped something quickly knows how it goes. The key goes into an environment variable because it has to work today. Then it stays there.
And one day it turns up in a log, in a copy of the environment, or on the screen of somebody who shared their terminal.
Fact
The facts: on 18 August 2026 Vercel announced KMS, a key management service. It allows signing of JWT tokens and arbitrary messages straight from a function, with the private key staying inside the service. The function authenticates with its own OIDC token. RSA, ECDSA and EdDSA keys are supported, with creation and rotation from the command line and the dashboard. Signing access is granted per project and per environment, including production, preview and development. You can constrain which claims a given project may request and validate them against a schema. Each issuer publishes a standard discovery document and a public key set, so verification works with an ordinary library.
Why this is more than convenience
A key that is not in your code cannot leak from your code. It is that simple, and that is exactly why it works.
The second part I like more: the constraint on what a given project may request. So even if somebody does manage to sign, they can only sign certain things for a certain environment.
The best secret is the one your application has never seen.
There is a caveat, of course. The key is no longer with you, it is with a provider. You trade the risk of a leak for the risk of a dependency. For most teams the trade is worth it, but it is a trade, not a gift.
If you are on Vercel and rolling your own signing, go and look at it. If you are not, the idea is free to steal: let the key live in one place that your code only ever asks, without seeing.
Official primary sources
Vercel: Sign JWTs from your Functions without managing private keys (18.08.2026)The visual is generated code-art, no third-party images.