Infrastructure and deployment

Connection strings, IPs, passwords and test accounts are in the team secret manager. They don't belong on this page.

Environments

	Marketing	Product	API
Production	kwilo.ai	app.kwilo.ai	api.kwilo.ai/api/v1
Staging	staging.kwilo.ai	app-staging.kwilo.ai	api-staging.kwilo.ai/api/v1
Local	localhost:5174	localhost:5173	localhost:8000

Staging is behind Cloudflare Access: a @kwilo.ai email login for people, a service token for native builds.

Locally, pnpm dev:local runs the stack with Caddy simulating the subdomain split. pnpm dev:local:staging points the frontends at the staging API, which is the way to test LLM features because local backends have no model keys.

Azure

Everything runs in Azure Central India, subscription KwiloAI Startup Credits. Terraform lives in MySetu-AI/kwiloai_infra.

	Resource group	What
Backend	kwilo-backend-{staging,prod}-rg	Container Apps environment (VNet-injected): backend, imgproxy, doc-intelligence, deep-research, migrations job, reaper job. Blob uploads, Key Vault, ACR, Redis private endpoint.
Database	kwilo-prod-pg-rg (prod)	Azure Database for PostgreSQL Flexible Server, private access, delete lock
Shared	existing	Chatbot and eval service (Container Apps), Qdrant and memory Redis (AKS), Service Bus, Application Insights

App secrets are Key Vault references on the Container App and its migrations job. GitHub Actions deploys through OIDC federation, no stored credentials.

Staging and production have separate database servers. Database names keep the old vidyanet prefix.

Google Cloud

GCP hosts only what Azure can't replace:

• The private Python package index kwiloai-python in Artifact Registry, which every backend build pulls from.
• Gemini through Vertex AI. Azure managed identities federate into the GCP pool azure-pool and impersonate vidyanet-backend-sa. No long-lived keys.
• Google products: Sign-In and the OAuth clients (in vidyanet-staging), Play publishing, Firebase App Distribution.

The GCP projects vidyanet-staging and vidyanet-prod are shared with another product. Don't touch resources that aren't Kwilo's.

Cloudflare

• Pages: kwilo-site (kwilo.ai) and kwilo-web (app.kwilo.ai). Production branch main, staging branch alias staging.
• Workers: api.kwilo.ai and api-staging.kwilo.ai proxy to the backend Container Apps (kwiloai-backend-prod, kwiloai-backend-staging). img.kwilo.ai forwards to imgproxy. t.kwilo.ai relays PostHog. The staging API worker uses redirect: 'manual' so OAuth redirects reach the browser; download the live script before editing it.
• Access (Zero Trust): gates staging and internal tools, including this docs site. For single-page apps, gate the HTML only and bypass /api/* and /assets/*, or requests fail CORS.
• DNS: zone kwilo.ai.

Releases

• Branch from staging, open PRs against staging. main is updated by periodic staging merges and is protected.
• ci-cd.yml runs the quality gate. deploy-backend-aca.yml then deploys the backend: build and push to ACR, sync Key Vault secrets, run the migrations job, start a new revision at 0 %, smoke-test it, ramp 90/10, then 100 %. Staging deploys after a green CI run on staging; prod deploys by workflow_dispatch from main.
• site-cf-pages.yml and web-cf-pages.yml deploy the frontends. ph-relay-worker.yml deploys the PostHog relay.
• Rollback: move traffic back to the previous Container App revision, or roll back the Pages deployment in the Cloudflare dashboard.

Migrations

Three Alembic chains: the main app, alembic_erp for the ERP schema, and alembic_kwilo_memory. In deployed environments the migrations job runs them before traffic moves. Locally, run the ones your change touches:

cd apps/backend
alembic upgrade head
alembic -c alembic_erp.ini upgrade head
alembic -c alembic_kwilo_memory.ini upgrade head

Mobile

Kwilo Campus (apps/mobile-b2b) releases through mobile-b2b-play.yml. Kwilo Learn ships from its own repository: see Kwilo Learn app.