PROMPT MANAGEMENT

Ship prompts without shipping code.

Every prompt is a set of immutable revisions. Promote by moving a label — REST, SDK, and MCP resolve identically, with no redeploy.

Immutable revisions + append-only rollback + label promotion, resolved identically across REST, SDK, and MCP.

3Interfaces (REST · SDK · MCP)
ImmutableRevisions
Append-onlyRollback
0SDK runtime deps
OpenAPI 3.1Generated spec
Apache-2.0License

$ npm install @usetheo/promptly-sdkcoming to npm

Read the docs View on GitHub

Prompts drift the moment they leave your editor: hard-coded strings, a redeploy for every tweak, no history when something breaks. Theo Prompts treats a prompt as a named resource with immutable revisions and environment labels. You edit by adding a revision, you promote by moving a label, and the next resolution reflects it — from your backend, your app, or an agent over MCP.

What you get

Concretely, what ships.

Immutable revisions

Each edit is a new version; history is auditable, rollback is append-only.

Label-based promotion

Point prod / staging at a revision; promote by moving the pointer, no redeploy.

{{var}} templating

Templates render client-side in the SDK; the server never sees variable values.

Three interfaces, one core

REST, SDK, and MCP delegate to the same core — a contract test proves parity.

Typed, fail-clear errors

Codes like prompt_not_found, invalid_template, label_not_found.

Cache that can’t be a SPOF

Redis epoch-rotation invalidates on promote; any Redis error falls back to Postgres.

Feel it

typescript

import { PromptlyClient } from '@usetheo/promptly-sdk';

const client = new PromptlyClient({ baseUrl: 'http://localhost:3000' });

await client.createPrompt('greet', 'hi {{name}}');   // v1
await client.assignLabel('greet', 'prod', 1);        // prod -> v1

const p = await client.getPrompt('greet', { label: 'prod', vars: { name: 'Theo' } });
p.content; // 'hi Theo' — rendered in the SDK; the value never reaches the server

await client.assignLabel('greet', 'prod', 2);        // promote, no redeploy

Promote from v1 to v2 by moving a label — no redeploy.

What you'd ship

Things you would actually build.

01Promote a new prompt revision to prod by moving one label — no rebuild of your app.
02Roll back a bad prompt with an append-only revision instead of a code revert.
03Let agents resolve prompts over MCP with the exact content your backend serves.
04Keep an auditable history of every prompt change, ordered by revision.
05Render {{var}} values client-side so sensitive variables never hit the server.
06Point staging and prod at different revisions to test before you promote.

Why Theo Prompts

How it compares.

Prompts are now production config, and agents increasingly need the same prompt your app uses, resolved the same way. Comparison of versioned-prompt features, public docs mid-2026.

Capability	Theo Prompts	LangSmith Prompts	PromptLayer	Langfuse
Access surface	REST + SDK + MCP (one core)	REST / SDK	REST / SDK	REST / SDK
Promotion model	Move a label, next resolve reflects it	Versions / tags	Versions	Labels / versions
Variable privacy	Rendered client-side, values never sent	Varies	Varies	Varies
SDK runtime deps	Zero (native fetch)	Varies	Varies	Varies
Self-host	Apache-2.0, Postgres (+Redis)	Mostly SaaS	SaaS	Self-hostable

Versioned prompts you promote by moving a label — reachable identically from a backend, an app, and an agent — over Apache-2.0 code you can host yourself.

Why now

A prompt change should be a config change, not a deploy. Theo Prompts makes the prompt a first-class, versioned, immutable resource with one core behind REST, SDK, and MCP.

Status

Honest claims only.

One core behind REST, SDK, and MCP — a contract test proves all three resolve identically.
Immutable revisions + label promotion + append-only rollback, backed by Postgres and optional Redis.
Apache-2.0 · self-hostable · SDK publishing to npm next.