Deployment & environments

Frontier’s operational integrity relies on a well-defined deployment strategy across multiple environments, ensuring stability, quality, and rapid iteration. This page outlines the deployment pipeline, the various environments, and how each component of the Frontier system is released and managed.

Environments

Frontier uses several distinct environments to manage the development, testing, and release lifecycle:

• Local: An engineer’s machine. The frontend and Next.js dashboard run locally, while the Call Server typically runs via wrangler dev --remote — so local code executes against real, remote Cloudflare bindings (D1, R2, KV, Vectorize, AI) rather than local simulations, giving high-fidelity local testing. A dedicated Doppler local config supplies secrets.
• Dev: The shared remote development target (Doppler dev config); used for integration work beyond a single machine.
• Preview: Ephemeral environments created automatically for each pull request, allowing for isolated testing of feature branches.
• Demo: A stable snapshot environment for demos — its own Doppler demo config, its own Cloudflare Worker suffixes (-demo), D1 (call-agent-db-demo), and a separate Vercel project for the dashboard — so sales/demo activity is isolated from staging QA and production.
• Staging (Stg): Automatically deploys on every merge to the main branch. It serves as a continuous integration target and the primary environment for QA testing.
• Release Candidate (RC): A manually dispatched environment that pins a specific code SHA for final, focused quality assurance before a production release. Used because staging is a moving target, allowing for a stable QA snapshot.
• Production (Prd): The live, customer-facing environment, manually dispatched from either Staging or RC after successful validation.

Caution

The RC environment shares the staging Supabase database. This means any database migrations run in RC will also affect the staging database, posing a risk of impacting concurrent staging QA activities if a destructive migration were to occur.

Deployment Workflow

Frontier’s continuous integration and continuous delivery (CI/CD) pipeline is driven by GitHub Actions workflows.

All non-development deployments leverage a blue/green deployment strategy for Cloudflare Workers. New worker versions are uploaded to Cloudflare with 0% traffic, smoke-tested using a Cloudflare-Workers-Version-Overrides header, and then, if tests pass, promoted to 100% traffic. If smoke tests fail, traffic is never shifted, eliminating the need for an explicit rollback step.

D1 and Supabase Drizzle database migrations are executed in parallel before smoke tests for each deployment, ensuring the database schema is updated prior to testing the new application version.

Deployments for Staging occur automatically on every push to the main branch. Release Candidate, Demo, and Production deployments are manual, triggered via workflow_dispatch. CI deploy jobs run on Blacksmith runners, while desktop application builds run on macos-latest GitHub Actions runners. Pre-checks (type-checking, linting, and callable-registration tests) run concurrently with worker uploads as a secondary safety net.

GAP — founder supplies

Latency, throughput, uptime, SLO, cost figures, and DORA-style metrics (lead time, deploy frequency, MTTR) for any environment or deploy step are not currently available.

Application Deployment Details

Call Server

The Call Server is an orchestrated set of six Cloudflare Workers deployed together as a single unit per environment: the main call-agent worker, and companion workers for logging, script-completion, faq-detection, question-detection, and transcript-orchestration.

The call-agent worker hosts six Cloudflare Durable Object classes: call-agent, call-chat-agent, quick-answer-agent, websocket-relay, org-answer-agent, and call-answer-agent.

Production deployments use bare worker names (e.g., call-agent), while Staging, RC, and Demo environments use -[env] suffixes (e.g., call-agent-stg). For preview deployments, each pull request automatically deploys six csa-{branch} workers for isolated testing.

Caution

During Cloudflare Worker promotion, if one of the six workers fails to promote, any earlier successful promotions are not automatically rolled back. This could leave the system in a mixed-version state where some workers are updated and others are not.

If a pending Durable Object migration blocks a blue/green versions upload (due to Cloudflare error 10211), the deployment process falls back to a full wrangler deploy. This immediately pushes the new version to 100% traffic, meaning smoke tests then run against an already live production system.

Dashboard

The Dashboard (@frontierx/dash), built with Next.js, is deployed to Vercel. Deployments utilize the Vercel CLI (vercel pull/build/deploy) and vercel alias to cut over domain names only after successful smoke tests. Each environment has a dedicated domain (e.g., dash-stg.frontierxai.com, dash.frontierxai.com for production). The Demo dashboard specifically uses a separate Vercel project from the main dashboard project.

Docs Site

The Frontier documentation site has two components:

• The original site (@frontierx/docs-site) is deployed to Cloudflare Pages project frontierx-docs.
• A newer Astro Starlight site (@frontierx/docs) is deployed as a Cloudflare Worker.

Caution

The deploy-docs.yml workflow is configured to trigger on changes to the new Astro Starlight docs site (apps/docs/) but then deploys the older Cloudflare Pages site (apps/docs-site). This configuration discrepancy means changes to the current Astro Starlight documentation will not be deployed by the automated workflow.

Desktop Client

The Desktop client (@frontierx/desktop) is an Electron application for macOS. Development and Demo builds are unsigned, while Staging, RC, and Production builds are Apple-signed and notarized for security and user trust. Per-environment product names (e.g., Frontier-Dev, Frontier-RC, Frontier) allow multiple installations to coexist on a single machine.

Release builds are uploaded to environment-specific Cloudflare R2 buckets (e.g., frontierx-app-prd), which serve as the source for the application’s auto-update feed (e.g., download.frontierxai.com). Production desktop versions are strictly derived from the latest prd-desktop-v* git tag, with CI configured to hard-fail if this tag is missing, preventing unintended versioning.

Caution

While Windows desktop builds exist, there is no evidence of a signed, published release pipeline or an auto-update feed for the Windows version of the Desktop client.

Secrets and Feature Flags

Secrets across all environments are managed using Doppler (project frontier-x). Each environment (dev/local, preview, demo, stg, rc, prd) has a dedicated Doppler configuration, and secrets are injected into the GitHub Actions environment at deploy time via the dopplerhq/secrets-fetch-action.

Feature flags are also managed via Doppler-supplied environment variables. Key flags include:

• USE_DIRECT_AUDIO: This flag gates the new direct microphone and speaker audio capture path, which streams directly to Deepgram for transcription. This is part of Frontier’s migration away from reliance on the deprecated Recall cloud-bot for audio capture.
• USE_DIRECT_AI: Controls direct AI integration.
• USE_WEBSOCKET_RELAY: Governs the use of the WebSocket relay for real-time traffic.
• TRANSCRIPTION_PROVIDER: Specifies the transcription service to use.
• QA_FAST_ANSWER_MODEL, QA_REFINEMENT_MODEL, QA_QUERY_REWRITE_MODEL, and QA_RERANKING_ENABLED: These flags control various aspects of the quick-answer AI models and their retrieval mechanisms.

For a feature flag to be enabled, its environment variable must be explicitly set to a truthy value (e.g., 'true', '1', or 'yes').

Caution

The transition to direct audio transcription (USE_DIRECT_AUDIO) involves parallel implementations in the Dashboard, HUD, and Call Server. Maintaining consistent flag parsing and behavior across these independent components is critical to avoid drift and ensure reliable functionality.