Changelog

• May 6, 2026

  Appwrite CLI now supports multi-file project configuration

  Appwrite CLI 20.0.0 adds support for splitting large appwrite.config.json files into multiple local JSON files with a new includes field.

  You can move supported resource arrays, such as functions, sites, tablesDB, tables, topics, teams, buckets, webhooks, and messages, into their own files while keeping init, pull, push, and run workflows unchanged. The CLI reads included resources into the same in-memory config shape and writes updates back to the file where each resource is defined.

  Function and site paths are resolved relative to the file that defines them, so nested workspaces, packages, and submodules can keep resource configuration and source paths together.

  JSON

  {
      "projectId": "<PROJECT_ID>",
      "endpoint": "https://<REGION>.cloud.appwrite.io/v1",
      "includes": {
          "functions": "./appwrite/functions.json",
          "sites": "./appwrite/sites.json",
          "buckets": "./appwrite/buckets.json"
      }
  }
  

  Learn more about multi-file configuration

• May 5, 2026

  Configurable start command for SSR Sites

  You can now set an explicit start command for server-side rendered (SSR) Sites in the Appwrite Console, alongside your existing build settings (install command, build command, and output directory). After a successful build, Appwrite uses this command to start the Node.js process that serves your app at runtime.

  Framework presets still supply sensible defaults for common stacks. When you need more control, a dedicated start command helps you:

  • Point Appwrite at the exact script or binary that boots your server (for example a custom server.js, a framework CLI wrapper, or a workspace-specific package.json script).
  • Run monorepos and multi-package layouts where the server lives under a subpath or a different package than the build root.
  • Match team conventions (pnpm, yarn, npx) or CI-style commands without relying on whatever the preset inferred from the framework alone.
  • Try diagnostics or staging behavior at boot (for example extra logging or guarded startup) while keeping your build commands unchanged.

  Configure it under your site’s Settings → Build settings when Server side rendering is enabled, then redeploy so the new command takes effect.

  Appwrite Sites documentation

• May 4, 2026

  Rust runtime for Appwrite Functions

  Appwrite Functions now supports Rust 1.83 as a first-class runtime. You can write functions in Rust, deploy them through the Appwrite CLI or Console, and pair them with the official Appwrite Rust SDK for type-safe, async access to every server API.

  The runtime gives you compiled, memory-safe performance for the hot paths in your backend, payment and webhook signature verification, image processing, data transformation, and any workload where latency and predictability matter. It is available on Appwrite Cloud today.

  A new Starter template for Rust is available in the function templates catalog, and the Functions documentation covers the runtime contract, request and response helpers, environment variables, dynamic API keys, and end-to-end examples for the new runtime.

  Read the announcement

• Apr 30, 2026

  Variables API: manage function, site, and project variables with Server SDKs

  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.

  Read the announcement

• Apr 29, 2026

  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

Load more