Gateway

Deployment

This page is about routing your app's live traffic through Cran - a step that's optional and separate from the MCP connection (cran login). Cran doesn't run inside your app process. Locally and in production your code calls the same OpenAI-compatible proxy with the same connection key - only where the env vars live changes.

Environment variables (the optional routing key)

These env vars hold the connection key that routes live traffic through the proxy - they are not the MCP login. After cran link, copy these from the generated .env(never commit it) into your host’s environment:

.env

OPENAI_API_KEY=cran_…          # product connection key (from cran link, routing only)
OPENAI_BASE_URL=https://trycran.in/api/v1
CRAN_PROJECT_ID=project_…       # optional metadata

Your application code is unchanged - keep reading process.env.OPENAI_API_KEY and process.env.OPENAI_BASE_URL.

Vercel

Add the variables under Project → Settings → Environment Variables, then redeploy:

bash

vercel env add OPENAI_API_KEY production
vercel env add OPENAI_BASE_URL production
vercel env add CRAN_PROJECT_ID production

Staging vs production

This is about isolating routed traffic per environment - the single MCP login (cran login) is unaffected.

Create two Cran projects (e.g. my-app-staging and my-app-prod).
Run cran link --project … per environment - each yields a different connection key for routing.
Map Preview deploys → staging key, Production → prod key via Vercel env scopes.
Spend and Connected status are per-project, so staging traffic never pollutes prod metrics.

Token hygiene

Provider keys & regions

Provider keys (OpenAI / Anthropic / Google, plus Cohere for embeddings) are configured on the Cran server, not in your app. The new embedding and image endpoints only resolve models whose provider key is set. Run the gateway in a region close to Supabase and your providers to minimize added latency.

Going live safely

A quick checklist to deploy with confidence — most of it is one click in the dashboard, no redeploy.

Verify — open Deployin the dashboard, send one request from your app, and watch it flip to “you’re live”. The response carries an x-cran-model header showing which model answered.
Roll out gradually — point a staging environment (or one non-critical workflow) at Cran first; check Analytics for success rate, latency, and spend before the full production cutover.
Roll back instantly — on any workflow, Take offline or Undo last change (live in ~30s, no redeploy). Or remove OPENAI_BASE_URL to fall straight back to your provider.
Monitor — Activity shows who changed what plus tests and scans; Analytics tracks spend, errors, and latency per model and workflow.
Cap spend — set a budget in Limitsso a runaway can’t overspend; the gateway also retries fallbacks automatically if a model errors.

After the first production request

The dashboard flips to Connected and records spend by model and workflow. Platform routing (model, system prompt, temperature) is controlled from the dashboard - publish an architecture to change what auto serves.