Auto-updates

The Flowstate Agent is in a transitional state on updates. Background:

• Today (v1.12.1, 2026-05-15): there is no in-agent auto-updater on any platform. Upgrading is a manual flowstate install run, which reconciles the binary, the daemon config, the CA, and the per-tool config in one shot. The command is idempotent — safe to schedule via MDM on a cadence.
• Coming on macOS (~weeks): Sparkle integration in FlowstateAgent.app for in-app silent updates. Gated on Apple notarisation of the .pkg and the .app bundle. Once it lands, every managed Mac picks up updates automatically without admin intervention.
• Coming on Windows + Linux: still in design. The likely shape is a scheduled flowstate self-update cron that checks the release manifest and re-runs flowstate install if a newer version is available — same surface as Sparkle, just on a different mechanism.

This page describes the manual workflow that works today plus the Sparkle plan for context.

Manual upgrade (works today on every platform)

Re-run the installer. That's it.

macOS / Linux:

# 1. Replace the binary (pull from your binary distribution path — typically
#    GitHub Releases on meetflowstate/flowstate-agent today).
#    <!-- TODO: switch to https://binaries.flowstate.inc once that site is updated -->

# 2. Reconcile in place.
sudo flowstate install --key="<key>" --user="<email>"

Windows (elevated PowerShell):

# 1. Install the new MSI.
msiexec /i "flowstate_windows-amd64.msi" /qn /norestart

# 2. Reconcile in place.
& "C:\Program Files\Flowstate\flowstate.exe" install `
    --key="<key>" --user="<email>"

flowstate install reads the existing /etc/flowstate.env (or the Windows registry equivalent) for --key / --user defaults if you pass them again — passing them is the simplest form, but a bare sudo flowstate install also works post-MSI as long as the values are already on disk from the prior install.

Existing sessions in flight are not lost: the daemon restart happens in ~2 seconds and any traffic mid-transfer buffers and replays on the new process.

Schedule the upgrade via MDM

For Kandji and other MDMs that re-run install actions on a cadence, simply bump the version on the Custom App (or the audit-script's expected version) and the MDM re-runs the same .pkg / MSI + the same flowstate install post-install step on every machine in the next check-in cycle. No per-version changes to the recipe needed.

The Kandji recipe at flowstate-agent/docs/mdm/kandji.md includes a worked example of the audit script that triggers re-install on version bump.

For Ansible / Puppet on Linux:

# Ansible — bump flowstate_version and re-run the play.
vars:
  flowstate_version: "v1.12.2"   # bumped from v1.12.1

For Intune on Windows: bump the Win32 app's detection version, re-upload, re-assign — Intune installs the new version on the next sync.

Sparkle integration (coming on macOS)

Once Apple notarisation lands for the .pkg + .app bundle, the FlowstateAgent.app host app on macOS uses Sparkle for silent in-app updates. The shape:

1. FlowstateAgent.app polls a Sparkle appcast feed (the URL is written into <data-dir>/update.json by flowstate install; defaults to the project's stable appcast).
2. New release detected → the .app downloads the signed update archive in the background.
3. Update applies on the next process restart (or on next launch if the user has the app open).
4. The Go daemon and the menubar app upgrade in lockstep.

You'll be able to:

• Override the appcast URL with flowstate install --appcast-url=<url> for staging / on-prem mirrors.
• Pin a specific version via a Flowstate-managed agent policy (the same surface that exposes the org-scope key today will gain a "pinned version" field).
• Disable Sparkle entirely for environments that own their binary distribution (Munki, internal mirror) by leaving the appcast URL empty.

These knobs do not exist yet on the customer-facing UI. Watch the changelog for the GA announcement.

What happens when the agent is offline

The agent caches its last-known org key and configuration locally. If the daily poll to the cloud proxy fails (no connectivity, server unreachable), the agent keeps operating with the previous values — capture and forwarding continue, sessions queue locally, and flush when connectivity returns.

There is no fail-open / fail-closed behaviour to choose: the agent never reaches more permissive defaults on a failure, only the values it last successfully retrieved.

Disabling updates entirely

For environments that own the binary distribution themselves (Munki, internal mirror, hand-built images), Sparkle (once shipping) will be toggled off via the agent policy. Until Sparkle ships, "disabling updates" is the trivial case: you control when to re-run flowstate install, so nothing happens until you say so.

Roadmap

• v1.12.1 (2026-05-15): MSI archive naming + goreleaser hardening for the .pkg pipeline. Manual upgrade only.
• v2.0.0 (in progress): WinDivert SHA256 fix + first signed .pkg builds. Sparkle integration enabled in FlowstateAgent.app on macOS once Apple notarisation completes.
• TBD: scheduled self-update on Linux + Windows, with the same policy surface (pin, channel, maintenance window) Sparkle gets on macOS.