Documentation
Add Kicklace from Vercel
Install from Vercel and your keys are written into your project.
Press Add Integration in Vercel and Kicklace writes its keys straight into your project's environment variables. Nothing to copy, nothing to paste, and no key on a screen: a secret key for your server, the public key for the tag, and the two addresses both of them need. Then it allows your project's production domains, so the tag works the moment you deploy.
This is different from Deployments from Vercel, which makes your production deploys land as releases. The install can set that up for you too, which is the only place they touch.
What one click does
- You press Add Integration in Vercel and choose the team or personal account it goes into.
- Vercel opens Kicklace with a short-lived code, and Kicklace swaps it for an access token at once, so the rest can wait for you.
- You sign in to Kicklace, or sign up, and come back to where you were.
- One screen asks two things: which workspace, and which projects. Every project is ticked, and so is "Send deployments to Kicklace too".
- Connect, and for each project Kicklace:
- makes a server key of its own, labelled
Vercel: <project>; - writes four environment variables into the project, for production and preview;
- allows the project's production addresses to post to your workspace;
- and, once for the whole install, makes the deployments webhook.
- makes a server key of its own, labelled
- Redeploy each project once. A build only has the variables it started with.
Nothing is emailed and nothing is charged.
The variables it writes
| Name | What it is | Where |
|---|---|---|
KICKLACE_SECRET_KEY |
the server key the package posts events with | production and preview, encrypted |
NEXT_PUBLIC_KICKLACE_KEY |
the public key the tag carries; it can only add people | production, preview, development |
KICKLACE_URL |
where Kicklace is, for the package on your server | production, preview, development |
NEXT_PUBLIC_KICKLACE_URL |
where Kicklace is, for <KicklaceTag /> in a page |
production, preview, development |
Both addresses are written because the package reads them separately: new Kicklace(…) reads
KICKLACE_URL and <KicklaceTag /> reads NEXT_PUBLIC_KICKLACE_URL.
A name your project already has is updated, never doubled. A variable you set by hand afterwards is the one that stands until you connect again.
Doing it twice
Pressing Connect again is safe, and it's how you finish an install that stopped halfway:
- a project that already has its key keeps it, and the public key and address are refreshed;
- a project you tick for the first time gets everything;
- addresses already allowed are left alone;
- deployments are only connected once.
A step that fails says which project and why, and everything before it stays done. If you left "Send deployments to Kicklace too" unticked, Connect deployments too under Connected from Vercel on Connections → Vercel does the same thing later.
What's never written
- No key is ever shown on a screen, put in a log, or handed back in an answer.
- Kicklace never writes into a project you didn't tick, or touches a variable it doesn't own.
- Development gets no secret key, because a laptop shouldn't post into a production workspace.
Taking it away
- Disconnect on Connections → Vercel → Connected from Vercel revokes the keys that install made. They stop working at once; the variables stay in your projects, holding a key that no longer answers.
- Remove the integration in Vercel's own Settings → Integrations → Kicklace clears the variables, and Vercel tells Kicklace, which revokes the keys itself.
Either way your workspace, its people, its releases and its allowed addresses all stay.