---
name: prompton-setup
description: Set up PromptOn in an existing server-side LLM app, or continue its setup and approved migration from a PromptOn setup prompt.
---

# Set up PromptOn

App host: https://app.prompton.ai.

PromptOn lets a team manage an application's prompts, model settings and deployment
revisions outside application code, then inspect call logs and compare candidates
in Arena. A prompt represents an LLM call site. An environment's deployment pins
one immutable prompt version, model and parameter configuration. Editing or
committing a draft does not change runtime behavior until it is deployed.

The application fetches that configuration through the SDK, calls the model
provider with its own credentials and HTTP client, and reports monitoring logs.
PromptOn does not proxy those application calls. Provider keys registered in
PromptOn serve its own features, such as Arena; they do not replace the app's keys.

## Use the current references

Read the [short guide](https://app.prompton.ai/docs/agent.md) when starting or resuming setup;
it owns the launcher-scope rules and setup sequence. Treat the hosted references
as the source of truth for CLI commands, API schemas and SDK capabilities.

The links below return Markdown.

| When you need to… | Read |
| --- | --- |
| Resolve launcher scope and follow the setup sequence | [Agent guide](https://app.prompton.ai/docs/agent.md) |
| Understand prompts, pins, environments or credentials | [Concepts](https://app.prompton.ai/docs/concepts.md) |
| Inspect call sites, choose targets and provision resources | [Setup provisioning](https://app.prompton.ai/docs/setup-provisioning.md) |
| Install/authenticate the CLI or check a command and flags | [CLI](https://app.prompton.ai/docs/cli.md) |
| Provision through HTTP or handle a capability absent from the CLI | [CLI HTTP API reference](https://app.prompton.ai/docs/management-api.md) |
| Create and verify the setup's synthetic samples | [Setup samples](https://app.prompton.ai/docs/setup-samples.md) |
| Propose or perform the approved application migration | [Setup migration](https://app.prompton.ai/docs/setup-migration.md) |
| Select an SDK and inspect its current supported interface | [SDK guide](https://app.prompton.ai/docs/sdks.md), then only the chosen language's versioned README |
| Fetch/render runtime configuration or send logs | [SDK HTTP API reference](https://app.prompton.ai/docs/api.md) |
| Implement or verify caching, bundles and outage behavior | [SDK config fetch](https://app.prompton.ai/docs/sdk-config-fetch.md) |
| Preserve tool calls or record execution traces | [Tools and traces](https://app.prompton.ai/docs/tools-and-traces.md) |
| Diagnose an actual setup failure | [Troubleshooting](https://app.prompton.ai/docs/troubleshooting.md) |

Before writing an integration, check the chosen SDK's documented release and the
installed dependency/lockfile. Do not infer identical features across languages
or invent methods from an example in another SDK.

## Preserve scope and application behavior

- Honor the setup prompt's organization, project and prompt scope. The five
  launchers are landing, organization, new project, existing project and single
  prompt. The guide distinguishes reuse from creation; a new-project launcher
  requires a new project, while single-prompt setup stays within that prompt.
  Preserve returned identifiers on retries. Resolve genuinely ambiguous targets
  before writing rather than picking an unrelated project.
- Inspect real server-side LLM call sites before provisioning. Preserve their
  prompt kind, variable values and types, model, parameters, tools, response
  parsing and return type. A browser-only call site needs a server-side boundary
  first; no call sites means there is nothing to migrate.
- Keep authentication roles distinct. The CLI's device-login session manages
  resources; a project SDK key fetches configuration and sends logs. Relay
  the actual device approval URL/code while login is waiting. Keep credentials
  server-side and out of source control, chat and monitoring payloads.
- Preserve Chat and Decision contracts. For Chat, the app owns conversation
  history and the current user input and combines them with rendered managed
  messages. For Decision, use the deployment's native API, request path and body;
  do not silently route it through Chat. Missing SDK request-contract support
  blocks that call site's migration; it does not authorize building a new SDK.

## Prepare, review and verify

Provision nonproduction review resources first. Select the project's existing
lowest active nonproduction environment from its current ordered environments,
and carry its slug as `PTN_SETUP_ENV`. Do not assume `staging` exists or create a
replacement environment. Keep production pins, environment ordering/protection
and shared settings unchanged during setup.

Follow the guide's provisioning and sample stages before app migration. Setup
samples are synthetic manual fixtures, not observed provider calls. Create ten
successful samples per deployed prompt, including reused prompts, and use the
sample reference for retry identity, accounting and stored-payload verification.
Never report an accepted write as proof that its stored content was verified.

App-code migration needs approval; reuse approval already given in the session.
Make the proposed mapping and code change reviewable before asking, and continue
when that approval exists. A prompt-kind or Decision response-schema change also
requires compatibility with both deployed and candidate contracts before changing
the pin. Follow the migration reference for the detailed review and rollout order.

Use the same environment for configuration, logs, cache and bundle data. Map the
application's actual production deployment flag to PromptOn `production`, and
other deployments to `PTN_SETUP_ENV`; build mode alone does not establish that flag.
Keep the last valid memory/disk/bundle configuration during outages. With no valid
configuration, surface an explicit error instead of restoring hard-coded prompts.

Finish with actual prompt/deployment, Logs and Arena links; sample accounting;
representative behavior and offline-cache/bundle verification; the code diff;
and rollback instructions. Distinguish observed results from synthetic fixtures,
proposed changes and unsupported call sites. Setup ends at verified nonproduction
integration; production rollout needs a separate request.