Environment variables for functions, sites, and projects can now be created, listed, retrieved, updated, and deleted programmatically through the Appwrite Server SDKs. Two new API key scopes, project.read and project.write, control access to the project-scoped endpoints, alongside the existing functions.* and sites.* scopes for resource-scoped variables.
This enables configuration as code, one-place rotation of secrets shared across multiple resources, and repeatable bootstraps of new environments and tenants from scripts or templates.
Appwrite Realtime now keeps a single WebSocket per client session and applies incremental, message-based subscription changes instead of encoding subscription state mainly in the connection URL and reconnecting for every add or remove.
Previously, subscription details were often encoded in the WebSocket URL query string. That tied you to URL length limits in browsers, proxies, and servers, which capped how many channels you could combine and how much metadata you could send on one connection. It also squeezed Realtime queries for server-side filtering, because every extra filter still had to fit in the same limited URL. Channels and queries are now carried over the open socket, so you are not constrained by query-string size the same way.
In client SDKs, you can now:
Per-subscription lifecycle: Call unsubscribe() on a subscription handle to stop that listener only; other subscriptions on the same Realtime instance keep running.
update(): Change channels and queries on an existing subscription in place, without recreating the client.
disconnect(): Close the WebSocket and drop every active subscription in one call when your app is done with Realtime (for example on component unmount).
Together, the Realtime protocol change and matching SDK APIs reduce unnecessary reconnects, make UI-driven subscription changes easier to reason about, and move subscription state off the WebSocket URL onto incremental messages over the open connection.
Read the announcement on the blog for context and examples, and see the Realtime documentation for how this maps to your platform.
The Appwrite CLI 19.1.0 adds dedicated flags for filtering, sorting, and pagination on list-* commands, so you no longer need to hand-write Appwrite query JSON for --queries on common one-offs.
The new flags include --where, --sort-asc, --sort-desc, --limit, --offset, --cursor-after, --cursor-before, and --select. The --queries flag is still supported and is combined with the new flags when both are used. See the 19.1.0 release notes for more details.
We have raised the maximum build duration for Sites and Functions on Appwrite Cloud from 15 minutes to 45 minutes for organizations on the Pro plan and above. Free plan organizations keep the 15-minute build limit, so the longer window is an explicit benefit of upgrading when your workloads need it.
Build pipelines are rarely constant-time: cold dependency caches, larger lockfiles, native compilation, first-time container layer pulls, and multi-stage bundling can push wall-clock time well beyond a minimal compile on a warm workstation. A 15-minute cap often fails builds that are otherwise healthy, especially after cache invalidation, dependency upgrades, or when parity with a longer-running CI job matters. For Pro and above, extending the ceiling to 45 minutes reduces those false negatives, improves predictability when you are tuning compute for build versus runtime, and removes pressure to split deployments or strip build steps solely to stay under a short timeout.
On eligible plans, you get fewer interrupted builds on legitimate workloads, less time spent re-running jobs after transient slowdowns, and closer alignment between what you can run locally or in your own CI and what Appwrite Cloud will accept during the build phase. Teams shipping larger frontends, monorepo-style repositories, or functions with heavier packaging steps should see the clearest gain. Compare plans and limits on the pricing page.
You can now learn how to manage Appwrite project configuration as code with the official Terraform provider directly in our documentation. Define TablesDB resources, storage buckets and files, Auth users and teams, Functions and Sites, messaging providers, topics, subscribers, webhooks, backup policies, and more in .tf files, keep changes in version control, and apply the same setup across staging and production with less manual work in the Console.
The new Terraform provider section links to the Terraform Registry for full generated schemas and walks through configuration for Appwrite Cloud and Community Edition. We also added a Terraform provider entry in the integrations catalog.