Deployment Patterns

A prompt can be stored in three places: hard-coded in the application source (embedded in the code), in a configuration file or environment variable (config-driven), or in a database or external service (database-backed or service-backed). The storage choice determines how the prompt is deployed, how fast changes can be made, and how easy rollback is.

Hard-coded prompts: the prompt text lives in the application code. Change the prompt, change the code, deploy a new application version. Rollback means reverting the code commit. Simple, auditable (the prompt is in version control), but slow — every prompt change requires a full application deploy cycle. Appropriate for small teams with infrequent prompt changes and engineering-managed prompt workflows.

Config-driven prompts: the prompt is loaded from an environment variable, a config file, or a secrets manager at application startup. Change the config, restart the application. Faster than a code deploy, but still requires a restart cycle. The prompt is separated from the application code — non-engineers can change it with config access. Rollback is a config revert.

Database-backed or service-backed prompts: the prompt is retrieved at runtime from a database or an external prompt management service. Change the record in the database, the change is live on the next request — no restart required. Enables per-request prompt selection, A/B testing, and live updates without deployment. The complexity cost is significant: the database becomes a critical dependency, caching strategy must be designed, and the blast radius of a bad change is immediate.