v0.2.1

A patch, which here means exactly one thing: ./upgrade.sh and nothing else.
No migration, no new variable, no change to the tracker.

git fetch --tags && git checkout v0.2.1
cd infra/selfhost && ./upgrade.sh

The revenue switch now means what the screen says

v0.2.0 shipped the per-site switch that decides whether a payment is tied back to
the visit that produced it, and it closed the half a browser can reach: the
tracker stopped sending the order reference for a site with the switch off.

Two of the three signals that link a payment never pass through a browser. A
checkout reference and an identity on the payment object travel from a site's own
server to the provider and reach us on a webhook, so a site could switch linking
off, watch the change take effect in its own network tab, and still find journeys
appearing. A setting that describes the browser while the product does something
else is worse than no setting.

Both halves are closed here. The collector drops a linking hint that arrives for
a site with the switch off, whatever sent it, and counts what it removed, so a
page still serving a bundle cached from before the flag existed is visible rather
than silent. The attribution job reads the switch once, above every read it
gates, so a fourth signal cannot be added past it by accident later.

Three things this deliberately does not do:

• Revenue figures do not move. Totals, per-day, per-hour, refunds, disputes
  and fees are read from the payments themselves. The switched-off path still
  runs the rollup and still advances the watermark, and a test asserts the
  buckets written are identical with the switch in either position.
• Nothing already recorded is deleted. Journeys from before the switch went
  off stay in the dashboard. Turning a setting off is not an erasure request.
• Turning it back on reaches back a month, not further. The matcher re-reads
  roughly the last 31 days on its next pass, which is the horizon it already had.

The settings screen and the Stripe connect flow now say all three, because
somebody deciding this needs to know that their revenue is not what is at stake.
/docs/revenue carries the same account.

Self-hosting, corrected from a real run

infra/selfhost/docker-compose.keys.yml was documented as unverified. It has now
been run on a real host: keys are generated once and a redeploy does not rotate
them, the modes and ownership hold on fresh volumes, and a service started before
its key exists refuses to start with the reason on the line and then recovers on
its own. Two behaviours are written down rather than left to be discovered:

• Services waiting on the one-shot keygen step can be left Created rather
  than started once it finishes. A second docker compose up -d starts them.
• The two Valkey addresses are pinned rather than allocated, so a recreate can
  ask for an address the container it replaces is still holding and stop with
  Address already in use. Run the same command again. Deleting the
  ipv4_address lines is the wrong fix: the connection factory rejects a
  plaintext redis:// on a service name, and the queue would not come up at all.

Images

Eight, published to ghcr.io/openlabs-so/openanalytics and tagged v0.2.1:
migrate, tracker-build, api, collector, worker, query-gateway,
realtime, web. amd64. On arm64, build them instead: same compose file, one
flag.

infra/selfhost/docker-compose.coolify.yml moves its pin to v0.2.1 with the
tree. Still not a supported path, and now for a named reason rather than an
unexplored one: without the compose network it has no private address to give
the Valkey URLs, and the connection check refuses a plaintext redis:// on a
service name. The file says so at the top, with the three ways out.

Migrations do not go down. ./upgrade.sh takes the snapshot ./rollback.sh
needs before it starts, and a rollback discards everything recorded after it.

RELEASING.md
is what a version number here means.

Full changelog: v0.2.0...v0.2.1