July was all about making Appwrite easier to automate, easier to connect to AI tools, and easier to manage at scale. This month's Appwrite product update covers a hosted remote MCP server, the new Projects API, a simpler CLI login flow built on OAuth Device Authorization, and Appwrite 1.9.6 for self-hosted deployments.
There's a common thread running through all four: removing the manual steps between you and a working project. Setup you used to do by hand, whether that was installing a local server, clicking through Console settings, or pasting credentials into a terminal, is now either automated or gone.
What shipped in Appwrite's July product update?
In July 2026, Appwrite shipped four releases:
- Hosted remote Appwrite MCP Server with OAuth. Connect any MCP-compatible AI tool with a single URL, no local install required.
- Projects API. Configure and manage nearly every project setting programmatically through the SDKs and CLI.
- OAuth Device Authorization for the Appwrite CLI. Log in through your browser instead of typing credentials into the terminal.
- Appwrite 1.9.6. Reliability and migration fixes for self-hosted deployments.
Let's dive in.
The Appwrite MCP server is now remote
The Appwrite MCP server is now available as a hosted remote server.
What is the remote Appwrite MCP server?
The remote Appwrite MCP server is a hosted Model Context Protocol endpoint that gives AI coding tools structured access to your Appwrite project and documentation. Because it runs on Appwrite's infrastructure, you add one URL to your AI tool, authenticate with OAuth, and start building.
That means:
- No local installation. No cloning, no running a server alongside your editor.
-
No Python or
uv. The previous local setup depended on a Python toolchain. That requirement is gone. - No API keys to generate, paste, or rotate. OAuth handles authorization, so credentials never sit in a config file.
Which AI tools work with it?
The remote server works with any client that supports remote MCP servers, including Claude Code, Cursor, Codex, VS Code, Windsurf, and Zed.
Under the hood, the server keeps the same context-efficient architecture as the local version. That matters more than it sounds: MCP servers that expose hundreds of loosely organized tools eat into a model's context window before it writes a single line of code. Appwrite's server is designed to keep tool definitions lean so the model spends its context on your problem instead of on the catalog.
What can you build with it?
Once connected, your AI tool can read Appwrite documentation directly instead of guessing at SDK signatures from memory, and it can work against your actual project. In practice that means fewer hallucinated method names, fewer round trips to the docs tab, and less time spent correcting code that was written against an older version of the API.
If you were already using the local MCP server, the remote server is the recommended path forward. If you skipped MCP entirely because the setup felt like a side quest, this is the release to revisit.
Introducing the Projects API
The new Projects API lets you configure and manage nearly every Appwrite project setting through the SDKs and CLI.
What can you automate with the Projects API?
Settings that previously lived only in the Console are now programmable:
- Authentication providers. Enable and configure OAuth providers across environments
- API keys. Create, scope, and rotate keys as part of a deployment pipeline
- Platforms. Register web, Flutter, Apple, and Android platforms
- Environment variables. Set project-level variables without manual entry
- Email templates. Version your verification, recovery, and invitation templates
- Session policies. Control session length and limits per project
- Labels. Organize and tag projects at scale
Why does Projects API matter?
Because it turns project configuration into code.
Until now, standing up a new staging environment that matched production meant clicking through the Console and hoping you did not miss a toggle. Configuration drift between development, staging, and production is one of the quieter sources of "it works on my machine" bugs, and it is exactly the problem infrastructure as code was invented to solve.
With the Projects API you can:
- Script environment setup. Define a project once and reproduce it on demand.
- Version your configuration. Keep project settings in Git alongside your application code, with review and history.
- Reproduce configurations across environments. Promote the same settings from development to staging to production instead of recreating them.
- Onboard teams faster. New engineers run one command instead of following a Console walkthrough.
It also pairs naturally with the remote MCP server. Configuration that is expressible through an API is configuration an AI agent can reason about and apply for you.
OAuth Device Authorization for the Appwrite CLI
Logging into the Appwrite CLI is now much simpler.
How does the new CLI login flow work?
Instead of entering credentials in the terminal, the CLI now uses the OAuth 2.0 Device Authorization Grant:
- Run the login command in your terminal.
- The CLI opens your browser.
- Review the permissions being requested and approve access.
- The CLI signs in automatically.
You authenticate in your browser, so you never have to type your password into the terminal.
Why device authorization instead of a password prompt?
Device Authorization Grant is the standard OAuth flow for input-constrained clients, which is why you have seen it on smart TVs and streaming devices. Applied to a CLI, it brings a few practical benefits: your identity provider handles authentication, so MFA and SSO come along for the ride; the CLI receives a scoped token rather than your account password; and you get an explicit consent screen showing exactly what access you are granting.
Self-hosted users: nothing breaks. The existing email and password flow continues to work unchanged.
Appwrite 1.9.6 is now available
Appwrite 1.9.6 focuses on improving reliability for self-hosted deployments following the 1.9.5 release.
What's fixed in Appwrite 1.9.6?
- Automatic repair of missing Git provider attributes during migrations. Deployments that hit incomplete Git provider data now self-correct instead of requiring manual intervention.
- Migrations are safe to rerun after partial failures. If a migration stops halfway, you can run it again without worrying about compounding the problem. That is a meaningful change if you have ever watched a partial migration and wondered which half completed.
- Improved health checks for Appwrite containers and MongoDB. Better signals mean orchestration layers can detect and recover from unhealthy services faster.
If you are self-hosting and still on 1.9.5, this is a recommended upgrade. Review the self-hosting docs before you start, and as always, back up before upgrading.
Engineering resources
- Claude is now free for K-12 educators in the US
- Grok 4.5 Coding is here. Here's what developers need to know.
- Claude Sonnet 5 is Anthropic's most agentic Sonnet yet
- What's new in the MCP 2026-07-28 specification
- Claude Opus 5 nears Fable 5 intelligence at half the price
What's to come
July laid the groundwork for what's next, but we're only getting started.
We've been building some of our biggest updates yet, and while we're not quite ready to share them, we think you'll want to keep an eye on what's coming. Stay tuned for major announcements around the Appwrite platform in the weeks ahead.
In the meantime, follow us on X, check the Changelog regularly, and browse the docs to stay up to date with the latest releases.
Top comments (0)