DEPLOY.md

Deploying the POC

The app needs PyTorch + a ~360 MB model, so pick a host with ≥ 1–2 GB RAM (the smallest free tiers like Render's 512 MB will OOM). A Dockerfile is included and works on any container host.

Set your Sarvam key as a secret env var on the host — never commit .env:

SARVAM_API_KEY=your_key

---

Option A — Hugging Face Spaces (recommended, free, persistent)

Free CPU Spaces give 16 GB RAM and a stable public URL like https://<user>-voxsplit.hf.space — ideal for an ML demo.

1. Create a Space at https://huggingface.co/new-space → SDK: Docker → Blank.
2. Push this folder to the Space's git repo (or upload files in the UI):

   git init && git add . && git commit -m "voxsplit poc"
   git remote add space https://huggingface.co/spaces/<user>/voxsplit
   git push space main
   

3. Space → Settings → Variables and secrets → add secret SARVAM_API_KEY.
4. It builds the Dockerfile and serves on port 7860 automatically. Share the URL.

The Dockerfile pre-downloads the gender model during build, so the first request is fast.

Option B — Render (Docker web service)

1. Push this repo to GitHub.
2. Render → New → Web Service → connect repo → it detects the Dockerfile.
3. Instance type: pick one with ≥ 2 GB RAM (Starter/Standard, not Free).
4. Add env var SARVAM_API_KEY. Render injects PORT; the container already honors it. Deploy and share the *.onrender.com URL.

Option C — Fly.io (Docker, good for long requests)

fly launch --no-deploy          # generates fly.toml from the Dockerfile
fly secrets set SARVAM_API_KEY=your_key
fly scale memory 2048           # give it 2 GB
fly deploy

Option D — Instant link, zero deploy (temporary)

Fastest way to show a client right now, while your server runs locally:

# terminal 1: your app is already running on :8000
# terminal 2:
brew install cloudflared
cloudflared tunnel --url http://localhost:8000

This prints a public https://*.trycloudflare.com link. Downsides: the link is temporary and your machine must stay on. (ngrok http 8000 works the same way.)

---

Heads-up: long transcription jobs

The /api/transcribe request blocks until Sarvam's batch job finishes, which can take a while for long audio. Some platform proxies cut idle HTTP requests at ~60–100s. For a smooth client demo, use short clips (≤ ~1–2 min). If you need long files in production, the next step is to make transcription async (return a job id + poll for status) — ask and I'll wire that up.