What the Vercel connector is
The connector writes an environment’s keys into a Vercel project’s environment variables, so a build and a deployment read them with no one pasting a value into a settings page.
It runs when you change something. Save a key in a connected environment and the push is owed from that moment; a worker performs it a few seconds later.
A token, a project, a target
A Vercel environment variable belongs to a project and to at least one of three targets, which is what a kyvlt.sh environment lines up with. The rest is said once, above it:
- The organisation connects one Vercel account or team — by installing this deployment’s integration on Vercel, or by an access token where the deployment has registered none.
- A project is aligned to a Vercel project, once. Every environment under it inherits that.
- An environment names one target —
production,previewordevelopment— and whether all of its keys travel or only some collections.
Sensitive, not encrypted
Vercel stores a variable under a type, and the type decides who can read it back afterwards:
| Type | Who can read the value afterwards |
| --- | --- |
| plain | Anybody with access to the project |
| encrypted | Anybody with access, through the API |
| sensitive | Nobody, including kyvlt.sh |
kyvlt.sh writes a secret as sensitive. encrypted is Vercel’s
default and is a weaker promise than it sounds: it is encryption at rest, and
the value comes back to whoever asks with the right scope.
A key you have designated a variable is written as plain, deliberately.
That is the same distinction GitHub’s connector makes between a secret
and a variable, and it means the same thing: a variable is configuration
somebody may need to read, and it must not hold anything you would mind being
read.
Why kyvlt.sh pushes
The Kubernetes connector runs beside your workloads and asks kyvlt.sh for what it needs, which is why kyvlt.sh holds no credential for your cluster. Vercel has no equivalent place to put such a thing — a build reading from kyvlt.sh would need a kyvlt.sh token, stored as a Vercel environment variable, which is the thing you came here to configure.
So this one goes the other way: kyvlt.sh writes. What you are trusting it with is an access token — either one Vercel issued it when you installed the integration, scoped to what you approved there, or one you made and pasted. The page says which of the two this deployment offers, and what it can reach.
What it never does
- It does not read from Vercel into kyvlt.sh. Every connector is one-way, outward.
- It does not delete a variable it did not write. A variable in Vercel that this connection does not carry is reported and left where it is — somebody set it by hand, and a deployment may depend on it.
- It does not claim the two sides agree. For a
sensitivevalue nobody can observe that, including us. See what the screen can claim.