Purpose and production hosts
Orvexa AI uses separate hostnames for distinct responsibilities while keeping the documentation and web application in one Next.js deployment. The public website explains the product, the clinic app handles authenticated work, the documentation teaches each workflow, and the API performs server-side operations.
- orvexaai.cloud serves the public website and clinic application.
- docs.orvexaai.cloud serves this documentation portal through hostname-based routing in the same Netlify site.
- api.orvexaai.cloud serves the production backend API.
- Development hosts and production hosts must never share production credentials by accident.
Deploy the web application and documentation
Netlify builds the frontend from the frontend directory with npm ci and npm run build. The documentation hostname is added as a custom-domain alias on the same Netlify site. DNS points docs.orvexaai.cloud to that site's netlify.app hostname, and the application proxy routes documentation-host requests into the docs portal.
- Merge reviewed work into the production branch.
- Confirm the Netlify production context contains the required public environment variables.
- Let Netlify complete the Next.js production build before changing traffic.
- Verify both orvexaai.cloud and docs.orvexaai.cloud after deployment because they share one release.
Environment variables
Public frontend configuration is injected during the Next.js build. NEXT_PUBLIC_APP_URL names the main website, NEXT_PUBLIC_DOCS_URL names the documentation host, and NEXT_PUBLIC_API_URL names the backend. Supabase public configuration enables browser authentication. Values prefixed with NEXT_PUBLIC are visible to browsers and must never contain secrets.
- Production app URL: https://orvexaai.cloud
- Production docs URL: https://docs.orvexaai.cloud
- Production API URL: https://api.orvexaai.cloud
- Keep service-role keys, signing secrets, vendor credentials, and private API keys out of frontend variables.
Deploy the API
The FastAPI service is deployed independently from the Netlify frontend. It owns authenticated business operations, clinic scoping, integrations, report generation, billing coordination, and readiness checks. Frontend deployments should not silently change the API contract.
- Run backend tests before releasing backend changes.
- Apply reviewed database migrations through the production migration workflow.
- Keep allowed origins aligned with the production web hosts.
- Verify the readiness endpoint before directing frontend traffic to a new backend release.
Release checklist
A release is complete only when the built application, documentation host, API, authentication redirects, and critical clinic workflow have been checked together.
- Run frontend tests, lint, TypeScript checks, and the production build.
- Open the website and documentation at mobile, tablet, and desktop widths.
- Verify sign in, dashboard access, one clinic data read, and a safe sign out.
- Confirm documentation navigation stays inside the documentation portal.
- Check that no patient data, credentials, or production secrets appear in build output or logs.
- Use the previous Netlify deploy and backend release as the rollback points.