How to version and manage prompts in production: a guide

By the end of this guide you will have your prompts stored in a registry instead of scattered through your code, with version history, separate dev and production releases, tests that run before a change ships, and a quick way to roll back. The software for this is a prompt management tool, usually one that also records production traces so you can see which prompt version produced which answer.

Prompt management in production matters because a small wording change can alter behaviour for every user. This guide walks through the setup step by step and compares seven tools from our Developer platforms category, from dedicated prompt registries to open-source observability platforms that include prompt versioning.

Key takeaways

• Treat prompts like code: store them in one registry, version every change, test before release, and keep a rollback ready.
• The main decision is a dedicated prompt registry, an observability platform with prompt features, or an open-source tool you host yourself.
• Link each logged request to the prompt version that produced it, otherwise you cannot tell whether a change helped.
• Free plans exist but have request, seat or data caps. Check them against your traffic before you move production prompts onto one.

What you need before you start

• An LLM app with prompts you want to control. Even a handful of prompts hard-coded in files will do.
• A list of who edits prompts. Engineers only, or also product managers and domain experts.
• A set of test cases. Real inputs and what a good output looks like, even roughly.
• A model provider key. Evaluations and playgrounds call your model provider, and you pay for that usage.
• Time. Moving a few prompts into a registry takes under a day. Building a good test set takes longer.
• Difficulty. Easy to moderate. The code change is small, and the discipline is the main work.

Which kind of AI tool fits this job

Pick by who edits prompts and how much of the surrounding platform you want.

A dedicated prompt registry for teams. PromptLayer keeps prompts in a registry outside the codebase, with a visual editor, version history with comments, diffs and rollbacks, and separate dev and prod deployments. It also adds evaluations and observability. PromptHub stores prompts with Git-style branches and commits, and an API runs or returns the latest commit from a branch, so a prompt tweak needs no code redeploy.

An open-source observability platform with prompt management. Langfuse records traces, sessions and cost, and adds prompt versioning with release management, a playground, datasets and experiments. You can use the managed cloud or self-host it under the MIT license. Arize Phoenix is open source and includes prompt management with versioning and a side-by-side playground, and it can rerun datasets through new prompt versions to see whether a change helped. MLflow is an open-source platform that versions prompts with lineage tracking alongside traces and evaluation, and also covers classic machine learning.

Logging-first tools with prompt features. Lunary combines logging, analytics and evaluation with prompt templates that support versioning and A/B testing, so non-technical teammates can collaborate. Helicone logs requests with cost and latency through a one-line change to your base URL, and includes prompt management without redeploying alongside an AI gateway.

Step 1: Inventory your prompts

You finish this step with a list of every prompt that reaches a model.

1. Search the code for system prompts, templates and inline strings.
2. Record for each: what it does, which model it uses, which variables it takes, and who owns it.
3. Mark the high-impact ones, such as customer-facing answers or anything that triggers actions.
4. Note any prompts that contain sensitive data or customer names, and remove those from the text.

Check it worked by having a table of prompts with an owner and a risk level each.

Step 2: Decide who edits and who approves

A registry is only useful if the right people can change prompts safely.

1. Decide whether non-engineers will edit prompts. PromptLayer and Lunary both describe collaboration with non-technical teammates.
2. Choose how changes are reviewed. PromptHub's Git-style branches and commits support review before shipping.
3. Decide who can publish to production, and keep that group small.
4. Write a short rule: no prompt change goes live without a passing test run.

Check it worked by being able to name who can publish a prompt change.

Step 3: Choose a tool and set up the registry

Match the tool to your team and your hosting rules.

1. Compare the options in the table below. Check free-plan caps on users, requests and data.
2. Check where data is stored. PromptLayer's Free, Pro and Team plans run on its US cloud, and self-hosting is an Enterprise option. Langfuse, Phoenix, MLflow and Helicone list self-hosting.
3. Create a project and add your API keys.
4. Import the prompts from Step 1 with their names and variables.

Check it worked by opening the registry and seeing every prompt listed with its current text.

Step 4: Fetch prompts from the registry in your app

The point of a registry is that the app reads from it.

1. Replace hard-coded prompt text with a call that fetches the prompt by name and label, such as dev or production.
2. Pass the variables when you build the final prompt.
3. Cache the fetched prompt for a short time, and keep a fallback copy in your code so the app still works if the registry is unreachable.
4. Attach the prompt name and version to each logged request. PromptLayer ties each log to the prompt version that produced it.

Check it worked by changing a prompt in the registry and seeing the new text used by the dev environment without a redeploy.

Step 5: Version, label and release

Make every change visible and reversible.

1. Save each edit as a new version with a comment describing why.
2. Use labels or environments to separate dev, staging and production.
3. Publish a version to production only after tests pass.
4. Practise a rollback: point production back to the previous version and confirm it works.

Check it worked by rolling back a test prompt and seeing the older behaviour return.

Step 6: Test changes before they ship

A prompt change should have to pass a test, like code does.

1. Build a dataset of realistic inputs, including difficult ones, from your Step 1 notes and from real logs.
2. Run the new prompt version against the dataset, and compare with the current version. Phoenix can rerun traces through new prompt versions, and Langfuse has datasets and experiments.
3. Score results using rules, an LLM judge, or human review. PromptHub evaluations, on its Team and Enterprise plans, use string rules or an LLM as judge, and PromptLayer lists human and AI graders.
4. Trigger tests automatically where the tool allows. PromptLayer lists regression tests when a prompt updates, and PromptHub pipelines (Team and Enterprise) run checks on commits.
5. Have a person review any prompt that affects advice in legal, medical or financial areas.

Check it worked by seeing a deliberately bad prompt fail the test before it can be published.

Step 7: Monitor in production and iterate

Releases are only half the loop.

1. Watch cost, latency and error rates per prompt version.
2. Sample real outputs and score them, to catch quality drift.
3. Turn failures into new test cases.
4. Run an A/B test for risky changes where the tool supports it. PromptLayer and Lunary both list A/B testing of prompt versions.

Check it worked by turning one production failure into a test case that the next version has to pass.

Tools for this job compared

Tool	Good fit for	Pricing	Stated limits
PromptLayer	A prompt registry with evals and observability for mixed teams	Freemium, paid from $49/mo (checked 24 Oct 2026)	Free plan: 5 users, 2.5k requests a month and 10MB per dataset; self-hosting and EU cloud are Enterprise options
PromptHub	Git-style prompt versioning with an API	Freemium, paid from $9/mo (checked 24 Oct 2026)	Free plan prompts are all public; evaluations and pipelines are on Team and Enterprise
Langfuse	Open-source tracing, prompts and evals; cloud or self-hosted	Freemium, paid from $29/mo (checked 24 Oct 2026)	Hobby plan includes 50k units a month, 30 days of data access and 2 users
Arize Phoenix	Open-source tracing and experiments with prompt versioning	Open source	Self-hosting means your team provisions and maintains it; support is community-based
MLflow	Prompt versioning next to experiment tracking and a model registry	Open source	You run and maintain the tracking server; applications need a small amount of instrumentation code
Lunary	Logging, analytics and prompt templates with A/B testing	Paid, from $20/mo (checked 24 Oct 2026)	Team plan includes 50k events a month and caps seats at 10; self-hosting, SSO and PII masking are Enterprise
Helicone	Request logging and a gateway with prompt management	Freemium, paid from $79/mo (checked 24 Oct 2026)	Free tier covers 10,000 requests, 1 GB of storage and 1 seat; Pro and Team add usage-based charges

Prices and plan limits change, so confirm the current terms on each vendor's site before you commit.

Common mistakes to avoid

• Leaving prompts in code. It is quick at first, but every change needs a deploy and nobody can see the history. Fix it by moving prompts to a registry and fetching them at run time.
• Shipping without tests. A tweak that fixes one case can break others. Fix it by running every change against a dataset before publishing.
• Not linking logs to versions. Without that, you cannot tell which prompt caused a bad answer. Fix it by recording the prompt name and version on every request.
• Putting secrets and customer data in prompts. Registries store text and may share it with a team. Fix it by keeping secrets out, using variables for user data, and checking the tool's data location.
• Ignoring plan caps. Free plans limit users, requests, retention or private prompts, and PromptHub's free-plan prompts are all public. Fix it by checking the stated limits before you add production traffic.

How we put this together

This is an evidence-based guide built from each tool's listing in our directory, which is compiled from the vendor's own site and pricing page. It is not a review based on using the tools. We don't rank tools, and nobody paid to be included. Some outbound links may be affiliate links; see our disclosure.

Frequently asked questions

Is there a free way to manage prompts?

Yes. Langfuse, Arize Phoenix and MLflow are open source and can be self-hosted for free, and PromptLayer, PromptHub, Langfuse Cloud and Helicone all list free plans or tiers. Free options have caps on users, requests or data, and you pay your model provider separately.

Why not just keep prompts in Git?

Git works for small teams of engineers. A registry adds a visual editor for non-engineers, separate dev and production releases without a redeploy, and links between logs and prompt versions. Some tools, such as PromptHub, give you Git-style versioning inside the registry.

How do I roll back a bad prompt?

Keep every version and point production back to the previous one. PromptLayer lists version history with comments, diffs and rollbacks. Practise the rollback before you need it.

Do I need an observability platform as well?

You need some way to see which prompt version produced each output. Platforms such as Langfuse, Phoenix, Lunary and Helicone combine logging with prompt features, so one tool can cover both.

Can I keep my prompts private?

Self-hosting keeps data on your infrastructure, and Langfuse, Phoenix, MLflow and Helicone list it. Some hosted plans run on a single region only. PromptHub's free plan makes prompts public, so private prompts need a paid plan.

Compare more options in our Developer platforms category.