v0.22.1

Gateweave Cloud's Agents now keeps its database in the EU. Nothing changes for a copy you run
yourself, and this release has no migration.

Changed

• Gateweave Cloud's database is in the EU. agents.gateweave.com's D1 database (accounts,
  sessions, the list of workspaces) moved to one created with Cloudflare's eu jurisdiction, which
  guarantees where it runs and stores data. The old one was in Eastern North America. Everything was
  copied over, including what was written while the release deployed. Staging moved first.
  Workspaces' registries and conversations live in Durable Objects, which move separately.
  (#220, #221)

If you run your own

• Nothing to do. The top level of wrangler.jsonc, which is what you deploy, is as it was; only
  the cloud and staging environments changed.

v0.22.0

Admins can now see who changed their workspace, and when. This release has one D1 migration.

Added

• Audit log. Settings has a new Audit log page for owners and admins. It lists who invited,
  removed or promoted whom and who joined or left; who saved or removed a model key, set or removed
  a secret (by name, never its value) or changed an environment set or telemetry; who connected or
  disconnected GitHub, GitLab or an MCP server, and who changed a trigger or set up Track triage
  or Track work; who created, changed or deleted an agent, a team or a setup, and who had a setup
  open a pull request; and who deleted a project or a library asset. The newest come first. It
  names people as the server knows them now, so someone who deleted their account appears as
  "Deleted member". Entries are kept for a year. Chats, scans and runs are not in it.
  (#218)

If you run your own

• pnpm run deploy applies the migration (0011_audit_log) before the new code goes live.
• The log holds the addresses invitations went to, for a year, and forgets one when that person
  deletes their account. If your privacy policy lists what Agents keeps, add it; see Audit log in
  docs/architecture.md.

v0.21.0

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

Added

• A way in for backups. D1 can be backed up from outside the Worker, but a workspace's registry
  and its conversations live in Durable Objects only the Worker's own code can read. The Worker now
  exports a named entrypoint, Backup, for a backup Worker such as Gateweave Backup's. It lists each
  workspace's registry and conversations, 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 reads
  only what D1 and the registry still list, so a deleted conversation is never woken. It has no
  route: only a Worker in the same account with a service binding to it can call it.
  (#216)

If you run your own

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

v0.20.0

AI agents can ask a repository's wiki a question over MCP, at no cost to the workspace. There is no
migration in this release.

Added

• ask_wiki_question. It takes DeepWiki's arguments: a repository, or a list of up to 10, and a
  question. It answers with the pages of their wikis that bear on the question, best first. No model
  runs on the server: the agent that asks reads the pages and answers, so a question needs no key
  and costs the workspace nothing. (#212)
• list_wiki_repos. It lists the repositories with a wiki in your workspaces, with how many
  pages each has and the commit it was written from.
  (#212)

If you run your own

• Nothing to do for this release.

v0.19.0

A wiki of each repository, written with the workspace's own model key, and an MCP endpoint that AI
agents sign in to with OAuth to read it, with the tools DeepWiki has. This release has one D1
migration and one Durable Object migration.

Added

• Repository wikis. An owner or admin has a wiki written for any repository the workspace
  connects, private ones included, on the new Wiki page or from a repository's page. They choose
  a model from a provider the workspace has a key for. Every member reads it: numbered pages with
  the source files each was written from, citations linked to those lines at the commit, and the
  model, tokens and estimated cost. .devin/wiki.json steers it as it steers DeepWiki. Writing again
  keeps the current wiki readable until the new one is done, and a wiki that can't be written says
  why. (#210)
• An MCP endpoint for AI agents. /mcp lets an AI agent work with Agents as the person who
  connected it. It signs in with OAuth, and the person approves it on a consent page. Its tools
  only read: list_workspaces, and read_wiki_structure and read_wiki_contents, which keep
  DeepWiki's names, arguments and answers. An agent set up for DeepWiki's MCP server reads a
  workspace's wikis unchanged. It never takes a browser's session cookie.
  (#208,
  #210)

If you run your own

• Deploying creates the wiki Workflow, gateweave-agents-wiki, and applies D1 migration 0010
  for the OAuth server. The workspace registries add their wiki tables when each one wakes.
• /mcp needs BETTER_AUTH_URL. Tokens are bound to one address, so without it /mcp answers
  404 and nothing else changes.
• The workspace slugs mcp and oauth are now reserved, so no new workspace takes them. The
  new routes would hide pages of a workspace that already has one, so check before you update:
  SELECT slug FROM organization WHERE slug IN ('mcp', 'oauth') on the D1 database.
• Model usage stays the workspace's. A wiki costs the workspace one model request to plan it and
  one per page, with its own key.

v0.18.0

The account that 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 on a server until its owner changes it.

Added

• Sign-up by invitation, with a list. The account that runs the server sees a section, This
  server, on its account page. Choosing By invitation there lets in only addresses on the
  owner's list (ada@example.com) or at a domain on it (@example.com, which covers that domain and
  not its subdomains), addresses with a pending invitation to a workspace, and, where the owner turns
  on Trust, anyone who signs in through the server's OpenID Connect provider. GitHub is never
  trusted that way. Everyone else is told the same words, however they come and whether or not the
  address has an account. The list holds up to 5,000 entries with notes, shows whether an account
  exists yet for each, and changing anything needs a sign-in from the last day. A trigger in D1 holds
  the same rule for any path that makes an account. (#205)
• Ask for access. If SIGN_UP_REQUEST_URL is set to an https address, the sign-in pages link to
  it as "Ask for access" while sign-up is by invitation. Gateweave Cloud points it at its waitlist.
  (#205)
• A server always has an owner. While sign-up is by invitation, the owner's account can't be
  deleted, since nobody else could open sign-up again. On an open server, deleting it passes
  ownership to the oldest account left. (#205)

If you run your own

• Nothing changes unless you change it. An upgrade leaves a server with accounts open, with its
  oldest account as the owner. Deploying applies migrations 0006 to 0009.
• The list holds addresses of people who may not have an account yet. The self-hosting guide says
  so, for your own privacy notice. (#205)

v0.17.0

A ready-made setup for Gateweave Mail, and applying a setup now merges into a repository's .vscode/mcp.json instead of
replacing it. There is no migration in this release.

Added

• A ready-made Gateweave Mail setup. It adds Mail's skill and MCP server to a repository, for Claude Code, Codex,
  Gemini CLI, Cursor and GitHub Copilot, so their agents can read sign-up codes, wait for mail and send it. Adding it
  asks for your Mail's MCP address. The agent's key is read from GATEWEAVE_MAIL_KEY and never written to the
  repository. The setup has no instructions, so it leaves a repository's AGENTS.md and CLAUDE.md alone.
  (#202)
• A setup can ask for an MCP server's address. For a server that every install runs at its own address, an
  askUrl in setup.json makes the Setups page ask for it when the setup is added. The address is checked as one
  typed on the MCP page is. The CLI takes it as --url <server>=<url> from its next release.
  (#202)

Fixed

• Applying a setup no longer replaces .vscode/mcp.json. It replaced the whole file, so the repository's other
  servers and its inputs were lost. Only the setup's own servers are merged in now, as in the other MCP files.
  (#202)

If you run your own

• Nothing to do for this release.
• CI's browser tests install Chromium alone when Ubuntu's package mirror can't be reached.
  (#203)

v0.16.6

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. (#196)

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. (#194)

v0.16.5

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. (#190)

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. (#189)

v0.16.4

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. (#187)

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.