Change the prompt.
Not the deploy.
Your LLM prompts live as strings in your codebase, so every wording tweak is a pull request. promptkit moves them into a versioned store behind a GraphQL API — publish a new version, or roll back a bad one, and your app picks it up on its next request.
Hey {{name}}, welcome to {{product}} — here’s how to start.
Hey {{name}}, welcome to {{product}} — here’s how to start.
Hi {{name}}, thanks for signing up for {{product}}.
Welcome aboard, {{name}}.
Prompts are content, but they ship like code.
A wording tweak is a code change
Changing one sentence means a branch, a review, a merge and a deploy. The people who write the copy usually cannot ship it themselves.
No history when quality drops
Output gets worse after a release and nobody can say exactly which words changed, or when, or what the previous version said.
No safe way back mid-incident
Reverting means finding the commit, reverting it, and waiting on a full deploy — while the bad prompt keeps serving traffic.
// somewhere in your codebase
const WELCOME_PROMPT = `Hey ${name}, welcome to ${product}...`;
// ^ to change this, open a PR and redeployWire it up once. Then never again.
The API key goes into your environment one time. After that, changing a prompt never means touching your code or redeploying — publishing and rolling back are the same operation, moving which version the slug resolves to.
- 01
Create a prompt, get a slug
Sign up and add your first prompt in the dashboard. It gets a stable slug — welcome-email — and its first version.
- 02
Put one API key in your environment
Generate a key in Settings and add it to your app’s environment variables as PROMPTKIT_API_KEY, alongside PROMPTKIT_URL=https://prommpttkitt.space. Those two values are the only promptkit-specific things your codebase ever holds.
- 03
Fetch the active version at runtime
Your app queries by slug and authenticates with that key. It gets back whichever version is active right now — the prompt text never enters your repo.
- 04
Publish and roll back from the dashboard
Edit the template and publish — live immediately, no deploy. Roll back to any previous version in one click.
PROMPTKIT_URL=https://prommpttkitt.space
PROMPTKIT_API_KEY=pk_a1b2c3…const res = await fetch(`${process.env.PROMPTKIT_URL}/api/graphql`, {
method: "POST",
headers: {
"Content-Type": "application/json",
"x-api-key": process.env.PROMPTKIT_API_KEY,
},
body: JSON.stringify({
query: `query {
prompt(slug: "welcome-email") {
activeVersion { template }
}
}`,
}),
});{
"data": {
"prompt": {
"activeVersion": {
"template": "Hey {{name}}, welcome..."
}
}
}
}That is the whole integration. The same request runs before a rollback and after one — only the template in the response changes.
Built around versions.
Immutable version history
Every edit creates a new version. Nothing is overwritten, so you can always read exactly what shipped and when.
Instant rollback
The active version is a pointer. Moving it back to a previous version takes effect on the very next request.
A/B testing
Split traffic between two versions. Assignment is a hash of the subject id, so a given user always sees the same variant.
Live updates
Version changes are pushed over Supabase Realtime — open dashboards reflect a rollback without a refresh.
Teams who change prompt wording often.
If your prompts are settled and rarely change, a constant in your codebase is fine. promptkit is for the other case — where you are still tuning wording week to week, where a bad edit shows up in production output, and where you want the history and a way back that does not depend on a deploy finishing.
It is a young open-source project, running here for anyone to sign up and use — free, with no SLA. The core is working today: versioning, activation, rollback, API keys, A/B assignment and realtime updates. You can also run your own copy; the code is on GitHub.
Get your prompts out of your codebase.
Create an account, add your first prompt, and drop one API key into your environment. Every prompt change after that ships without a deploy.