v0.34.1

Gateweave Cloud's Track now keeps its database and attached files in the EU. Nothing changes for
a server you run yourself, and there is no migration in this release.

Changed

• Gateweave Cloud's database and files are in the EU. track.gateweave.com's D1 database and
  its bucket of attached files moved to ones created with Cloudflare's eu jurisdiction, which
  guarantees where they run and store data. The old ones only had an Eastern Europe location hint,
  which does not. Everything was copied over, files with their type and uploader, including what
  was written while the release deployed. Workspaces live in Durable Objects, which move
  separately. Staging moved first. (#280, #281)

Fixed

• pnpm dev:seed works again when local email is on. It used to stop at the first invitation,
  because the sample people have no mailbox to verify their address with. (#279)

If you run your own

• Nothing to do. The top level of wrangler.jsonc, which is what you deploy, is as it was;
  Gateweave Cloud's production now deploys its own cloud environment.
• If your FILES binding names a bucket in a jurisdiction, pnpm run deploy now creates a
  missing bucket in that jurisdiction too, instead of an empty one outside it. (#281)

v0.34.0

Admins can now see who changed their workspace, and when. Each workspace adds the table for it
itself when it next wakes; there is no D1 migration in this release.

New

• Audit log. Settings has a new Audit log page for admins. It lists who invited, removed or
  promoted whom, who joined or left, who added, renamed or deleted an agent or made or revoked its
  keys, who changed a team's name, key, cycles, automations, request form or intake email, who
  changed statuses, webhooks or GitHub connections, and who deleted labels, projects, issues or
  someone else's comment. The newest come first. The log keeps a deleted issue's key but not its
  title, and a webhook's host but not the rest of its address. It names people as the workspace
  knows them now, so someone who deleted their account appears as "Deleted member". Entries are
  kept for a year. Only admins can read it. (#277)

If you run your own

• The log holds the addresses invitations went to, for a year. If your privacy policy lists what
  Track keeps, add it; see Audit log in docs/architecture.md.
• Deploys can now check themselves. pnpm test:smoke with TRACK_SMOKE_URL set opens a
  deployment from outside and checks that sign-in, the service worker, sync and /mcp answer as
  they should. Gateweave Cloud's deploys run it after each environment goes live; see Checking a
  deployment in docs/self-hosting.md. (#276)

v0.33.0

Track can now send notifications to people's phones and computers. This release has two
migrations, one in D1 and one in each workspace, and push stays off until the server has a key for
it.

New

• Push notifications. Anyone can turn on push in Settings, Notifications, on each phone or
  computer they use Track on. News from their inbox that they get by email then also reaches those
  devices as it happens, one notification per issue, and a click opens the issue. News read in Track
  first is not pushed, and the email still follows ten minutes later if it stays unread. Each
  message is encrypted so that only that browser can read it, and passes through the browser's own
  push service: Google's for Chrome, Mozilla's for Firefox, Apple's for Safari, Microsoft's for Edge.
  Signing out on a device turns push off there. On iPhone and iPad, push works once Track is added
  to the Home Screen. (#274)

If you run your own

• To turn push on, make the key your server signs pushes with and set it in one go, so it is
  never shown: node apps/web/scripts/push-key.mjs | pnpm wrangler secret put PUSH_VAPID_KEY.
  Keep the key: a new one makes everyone turn push on again on each device. Name the browsers' push
  services in your privacy policy; see Push notifications in docs/self-hosting.md.
• pnpm run deploy applies the D1 migration (0014_push_subscription). Each workspace adds its
  own column when it next wakes.

v0.32.0

A backup Worker in the same Cloudflare account can now back up every workspace. There is no
migration in this release, and nothing changes until such a Worker binds to it.

New

• A way in for backups. D1 can be backed up from outside the Worker, but a workspace's Durable
  Object can't: only Track's own code reads its SQLite. The Worker now exports a named entrypoint,
  Backup, for a backup Worker such as Gateweave Backup's. It lists the workspaces and runs a SQLite
  dump's reads in one, inside a transaction it always rolls back, so a backup sees one moment and
  can change nothing. It has no route: only a Worker in the same account with a service binding to
  it can call it. A name that isn't a workspace answers null, so a backup never makes an empty
  one. (#272)

If you run your own

• To back up your workspaces, bind a backup Worker to the entrypoint
  ("services": [{ "binding": "TRACK", "service": "<your Worker>", "entrypoint": "Backup" }]); see
  Backups in docs/self-hosting.md. The copies it makes hold your workspaces' issues and comments:
  keep them as you keep the database.

v0.31.0

The person who runs a server can now close sign-up and keep a list of who may make an account.
This release has four migrations, and nothing changes until the owner closes sign-up.

New

• Who runs this server. Track now knows its server's owner: the oldest account that is a person,
  or on a new server the first account made. The owner gets a This server section on the account
  page. Changing anything there asks for a recent sign-in. If the owner deletes their account while
  sign-up is open, the next oldest person becomes the owner. ([#269])

• Closed sign-up and the owner's list. The owner can close sign-up. Then an account can be made
  only by:

  • an address on the owner's list, or at a domain on it (@example.com covers that domain, not its
    subdomains); the list has notes, a search and room for 5,000 entries, and shows whether each
    entry has an account yet;
  • an address with a pending invitation to a workspace, as before;
  • if the owner turns on Trust for it, the OpenID Connect provider Track is set up with, such as
    Gateweave ID, which keeps its own list. GitHub is never trusted this way.

  Every way of making an account (password, GitHub, OpenID Connect, invitations) gives the same
  refusal, and says nothing about which addresses have accounts. The database holds any other path
  to the same rule. ([#269])

• Ask for access. If SIGN_UP_REQUEST_URL is set to an https address, the sign-in page links to
  it while sign-up is closed. ([#269])

If you run your own

• Nothing changes unless you close sign-up. Deploying applies migrations 0010 to 0013 and
  makes your oldest account the owner. Check that it's yours before you close sign-up. To hand the
  server to someone else, change owner_id in the deployment table.
• The list holds addresses of people who may not have an account yet. It is personal data in
  your D1 database (sign_up_allow). Mention it in your own privacy notice. ([#269])
• pnpm dev:seed needs sign-up open, since it signs its sample people up through the API.

v0.30.7

A changed webhook stops retrying what it no longer wants. There is no migration in this release.

Fixed

• Changing a webhook drops what it no longer wants. Pausing a webhook already failed what it had yet to deliver, but changing its teams, events or agent dropped nothing: deliveries about a team taken off it, or of an event it stopped listening to, kept being retried to the receiver for up to about 17 hours. Each waiting delivery is now checked against the webhook as it is, and those it would no longer send fail with a reason its settings show. A delivery waiting its turn goes out with the webhook's URL and secret as they are when it is sent. (#265)

Changed

• Dependencies are up to date, among them Better Auth 1.7.18, Vite 8.3.6 and Wrangler 4.158. (#266)

v0.30.6

Webhooks to a host on your own zone now come in through Cloudflare. There is no migration in this release.

Security

• Webhooks reach your own zone as anyone's requests do. A request from the Worker to another host on its own zone went straight to that host's origin, past the security settings in front of it, such as Access or the WAF. A webhook's URL is the choice of whoever owns a workspace, so the Worker now runs with the global_fetch_strictly_public compatibility flag, and such a request comes in through Cloudflare like anyone's. A URL naming Track's own host with a trailing dot is refused, as the host itself is. (#263)

If you run your own

• Deploy, and keep the flag. It is in wrangler.jsonc. If you keep compatibility flags of your own elsewhere, add global_fetch_strictly_public to them. Requests to GitHub and to sign-in providers elsewhere are unaffected, and a provider on your own zone served by a Worker on a Custom Domain is reached as before. One on your own zone behind Access or a WAF rule now meets those rules, as a request from anywhere else would.
• pnpm install no longer pulls in a flagged version of esbuild through drizzle-kit, which only makes migrations. (#258)

v0.30.5

Whoever runs a server with no email can now help someone back in. There is no migration in this release.

Fixed

• A way back in without email. Without email nobody could reset a forgotten password, and /forgot-password told them to ask whoever runs the server, who had nothing to do about it. The self-hosting guide now says how: find the person's id in a list, run one statement, and pass on the link it prints. The link works once, for an hour. Using it signs the person out everywhere, as a reset does with email. (#256)

If you run your own

• Nothing to do for this release. Nothing changes on a server that sends email.
• CONTRIBUTING.md now says where a newcomer can start. (#255)

v0.30.4

People now hear by email when the tries at their password run out. There is no migration in this release.

Security

• An email when the tries at a password run out. Whoever holds a copy of a session can use up the person's allowance, which keeps them from changing their password in settings for a while. They now get an email at the first refusal, saying what happened and what to do, at most once a day and only at an address they have verified. The refusal doesn't wait for it, and it is the same as before. (#250)

If you run your own

• Nothing to do for this release. With no email set up, nothing changes.
• The self-hosting guide now says where your database lives and how to choose. A D1 database stays where it was made, so this is worth reading before your first deploy. (#249)

v0.30.3

Reading a session takes one trip to the database instead of two. There is no migration in this release.

Performance

• One query fewer each time a session is read. Better Auth read the session, then the person, as two queries, and each is a trip to D1's primary from wherever the Worker runs: measured at about 19 ms from Frankfurt, 109 from Virginia, 240 from Tokyo and 290 from Sydney with the primary in Eastern Europe. Opening a socket and fetching a snapshot now make two reads instead of three. (#247)

If you run your own

• Where your database lives matters more than this does. A D1 database stays where it was created, and every read and write of a session goes there. Nothing to do for this release, but if your people are far from it, that is where the time goes.