Changelog

• Apr 24, 2026

  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

• Apr 22, 2026

  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

• Apr 21, 2026

  More control over your API protocols

  You can now choose exactly which API protocols your project exposes from the Appwrite Console. A new project setting lets you explicitly enable or disable each protocol so your application only talks to Appwrite the way you intend.

  The following protocols can be toggled independently:

  • REST – standard HTTP API requests from client SDKs.
  • GraphQL – GraphQL API access for queries and mutations.
  • WebSocket – realtime subscriptions over WebSocket connections.

  Turning off protocols you don’t use helps you:

  • Reduce exposure by removing entry points your app doesn’t need.
  • Minimize the abuse surface available to malicious traffic.
  • Enforce stricter access patterns that match your architecture.

  You’ll find this under Project settings in your Appwrite Console.

• Apr 20, 2026

  Appwrite plugin for Claude Code

  The Appwrite plugin is now available for Claude Code. Install it to get agent skills for the Appwrite CLI and every major SDK, along with MCP servers for the Appwrite API and documentation, all in a single setup.

  Read the announcement

• 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

• Apr 7, 2026

  Education plan: project limit reduced to 2

  Due to a substantial increase in abuse, malicious activity, and breaches of our fair use guidelines, including running commercial projects, we are reducing the Education plan's project limit from 10 to 2.

  We understand this is not ideal. However, the recurring abuse of Education program resources had grown to a point where it was not feasible for our team to manually address each violation and we took this decision to protect the reliability and trust between Appwrite Cloud and the larger developer community.

  Each Education plan project still remains Pro-equivalent, with unlimited databases, buckets, functions, and sites, plus 2TB bandwidth, 150GB storage, and 200K monthly active users per project. The only exclusion is email support. Here's a simple comparison of a project on the Free plan versus the Education plan:

  Feature	Free plan	Education plan
  Databases per project	1	Unlimited
  Buckets per project	1	Unlimited
  Functions per project	2	Unlimited
  Sites per project	Unlimited	Unlimited
  Bandwidth	5GB / month	2TB / month
  Storage	2GB	150GB
  Monthly active users	75,000	200,000
  Project pausing	After 1 week of inactivity	Never

  For existing Education plan members with more than 2 projects, all current projects will remain active. However, they will not be able to create additional projects.

  We will continue looking for other ways to create value for Education plan members, through better learning content, hackathons, and more.

• Apr 6, 2026

  Appwrite plugin for Cursor

  The Appwrite plugin is now available on the Cursor Marketplace. Install it to get agent skills, MCP servers, and deployment commands for Appwrite, all in a single setup.

  Read the announcement

• Apr 2, 2026

  Flutter 3.41 and Dart 3.11 are now available on Appwrite Cloud

  Appwrite Cloud now supports Flutter 3.41 and Dart 3.11 runtimes.

  You can now select Flutter 3.41 when deploying Sites and Dart 3.11 when deploying Functions.

  These runtime upgrades include the latest stable improvements from the Flutter and Dart ecosystems, including language and tooling updates, performance optimizations, and ongoing platform compatibility improvements.

• Apr 1, 2026

  MongoDB support for self-hosted Appwrite

  Appwrite now supports MongoDB as a database for self-hosted installations. Starting with Appwrite 1.9.0, you can choose between MongoDB and MariaDB when setting up your instance. MongoDB is the new default.

  The new web-based installation wizard walks you through the setup, including database selection, in just a few steps. Your Appwrite API stays the same regardless of which database you pick; only the underlying database changes.

  Read the announcement

• Mar 31, 2026

  Security update: Axios npm incident

  We have reviewed Appwrite's production repositories, SDKs, and tooling chain following the recent Axios npm supply chain incident, and confirmed that Appwrite SDKs and tooling were not impacted by the compromised Axios releases.

  Our JavaScript and TypeScript SDKs use native platform APIs such as fetch rather than Axios. While no direct exposure was found in Appwrite deliverables, we still added extra safeguards to our TypeScript SDK workflow, including stronger lockfile handling, stricter CI install behavior, and improved dependency visibility during release review.

  Read the full security update

• Mar 23, 2026

  Appwrite Cloud: Realtime usage limits and billing enforcement

  Starting April 30, 2026, we will begin actively enforcing Realtime usage limits and billing on Appwrite Cloud.

  Since launching Appwrite Cloud in beta, we have not actively enforced Cloud limits for Realtime. We are now transitioning to full enforcement so that usage is measured and billed according to your plan. This change ensures fair usage across the platform and allows us to continue investing in Realtime and the rest of the Cloud offering.

  Realtime limits:

  • Messages: Free plan includes 2M messages/month; Pro include 6M messages/month. Additional messages are billed at $2.50 per 1M.
  • Concurrent connections: Free 250, Pro 500. Additional connections are $5 per 1,000.
  • Max message size: 256 KB on Free; 3 MB on Pro.

  Bandwidth consumed by the Realtime service also counts toward your plan’s general bandwidth allowance—the same pool used by your other Appwrite Cloud traffic (for example, API and Storage). See your plan’s bandwidth limits on the pricing page.

  You can view your current Realtime usage in the billing usage breakdown in the Appwrite Cloud console. Full details and plan comparison are on our pricing page.

  To improve performance and reduce costs, we recommend using Realtime queries to filter events server-side so your app receives only the updates it needs. Fewer messages mean lower usage and a better experience for your users.

  View pricing and limits

  Reduce messages with Realtime queries