Skip to content
JarvisJarvis Docs

Deployment tracks

Jarvis reaches users through several independent deployment tracks. Treat each track as its own release surface: it has a different trigger, validation point, rollback path, and blast radius.

Track map

Section titled “Track map”
Track Publishes Primary audience How it goes live First validation
Local or self-hosted server FastAPI backend plus the built web frontend Developers and self-hosters Pull or deploy a source checkout, build when needed, then restart or reload the backend Health endpoint returns the expected version
Hosted web entry and documentation Public web pages, mobile web entry, and docs under /doc Users opening Jarvis from a browser Site build and provider deployment Site tests pass and key routes load
Remote access tunnel A user’s local Jarvis instance exposed through an authenticated reverse tunnel Mobile and remote clients User enables remote access from their local instance Authenticated API, SSE, and WebSocket paths reach the local backend
Package distribution and updater Desktop installers, mobile packages, and updater metadata Installed app users Maintainer-approved release workflow uploads packages and metadata Fresh install and update checks pass

Local or self-hosted server

Section titled “Local or self-hosted server”

Use this path when running Jarvis from source or maintaining a private instance. The backend serves the API and can serve the built web frontend.

From the repository root:

Terminal window
./restart.sh

Then verify the backend:

Terminal window
curl -s http://127.0.0.1:${JARVIS_PORT:-8888}/api/v1/health

The response should be JSON and include the version you intended to run. If you have multiple checkouts, confirm which port belongs to which instance before restarting anything.

Rollback is manual for this track: move the checkout back to a known-good commit or revert the bad change, rebuild any affected frontend assets, restart, and verify health again.

Hosted web and documentation

Section titled “Hosted web and documentation”

The hosted web entry and the documentation site are public static deployments. They are safer to roll back than package releases because most hosting providers keep deployment history.

For documentation changes:

Terminal window
cd services/docs-site
npm run build
npm run check:search

For hosted app or landing-site changes, run the site package tests before deployment:

Terminal window
cd services/jarvis-site
npm test

Rollback should use the hosting provider’s deployment history when available. If that is not possible, revert the source change and deploy the corrected build.

Remote access tunnel

Section titled “Remote access tunnel”

Remote access lets a phone or browser reach a user’s local Jarvis backend without requiring public inbound ports. The local machine opens an outbound reverse tunnel, and authenticated clients reach the backend through that tunnel.

Validate this track by checking the full path, not only the tunnel process:

  1. The local Jarvis backend is healthy.
  2. The tunnel is connected.
  3. The authenticated remote API reaches the local backend.
  4. Streaming and WebSocket features still work.

Rollback is operational rather than version-based. Disable the tunnel, remove the broken tunnel binding, and provision it again after the underlying issue is fixed.

Package distribution and updater

Section titled “Package distribution and updater”

Package releases have the largest blast radius because updater metadata can reach installed desktop users automatically. Treat package uploads and updater metadata as separate acceptance points.

Before publishing packages, verify:

  • version metadata is synchronized
  • packages install on the target platform
  • the app starts from a fresh install
  • the updater sees the intended version
  • download metadata points at the intended artifacts

All-platform releases may update public updater metadata. Single-platform rebuilds should keep the current version unless the release runbook explicitly calls for a full release.

If package metadata is bad, publish corrected metadata or revert to the last known-good package set. Users who already updated may need a follow-up update to return to a good build.

Public safety rules

Section titled “Public safety rules”
  • Use placeholders for hosts, account IDs, local paths, and credentials.
  • Do not publish private server names, private IP addresses, secret names with values, or local filesystem paths.
  • Keep release notes and diagnostics focused on user-visible behavior.
  • Send sensitive logs, private transcripts, and security reports through a private support channel, not public documentation.
Section titled “Related pages”