Documentation

Getting started

Web Fleet is in active development. The v0.1.2 public preview is published; install it, or build the current source tree with Go.

Current status: The development build includes release automation, multi-account authentication, SQLite and PostgreSQL support. Validate the release notes for your selected version before production use.

Install, download and update

curl -fsSL https://webfleet.cv/install.sh | sh
curl -fsSL https://webfleet.cv/download.sh | sh
curl -fsSL https://webfleet.cv/update.sh | sh

The installer and downloader verify the selected release against its checksum manifest before writing the executable. The updater retains the prior binary or delegates a managed system service transition to Web Fleet.

Install with Go

go install github.com/webfleet-cv/webfleet/cmd/webfleet@latest

This builds Web Fleet from source using Go 1.23 or newer and installs it to your configured Go binary directory. Use the release installer when you prefer the published, checksum-verified binary.

The five-minute goal

The target self-hosted experience is: install Web Fleet, choose SQLite or PostgreSQL, create the first administrator, then add a website URL. The development build already follows the second and third steps, and public monitoring requires no agent or code change on the monitored website.

webfleet setup --email-file /run/secrets/admin-email --password-file /run/secrets/admin-password
webfleet serve

The release path provides checksum-verified install, download and update scripts for Linux and macOS. Until the first tag is published, these commands correctly have no stable release to resolve.

Open the dashboard, choose the database before first-admin setup, then add a site such as:

Name:     Example
URL:      https://example.com
Interval: 60 seconds

What happens after adding a site

Web Fleet schedules guarded HTTP checks, records status and latency, classifies failures, derives a fleet-level health state, tracks coherent incidents, observes TLS/DNS/header/redirect state, and runs a separate bounded crawler for page/link health. Performance history, manual browser Audit and privacy-first analytics are implemented in development. Audit never runs automatically and history is opt-in.

Adding analytics later

Analytics is deliberately separate from public monitoring. A GitHub Pages site, static Nift site or application hosted on another provider can send pageview events to one central Web Fleet server.

<script
  defer
  src="https://fleet.example.com/wf.js"
  data-webfleet="YOUR_PROPERTY_KEY">
</script>

The tracker is served at /wf.js on the Web Fleet host; the data-webfleet value is the analytics property key shown when analytics is enabled for a site in the dashboard.

The shipped default tracker does not require cookies or persistent visitor profiles. It validates the configured site origin, bounds event payloads, rate-limits attacker-reachable ingestion and stores no raw client IP address.

Next reading

Read Product overview for the product boundary, or Architecture for the implementation direction.