Connecting a Vercel project
Two steps, in this order. The second refuses until the first is done, which is deliberate: the alternative is configuration that looks complete and can never push.
1. Connect an account
There are two ways in, and the page shows you the one this deployment has.
Installing the integration
If whoever runs this deployment registered a Vercel integration, the page has a Continue to Vercel button. It sends you to Vercel’s own install page, where you choose the team, choose which projects the integration may reach, and approve the scopes Vercel lists. kyvlt.sh learns the answer when Vercel sends you back — nothing about your Vercel account is typed in here, and no credential is created by hand.
This is the same shape as installing the GitHub App, and for the same reason: the decision about what this may reach belongs on the page owned by whoever owns the account.
Pasting an access token
If it registered none, the page asks for an access token instead. A Vercel integration cannot be created by the thing that wants to use it — it is registered in Vercel’s console by a human and issued a client secret there — so a self-hosted kyvlt.sh that has not done that uses a token.
Make one at vercel.com/account/settings/tokens.
Two things are worth deciding while you are there:
- Scope it to the team that owns the projects, not to a personal account. A Vercel token can reach everything its account can, and there is no per-project scoping to ask for. A team token reaches that team.
- Give it an expiry you are willing to renew. kyvlt.sh will tell you when a push starts failing, but it cannot renew a token for you — there is no API for that. A token with no expiry never asks for attention and never stops working, and you should choose that knowingly rather than by default.
kyvlt.sh asks Vercel what the token can act for and shows you the answer: the personal account behind it, and any teams. Pick one. Nothing is stored until you do.
Either way
The token is sealed under your organisation’s key, and no screen returns it afterwards — not masked, not its length, not whether it still parses. If you need to know whether it still works, push something.
2. Align a project, then choose targets
A project is aligned to one Vercel project. Pick it from the list; the list is what your token can see.
An environment then chooses its targets: production, preview,
development. They are buttons rather than a text field because Vercel has
exactly three, and a typed name that Vercel does not have is a connection that
can never work.
One environment can push to more than one target, and two environments can push to the same one — kyvlt.sh will tell you when that happens, because whichever pushed last wins and the winner changes with whoever edited most recently.
Renaming, moving, and removing
Renaming a Vercel project changes nothing. The alignment stores
Vercel’s own prj_… identifier, not the name.
Moving a project to a different Vercel project is one edit on the project. Every environment under it follows, and the new project holds none of these keys until the next push.
Removing the account here stops every environment that pushed through it. kyvlt.sh refuses to do that quietly: it names what will stop first. What is already in Vercel stays in Vercel.
Uninstalling at Vercel’s end does the same thing from the other side, and kyvlt.sh finds out the next time it pushes: the token stops working, the connection carries the sentence saying so, and the bell says it if it stays broken. Installing again issues a new grant and replaces the old one — Vercel never reuses the identifier of an installation that has been removed.