Changelog

• Apr 17, 2026

  TTL-based list response caching

  You can now cache listRows responses by passing a ttl parameter (in seconds). The first request executes normally and stores the result in an in-memory cache. Subsequent identical requests return the cached response instantly until the TTL expires. The cache is permission-aware, so users with different roles never see each other's cached data.

  Set ttl between 1 and 86400 (24 hours). The default is 0 (caching disabled). Row writes do not invalidate the cache. To force a purge, call updateTable with purge set to true.

  Read the full announcement

• Apr 16, 2026

  Keys API: manage API keys with Server SDKs

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

  This enables automated key provisioning for CI/CD pipelines, multi-tenant platforms, key rotation workflows, and any scenario where managing keys through the Console is not practical.

  Read the announcement

• Apr 13, 2026

  Appwrite MCP server no longer requires service flags

  The Appwrite MCP server has been updated with a simplified setup. You no longer need to pass service-selection flags like --users, --databases, or --storage when configuring the server.

  The server now exposes only two tools to the model, appwrite_search_tools and appwrite_call_tool, while the full Appwrite tool catalog is searched at runtime, using less of the model's context.

  Read the announcement

• Apr 8, 2026

  Introducing the Appwrite Rust SDK

  Appwrite now supports Rust as an official server SDK. The SDK provides async, type-safe access to all Appwrite server-side APIs, including Databases, Auth, Storage, Functions, and Messaging. It is available on crates.io.

  Read the announcement

• Apr 8, 2026

  Separate build and runtime compute specs for Sites and Functions

  You can now choose independent compute specifications for the build and runtime phases of Sites and Functions. Each spec sets CPU and memory for that phase, so you can tune both performance and spend: right-size compute for heavy builds or busy runtimes without paying for peak capacity in the phase that does not need it.

  Sites

  • Build specification: CPU and memory used while installing dependencies and producing your deployment artifact.
  • Runtime specification: CPU and memory used when your site handles traffic, including server-side rendering (SSR).

  Functions

  • Build specification: CPU and memory used while building and packaging your function deployment.
  • Runtime specification: CPU and memory available to each function execution.

  Build steps (dependency installs, compilers, bundlers) often need different resources than steady execution or request handling. For example, a large frontend build may benefit from more RAM during CI-style build, while a lightweight API or static output might need fewer resources at runtime, or the opposite if runtime work is heavy. Setting build and runtime specs separately lets you align capacity with each phase instead of over-provisioning for both, which helps control cost as well as latency and reliability.

  Configure these under each resource’s Settings > Resource limits in the Appwrite Console. On Appwrite Cloud, customizing specs beyond the default is available on the Pro plan; Starter organizations see an upgrade prompt when adjusting CPU and RAM.

  Read the Compute docs to learn more