Skip to content

Changelog

  • Realtime: persistent WebSocket and message-driven subscriptions

    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.

    Read the blog announcement

    Manage subscriptions in the docs

  • New filter, sort, and pagination flags in the Appwrite CLI

    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.

    Read the CLI commands reference

    Update the CLI to the latest version

  • Build timeouts increased to 45 minutes (Pro and above)

    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.

    Learn about build and runtime compute

    View plans and pricing

  • Terraform provider for Appwrite

    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.

    Open the Terraform provider docs

  • Webhooks API: manage webhooks with Server SDKs

    Webhooks can now be created, updated, and deleted programmatically using the Appwrite Server SDKs. Two new API key scopes, webhooks.read and webhooks.write, control access to the new endpoints.

    This makes it possible to provision webhooks as part of CI/CD pipelines, migration scripts, or any workflow where managing webhooks through the Console is not practical.

    Read the announcement

Start building with Appwrite today

Get started

Our plans

  • Free

    $0

    A great fit for passion projects and small applications.

    Get started
  • Pro

    Most popular
    From
    $25
    /month

    For production applications that need powerful functionality and resources to scale.

    Start building
  • Enterprise

    Custom

    For enterprises that need more power and premium support.

    Contact us