I sell GPT prompts. Small business, $20-50 per prompt, mostly to people who use ChatBox or Cursor. Last month, one of my buyers screenshotted my prompt text and posted it in a Discord server. Within 24 hours, three other people were reselling it on Telegram. I felt sick.
The obvious fix — "just don't ship the prompt text" — sounded dumb until I realized that's exactly what every SaaS does. ChatGPT doesn't ship OpenAI's system prompt. Midjourney doesn't ship its prompt. They ship access.
So I built a tiny proxy. ~300 lines of Python, FastAPI, and httpx. OpenAI-compatible. Streaming. Bearer key auth. The prompt lives on my server, the buyer gets an API URL + key, they point their client at it, my server injects the system prompt, forwards to the AI provider, returns the response. The buyer never sees the prompt text.
This post walks through the architecture, the interesting bits, and a few mistakes I made along the way. The full Lite version is open-source on GitHub. The Pro version with encrypted storage + multi-tenant + admin panel is self-host paid — but everything in this article is in the open-source Lite version.
[Buyer's ChatBox] [My server] [DeepSeek API]
| | |
| POST /v1/chat/completions | |
| Authorization: Bearer sk-... | |
| {model, messages: [{user,...}]} | |
| --------------------------------> | |
| | 1. verify bearer key |
| | 2. load prompt from config |
| | 3. prepend as system message |
| | 4. forward to upstream |
| | ------------------------------>|
| | |
| | <--- response (stream ok) ----|
| | |
| <--- stream chunks --------------| |
| | |
The buyer's request is identical to what they'd send to OpenAI. The only difference is the URL and the API key.
The buyer is waiting for tokens. If you buffer the entire upstream response before returning, you've killed the UX.
async def _stream_upstream(url, headers, payload):
timeout = httpx.Timeout(connect=10.0, read=120.0, write=10.0, pool=10.0)
async with httpx.AsyncClient(timeout=timeout) as client:
async with client.stream("POST", url, headers=headers, json=payload) as resp:
if resp.is_error:
body = await resp.aread()
err = json.dumps({"error": {"code": resp.status_code, "message": body.decode("utf-8", "replace")}})
yield f"data: {err}\n\n"
yield "data: [DONE]\n\n"
return
async for line in resp.aiter_lines():
if not line:
continue
if line.startswith("data:"):
yield line + "\n\n"
else:
yield f"data: {line}\n\n"
yield "data: [DONE]\n\n"
FastAPI's StreamingResponse
will iterate this async generator and flush each chunk to the client immediately. No buffering. The buyer sees the first token as soon as the upstream emits it.
Mistake I made first: I returned response.aiter_raw()
directly without re-emitting the data:
prefix. ChatBox silently ate the stream because it expected SSE format. Always re-emit in SSE format.
The buyer may have configured their own system prompt in ChatBox. You don't want to overwrite it — you want to prepend yours.
def _inject_system_prompt(messages):
config = load_prompts()
system_text = (config.get("system_prompt") or "").strip()
if not system_text:
return messages
if messages and messages[0].get("role") == "system":
merged = {
"role": "system",
"content": system_text + "\n\n" + messages[0].get("content", ""),
}
return [merged, *messages[1:]]
return [{"role": "system", "content": system_text}, *messages]
Mistake I made first: I appended my system message at the end of the message list. The model treated it as a user instruction and the buyer's prompt leaked through. Always prepend, always merge if there's already a system message.
import secrets
from fastapi import Header, HTTPException, status
async def verify_client_key(authorization: str | None = Header(default=None)) -> str:
if not authorization or not authorization.lower().startswith("bearer "):
raise HTTPException(status_code=401, detail="Missing or invalid Authorization header")
token = authorization[7:].strip()
for configured in settings.client_keys:
if secrets.compare_digest(token, configured):
return token
raise HTTPException(status_code=401, detail="Invalid API key")
secrets.compare_digest
is constant-time. token == configured
is not — it short-circuits on the first different byte, which leaks key length and prefix info via timing. For 32-character API keys this is a minor risk, but it's free to do correctly.
Some buyers will configure gpt-4
in their client even though your upstream is DeepSeek. You can either reject the request or silently override:
def _override_model(model):
forced = (load_prompts().get("force_model") or "").strip()
return forced or model
I force the model. Buyers don't care which model runs, they care about the result. Forcing also means you can swap upstream providers without telling buyers.
After shipping the Lite version, I realized I needed more to actually run a prompt-selling business:
cat prompts.yaml
. The Pro version uses AES-256-GCM encryption in SQLite.clients
table with per-client keys + expiry + active flag.usage_logs
table.These are all in the Pro version (self-host, $49 personal / $99 team / $249 agency).
AES-256-GCM with a random nonce per encryption. The encryption key is a 64-character hex string loaded from env. Each prompt save generates a new nonce.
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import secrets
_NONCE_LENGTH = 12
def encrypt_prompt(plaintext: str, key: bytes) -> bytes:
nonce = secrets.token_bytes(_NONCE_LENGTH)
ciphertext = AESGCM(key).encrypt(nonce, plaintext.encode("utf-8"), None)
return nonce + ciphertext
def decrypt_prompt(ciphertext: bytes, key: bytes) -> str:
nonce = ciphertext[:_NONCE_LENGTH]
encrypted = ciphertext[_NONCE_LENGTH:]
return AESGCM(key).decrypt(nonce, encrypted, None).decode("utf-8")
Why AES-GCM and not AES-CBC? GCM gives you authentication for free — the auth tag validates that the ciphertext hasn't been tampered with. With CBC you'd need to add HMAC separately. GCM is also faster in hardware.
Why random nonce per encryption? If you reuse a nonce with the same key in GCM, you catastrophic-ally break confidentiality. secrets.token_bytes(12)
gives you 96-bit nonces, which is the GCM standard.
Threat model: Encryption protects against (1) database leak, (2) backup leak, (3) someone with file system access cat
-ing the SQLite file. It does NOT protect against someone with root on the running process — at that point the key is in memory and you're done. The point is raising the bar from "open the db file" to "compromise the running process".
The Lite version is a single Dockerfile:
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]
Build + run:
docker build -t prompt-proxy-lite .
docker run -p 8000:8000 --env-file .env -v $(pwd)/prompts.yaml:/app/prompts.yaml prompt-proxy-lite
For public internet exposure, put it behind Cloudflare Tunnel or Caddy. Don't expose FastAPI directly — it's not a TLS terminator.
/v1/chat/completions
correctly, you get compatibility with ChatBox, Cursor, LibreChat, Open WebUI, every Python/JS SDK, for free. This is a huge leverage point — you don't need to write a client.If you build something similar, I'd love to hear about it. The architecture is small enough that you can fork the Lite version and add your own twists — multi-model routing, prompt versioning, A/B testing, whatever.
If you found this useful, follow me on Twitter where I post about indie hacking + Python + AI tooling. And if you want to sell prompts but don't want to build the proxy yourself, the Pro version is $49 for personal use.
Article by tlyyxjz — indie hacker, Python dev, building tools for the AI creator economy.