Skip to main content
Wintertrace
Browse the documentation

Self-hosting & operations

Updates & cron in operation

What the single per-minute cron job does, how signed auto-updates work, and why no long-running background process is required.

Two things matter in ongoing operation: keeping the software current without needing a command line, and making sure background tasks run reliably. Both are designed to work on ordinary shared hosting without SSH access.

The auto-update system

Wintertrace includes an integrated update system that keeps the software current even without SSH. The process:

  1. Wintertrace checks the update server for new versions once a day automatically (configurable; can be disabled entirely).
  2. If a new version is available, it appears in the admin dashboard — with the version number and changelog.
  3. The admin decides whether and when to install. Updates are never applied automatically.
  4. On confirmation, the update is downloaded, verified, and installed. During installation the application enters maintenance mode briefly.
  5. Database migrations run automatically as part of the process.

The cryptographic checks

Every update passes through several checks before it is applied. The reason: an update mechanism that installs from the internet on a single click is only acceptable if it cannot be tampered with.

  • Ed25519 signature check: Every update manifest is digitally signed. A root key embedded in the software verifies authenticity.
  • Trust list with key rotation: The server can rotate signing keys without requiring a code update. Compromised keys can be revoked immediately.
  • SHA-256 checksum: The downloaded file is compared byte-for-byte against the signed checksum.
  • Rollback protection: A monotonically increasing counter prevents older versions from being offered as updates.

Neither the transport layer nor the update server can deliver a tampered update as long as the root key is secure. The same signature logic is used by modules — see Module signing & distribution.

Keeping full control

  • Updates are never installed automatically — the admin decides.
  • The automatic check can be disabled entirely.
  • A backup is recommended before each update; the integrated help explains how. For automated backup targets there is additionally the module-level backup system (see Storage & backup).
  • If an installation fails, the software remains in maintenance mode and can be retried at the next attempt without data loss.

The same feature seen from an operator’s perspective is covered on the Auto-updates page.

The one cron job

Beyond updates, Wintertrace needs only one running prerequisite: a single cron job that executes every minute. All background tasks are scheduled from it:

  • Fetch weather data — automatically at the start and end of each service job
  • Send email notifications — asynchronously after a job is completed
  • Data retention — aggregate and remove expired job records after the configured retention period
  • Update check — daily check for new versions
  • Cron heartbeat — status check to confirm the cron is running correctly

No daemon, no root access

Unlike many server applications, Wintertrace does not require a permanently running background process. Instead of a queue:work daemon — which a shared host would terminate after a few minutes — Wintertrace processes all pending tasks on each cron run and then exits cleanly. This works reliably on any web hosting that supports cron jobs.

Fault tolerance

If the cron job misses a run — for example because the hosting was briefly unavailable — no data is lost. Service jobs continue to be recorded correctly; weather data and notifications are processed on the next successful run. The cron heartbeat surfaces a persistent outage in the dashboard so you notice it before it becomes a problem.