Deployment

This page describes CertWatch's own hosting for context — it isn't a guide to deploying CertWatch yourself; there is no self-hosted distribution today.

The product

CertWatch runs on Fly.io. The marketing site (certwatch.sh) and the authenticated app (app.certwatch.sh) are one deployment that renders differently by hostname. Keeping those two product surfaces together avoids a second auth, cookie, CORS, and preview boundary while they share the same API and release cadence. A separate scheduled process runs the actual TLS/domain checks and alert delivery. Every change goes through an ephemeral per-pull-request preview environment before reaching production.

This docs site

docs.certwatch.sh (issue #220) is an intentionally separate, independently built and styled static site — its own directory (docs-site/) in the CertWatch repository, with its own build and test commands, not bundled into the app's frontend build. That separation is deliberate: documentation should not share a deploy pipeline, an outage, or a release cadence with the product it's documenting. If Fly.io is used, it should be a minimal static-only app with no database, API, authentication, or checker process. A static host such as Cloudflare Pages is also a reasonable alternative.

Current status: the site you're reading is built and testable in-repo, but the docs.certwatch.sh DNS record, TLS certificate, and Fly (or equivalent static-hosting) deployment have not been provisioned yet — see the repository's docs/DEVELOPMENT.md for the exact steps a maintainer still needs to run.

Releases

The product ships through pull requests merged to a shared integration branch, then promoted to production via a short-lived release branch — every change is reviewed, tested, and deployed to a preview environment before it reaches real accounts.