DEV Community: Appwrite

Weekly roundup: Password strength, self-serve BAA, and AI updates

Aishwari Pahwa — Wed, 17 Jun 2026 07:35:01 +0000

This week on the Appwrite blog, we shipped new Auth controls, made BAA acceptance self-serve for Pro organizations, covered Anthropic’s latest Claude models, and shared a full breakdown of everything that landed in May.

Here’s everything that went live this week.

Product announcements

Announcing Password strength

Appwrite Auth now lets you enforce password strength with minimum length and character requirements.

You can set the smallest number of characters a password must have, and require character types such as uppercase letters, lowercase letters, numbers, and special characters.

This gives teams more control over password rules at sign-up and password change, without building custom validation logic from scratch.

Read the announcement: https://appwrite.io/blog/post/announcing-password-strength

Announcing self-serve BAA

Pro organizations can now accept a Business Associate Agreement directly from the Appwrite Console.

Until now, getting a BAA with Appwrite required contacting the team and completing a signing process. With self-serve BAA, eligible Pro organizations can move faster without waiting on a sales or legal cycle.

For teams building healthcare applications that store or process PHI, this removes a major operational blocker from the compliance workflow.

Read the announcement: https://appwrite.io/blog/post/announcing-self-serve-baa

AI and developer ecosystem updates

Anthropic launched Claude Fable 5 and Claude Mythos 5

Anthropic launched Claude Fable 5 and Claude Mythos 5, its first Mythos-class models.

We covered what changed, how the models compare, and what developers should know about benchmarks, safeguards, pricing, and agent workflows.

The post breaks down where these models fit in the current AI developer ecosystem and what they could mean for teams building with coding assistants and agents.

Product updates

May product update

May was packed with releases across Appwrite, including:

→ Presences API

→ Rust runtime

→ Database relationships

→ BigInt columns

→ 7x faster Storage uploads

→ Git deployment triggers

→ Deployment retention

→ Email policies

→ Bun and Deno build runtimes

→ Appwrite plugin for OpenAI Codex

→ Dart 3.12 for Functions and Flutter 3.44 for Sites

From realtime presence to faster Storage uploads and new runtime support, May focused on making Appwrite faster, more flexible, and easier to build with across more stacks.

Read the full update: https://appwrite.io/blog/post/may-product-update-presences-api-rust-runtime-7x-faster-storage-uploads-and-more

Conclusion

We’re continuing to ship product updates, developer tutorials, and AI-focused deep dives every week.

Explore the latest posts on the Appwrite blog to stay updated with everything happening across Appwrite and the developer ecosystem.

May product update: Presences API, Rust runtime, 7x faster Storage uploads, and more

Aishwari Pahwa — Fri, 12 Jun 2026 09:31:26 +0000

Welcome back to the product update.

May was packed with releases across Appwrite. We shipped new tools for realtime collaboration, faster file uploads, better deployment workflows, new runtimes, Auth controls, and database improvements to help you build faster and scale with more confidence.

Here is a quick overview of what we shipped:

Presences API for online, typing, and activity states
Rust runtime for Appwrite Functions
Database relationships are officially out of beta
BigInt columns for Appwrite Databases
Up to 7x faster Storage uploads with parallel chunks
Git deployment triggers for Functions and Sites
Deployment retention for Functions and Sites
Email policies for Appwrite Auth
Bun and Deno build runtimes for Sites
Dart 3.12 for Functions and Flutter 3.44 for Sites
Appwrite plugin for OpenAI Codex

Let’s dive in.

Track who is online, typing, and active with the Presences API

Appwrite now includes a Presences API for short-lived user statuses like online, away, typing, editing, or viewing.

You can use it to build online indicators, typing states, multiplayer presence, collaborative editors, live dashboards, and activity feeds.

Read the announcement

Introducing the Rust runtime for Appwrite Functions

Appwrite Functions now supports Rust as a first-class runtime.

You can write and deploy functions in Rust, pair them with the official Appwrite Rust SDK, and use them for performance-sensitive backend workloads like webhook verification, image processing, payment flows, and data transformation.

Read the announcement

Database relationships are officially out of beta

Database relationships in Appwrite are now production-ready across Appwrite Cloud and self-hosted deployments.

You can model connected data more easily, filter across related records, and build apps with more reliable relationship loading and improved performance.

Read the announcement

Introducing BigInt columns

Appwrite Databases now supports 64-bit signed integers with the new BigInt column type.

BigInt is useful for large counters, external IDs, high-resolution timestamps, financial values, and any data that needs integer precision without floating-point rounding.

Read the announcement

Up to 7x faster Storage uploads with parallel chunks

Appwrite SDKs now upload Storage file chunks in parallel.

In our Node SDK benchmark, a 1.28 GB file upload dropped from 4 minutes 44 seconds to under 40 seconds. That is a 7.10x improvement, with no API changes needed.

Read the announcement

Git deployment triggers for Functions and Sites

Git deployment triggers give you more control over which changes create automatic deployments.

Use branch filters for production, staging, and preview workflows, or path filters so each Function or Site only deploys when relevant files change.

Deployment retention for Functions and Sites

Functions and Sites now support deployment retention.

You can choose how long Appwrite keeps non-active deployments before deleting them automatically. Active deployments are never deleted.

Read the announcement

Email policies for Appwrite Auth

Appwrite Auth now supports email policies.

You can block free providers, aliased emails, disposable inboxes, or enforce provider-specific domains for user creation and email updates.

Bun and Deno build runtimes for Sites

Appwrite Sites now supports Bun and Deno as build runtimes for Node-based frameworks.

You can switch the build runtime per Site from Runtime settings and apply the change on the next deployment.

Read the announcement

Dart 3.12 for Functions and Flutter 3.44 for Sites

Appwrite now supports Dart 3.12 as a Functions runtime and Flutter 3.44 as a build runtime for Sites.

Flutter teams can now build mobile apps, web apps, and backend functions with a more consistent Dart-based workflow.

Read the announcement

Appwrite plugin for OpenAI Codex

The Appwrite plugin is now available for OpenAI Codex.

It includes the Appwrite Docs MCP server and agent skills for the Appwrite CLI, major SDKs, and deployment workflows for Sites and Functions.

Learn more

Community Recognitions

We are excited to feature Ibaraki Douji as part of our monthly Community Recognitions for May 2026. Ibaraki Douji built a full, up-to-date Helm chart for self-hosting Appwrite on Kubernetes that deploys the entire stack, including the API, Console, Realtime, background workers, schedulers, database, Redis, and Kubernetes-native ingress with TLS. It lets you scale each component independently, run clean upgrades, and fits GitOps workflows with tools like ArgoCD and Flux. It has been running in production since Appwrite 1.7.4. Keep in mind that this is a community-backed project and is not maintained by Appwrite.

If you would like to participate in next month's Community Recognitions, join our Discord server and showcase your project.

Engineering Resources

What’s to come

We are continuing to improve Appwrite across realtime collaboration, deployments, performance, databases, Auth, and AI-assisted workflows.

Weekly roundup: Presences API, Git deployment triggers, and AI updates

Aishwari Pahwa — Thu, 11 Jun 2026 12:22:02 +0000

This week on the Appwrite blog, we shipped new product updates, published a hands-on realtime app tutorial, and covered the latest AI developer workflows.

Here’s everything that went live this week.

Product announcements

Announcing the Presences API

Appwrite introduced the Presences API, a new way to track short-lived user statuses like who is online, typing, viewing, or active inside an app.

Presences come with built-in Realtime channels, automatic expiry, and permission-aware subscriptions, making it easier to build collaborative and multiplayer-style experiences without managing temporary state manually.

Read the announcement: https://appwrite.io/blog/post/announcing-presences-api

Announcing Dart 3.12 for Functions and Flutter 3.44 for Sites

Appwrite now supports Dart 3.12 as a Functions runtime and Flutter 3.44 as a build runtime for Sites.

Developers can write serverless functions in Dart, deploy Flutter Web projects with Appwrite Sites, and use Appwrite Cloud for both backend and deployment workflows.

Announcing Git deployment triggers

Git deployment triggers for Appwrite Functions and Sites let developers control which branches and file changes create automatic deployments.

This helps teams build cleaner Git workflows for production branches, staging environments, previews, and monorepos, while avoiding unnecessary builds when unrelated files change.

Read the announcement: https://appwrite.io/blog/post/announcing-git-deployment-triggers

Developer guides

Build a Snapchat clone with Presences and Realtime

We published a hands-on tutorial showing how to build a Snapchat-style app with Appwrite’s Presences API and Realtime.

The guide walks through building realtime features using TanStack Start, TablesDB, Functions, and Storage, covering core experiences like live activity, disappearing content, and presence-driven interactions.

Read the tutorial: https://appwrite.io/blog/post/building-snapchat-clone-with-presences-and-realtime

AI and developer ecosystem updates

Anthropic launched Claude Opus 4.8 with fast mode and dynamic workflows

We covered Claude Opus 4.8 and what it means for developers building with AI agents.

The post breaks down fast mode, dynamic workflows, effort control, pricing, benchmarks, and how these updates point toward more flexible agentic development workflows.

Conclusion

We’re continuing to ship product updates, developer tutorials, and AI-focused deep dives every week.

Explore the latest posts on the Appwrite blog to stay updated with everything happening across Appwrite and the developer ecosystem.

Weekly roundup: Product announcements, AI updates, and developer insights

Aishwari Pahwa — Tue, 26 May 2026 13:13:41 +0000

This week was packed on the Appwrite blog. We shipped major product announcements, covered important AI and developer ecosystem updates, and published new deep dives across backend infrastructure, Auth, Databases, storage, runtime support, AI coding workflows, and modern app development.

Here’s everything that went live this week.

Major product announcements

Faster Appwrite Storage uploads with parallel chunks

We introduced parallel chunk uploads for Appwrite Storage, significantly improving large file upload performance. In benchmark tests, uploads saw improvements of up to 7x faster compared to the previous sequential approach. This update helps reduce upload bottlenecks for modern apps handling large media and datasets.

Read the announcement: https://appwrite.io/blog/post/faster-storage-uploads-parallel-chunks

Email policies for Appwrite Auth

Appwrite Auth now supports Email policies, letting developers block free email providers, aliased addresses, and disposable inboxes directly during signup. Policies can be configured independently through the Console or Server SDKs to improve signup quality and reduce abuse.

Bun and Deno runtimes for Appwrite Sites

Appwrite Sites now supports Bun and Deno build runtimes. Developers can deploy applications using modern JavaScript runtimes without additional infrastructure setup, giving teams more flexibility across frameworks and tooling.

Introducing the Appwrite plugin for Codex

We announced the Appwrite plugin for Codex, which brings Appwrite Skills and MCP support into Codex workflows. The plugin helps AI coding agents understand Appwrite projects, use the right SDK patterns, and build with more accurate context.

Read the announcement: https://appwrite.io/blog/post/announcing-appwrite-codex-plugin

Database relationships are out of beta

Database relationships in Appwrite are now production-ready. After a year of performance improvements, opt-in relationship loading, and full query support, relationships are ready for production workloads across Appwrite Databases.

Announcing BigInt columns

Appwrite Databases now supports BigInt columns, making it easier to store and query large integer values. This is useful for financial data, analytics, IDs, counters, and other workloads where standard integer limits are not enough.

Learn more: https://appwrite.io/blog/post/announcing-bigint-columns

Announcing deployment retention

Deployment retention for Appwrite Functions and Sites lets developers choose how long non-active deployments are kept before they are automatically deleted. This helps teams reduce storage usage and keep deployment history cleaner.

Developer guides and build ideas

3 things you can build with the Rust runtime

We published a practical guide on what developers can build with the Appwrite Rust runtime. The post covers use cases where Rust is a strong fit for server-side workloads, including performance-focused functions and backend processing tasks.

25 startup ideas you can build with vibe coding

We shared 25 startup ideas developers can build with vibe coding, from AI-powered tools to lightweight SaaS products. The post focuses on practical ideas that can move quickly from concept to prototype with the right backend and AI-assisted workflow.

Vibe coding security mistakes to avoid

We published a guide on common security mistakes developers can make when building with AI coding tools. The post covers risks around authentication, secrets, permissions, validation, and dependency management, helping developers move fast without shipping avoidable security issues.

How vibe coding is changing software development

We explored how vibe coding is changing the way developers build software, from faster prototyping to more AI-assisted development workflows. The post looks at what this shift means for developers, teams, and the future of building applications.

Vibe coding vs traditional development

We compared vibe coding with traditional software development, covering how each approach affects speed, control, technical decision-making, debugging, and long-term maintainability. The post helps developers understand where vibe coding works well and where traditional development practices still matter.

Learn more: https://appwrite.io/blog/post/vibe-coding-vs-traditional-development

How to deploy vibe coding projects to production

We published a step-by-step guide on taking vibe-coded apps from prototype to production, covering hosting, domains, secrets, permissions, logs, backups, and pre-launch checks.

How agencies are using vibe coding to ship client projects

We explored how agencies are using vibe coding to prototype faster, reduce delivery timelines, and ship client projects with more structured backend and deployment workflows.

Best backend for vibe coding apps in 2026

We compared backend options for vibe coding apps and looked at how the right backend can reduce complexity across Auth, Databases, Storage, Functions, hosting, and production readiness.

Can vibe coding replace junior developers?

We examined whether vibe coding can replace junior developers and what it actually changes for hiring, learning, code review, debugging, and software development teams.

Best frontend frameworks for vibe coding

We broke down the best frontend frameworks for vibe coding, including how options like Next.js, React, SvelteKit, Nuxt, Vue, Astro, and TanStack Start fit different project needs.

The hidden costs of vibe coding platforms

We covered the hidden costs of vibe coding platforms, including lock-in, fragmented tooling, hosting limits, scaling concerns, and what developers should consider before committing to a platform.

AI deep dives and industry updates

Gemini 3.5 Flash benchmark and capability review

We published a detailed breakdown of Gemini 3.5 Flash, covering benchmark performance, pricing, coding capabilities, reasoning improvements, and how it compares across real-world developer workflows.

Learn more: https://appwrite.io/blog/post/gemini-3-5-flash-deep-dive

OpenAI shipped Codex to the ChatGPT mobile app

We explored what OpenAI’s latest Codex mobile integration means for developers, coding agents, and the future of AI-assisted software workflows directly from mobile devices.

Anthropic launched Claude for Small Business

We covered Anthropic’s new Claude offering for small businesses and what it signals for the growing competition around AI-powered productivity and enterprise tooling.

Learn more: https://appwrite.io/blog/post/anthropic-just-launched-claude-for-small-business

Security and ecosystem updates

The TanStack npm attack shows how fragile modern JavaScript supply chains can be

We broke down the TanStack Start npm supply chain attack and what it means for modern JavaScript teams. The post looks at how dependency risk affects developer workflows and why security needs to be treated as part of the application lifecycle.

Learn more: https://appwrite.io/blog/post/tanstack-start-npm-supply-chain-attack

We’re shipping new product updates, backend improvements, AI deep dives, and developer-focused content every week.

Explore all the latest posts on the Appwrite blog and stay updated with everything happening across Appwrite and the developer ecosystem.

April product update: MongoDB support, Appwrite 1.9.0, Realtime upgrades and AI tooling

Aishwari Pahwa — Mon, 11 May 2026 05:58:38 +0000

Welcome back to the product update. April was packed with major releases across Appwrite. From our official MongoDB partnership and Appwrite 1.9.0 to new infrastructure APIs, Realtime improvements, performance upgrades, and deeper AI integrations, we shipped updates focused on helping you build faster, scale more reliably, and integrate Appwrite more deeply into your workflows.

Here is a quick overview of what we shipped:

Appwrite and MongoDB partnership in Appwrite 1.9.0
Terraform provider for Appwrite
Message based Realtime over a single WebSocket
List response caching with TTL
Introducing the Webhooks API
Official Appwrite Rust Server SDK
Appwrite MCP Server 2.0
Appwrite plugin for Claude Code
Appwrite plugin now available on Cursor

Let's dive in.

Appwrite and MongoDB join forces in Appwrite 1.90

Appwrite and MongoDB are now official partners. Starting with Appwrite 1.9.0, MongoDB is supported as a database option for self hosted deployments.

You can run Appwrite directly on your existing MongoDB infrastructure while keeping the same APIs and SDKs. No breaking changes. No rewrites.

Reuse your existing backups, monitoring, and scaling setup while staying fully open source and self hosted.

This release also includes improvements across Databases, Realtime, Auth, and infrastructure. You get better handling of large integers, new string column types, configurable caching, and improved observability for database usage.

Read the announcement

Terraform provider for Appwrite

You can now manage your Appwrite infrastructure using Terraform.

Define databases, storage, functions, auth, messaging, and more using HCL, and apply changes consistently across environments.

Works with both Appwrite Cloud and self-hosted setups.

Read the announcement

Message-based Realtime over a single WebSocket

Realtime has been reworked to use a message-based protocol over a single persistent WebSocket connection.

You can now manage multiple subscriptions on one connection, update them without reconnecting, and avoid URL length limits entirely. This makes Realtime more predictable and scalable for production workloads.

Learn more

List response caching with TTL

You can now cache list query responses in memory using a configurable TTL.

Repeated reads skip the database entirely until the cache expires, improving performance for feeds, dashboards, and frequently accessed data.

Caching is permission-aware, so users only see data they are allowed to access.

Learn more

Introducing the Webhooks API

Webhooks can now be fully managed through the Appwrite Server SDKs.

Create, update, and delete webhooks directly from code, configure signing secrets, and automate workflows for CI/CD or multi-tenant systems.

Available across all major Server SDKs.

Learn more

Introducing the Appwrite Rust SDK

Appwrite now has an official Server SDK for Rust.

It is async-first, type-safe, and designed for backend services and infrastructure use cases, covering all major Appwrite services. No raw HTTP calls, just a clean and idiomatic Rust API.

Learn more

Appwrite MCP Server 2.0

We have rebuilt the Appwrite MCP server with a simpler architecture.

Instead of passing service flags, everything is now enabled by default. The server exposes two tools: one to search the full Appwrite tool catalog, and one to execute operations. This reduces complexity and uses less of the model’s context.

Read the announcement

Appwrite plugin for Claude Code

Connecting Claude Code to a real backend usually takes manual setup and extra context.

The Appwrite plugin removes that. With a single install, your agent can interact with your Appwrite project using the right context from the start, with built-in skills and MCP servers included.

Learn more

Appwrite plugin now available on Cursor

The Appwrite plugin is now live on the Cursor marketplace.

No need to configure MCP servers or install skills separately. Just install and start building with support for the Appwrite CLI and major SDKs.

Install from the Cursor marketplace

Community Recognitions

We are excited to feature Abid as part of our monthly Community Recognitions for April 2026. Abid created a wrapper around an earlier version of the Appwrite MCP server to reduce token and context usage, an idea that later inspired improvements in Appwrite MCP Server 2.0.

If you would like to participate in next month’s Community Recognitions, join our Discord server and showcase your project.

Engineering Resources

What's to come

We are just getting started with MongoDB and AI integrations. Expect deeper database flexibility, more tools for AI-assisted development, and continued improvements across performance and developer experience.

Improve your Appwrite developer experience with dev keys

Aditya Oberai — Thu, 22 May 2025 12:42:37 +0000

When building applications with Appwrite, developers often need a way to test and debug services repeatedly over short periods. Sometimes, this can become a hassle, as Appwrite enforces strict rate limits on client apps to prevent abuse. Developers needed a way to bypass these rate limits in their test environments and CI/CD workflows to ensure the robustness of their app functionalities.

And this is the exact problem dev keys are here to solve!

What are dev keys?

Dev keys are a type of secret used by Appwrite's client SDKs. They allow the developer to bypass any rate limits enforced by Appwrite and suppress any CORS errors caused by not using a configured hostname. A developer can configure the expiration date of a dev key to any of the three preset options (1 day, 7 days, or 30 days).

Dev keys should never be used in production environments, as they can make your app more susceptible to abuse and security breaches.

Try out dev keys in an app

To test dev keys, I created a simple demo web app that sends 200 requests to create a new document in an Appwrite database. To set this app up, you must complete the following steps:

Step 1: Setup Appwrite project

First, create an Appwrite Cloud account or self-host Appwrite 1.7. Create a project (which will lead you to the project overview page) and head to the Databases page from the left sidebar. Create a new database with the ID testDb and a new collection with the ID testCollection. Store both of these IDs for future usage. In this collection, add the following attribute:

Name	Type	Required
`number`	Integer	True

Then, head to the Settings tab of the collection, scroll down to the Permissions section, and add the following permissions:

	Create	Read	Update	Delete
Any	False	False	False	False

Lastly, return to the project overview page, head to the Settings page from the left sidebar, and copy your API endpoint and project ID for future usage.

Step 2: Create web app

Next up, we'll create our test app. This will require us to create two files in our working directory:

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Dev keys demo</title>
</head>
<body>
    <h1>Dev keys demo</h1>
    <p>Click on this button to add 200 documents to the database in less than 1 minute.</p>
    <button type="button">Add documents</button>

    <!-- Appwrite Web SDK -->
    <script src="https://cdn.jsdelivr.net/npm/appwrite@18.1.1"></script>

    <!-- Our app's script -->
    <script src="app.js"></script>
</body>
</html>

app.js

const client = new Appwrite.Client()
    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1') // Your API Endpoint
    .setProject('<YOUR_PROJECT_ID>'); // Your project ID

const database = new Appwrite.Databases(client);

document.querySelector('button').addEventListener('click', async () => {
    const promises = [];
    for (let i = 0; i < 200; i++) {
        const promise = database.createDocument(
        'testDb', // Your database ID
        'testCollection', // Your collection ID
        Appwrite.ID.unique(),
        { number: i + i }
        );
        promises.push(promise);
        console.log('Request initiated:', i+1);
    }

    await Promise.all(promises);
});

If you open the HTML page in your browser and click on the Add documents button, you will notice numerous errors in the console with the HTTP code 429, as Appwrite's rate limits allow one client to create 120 requests per minute for this API endpoint.

Step 3: Create dev key

Head back to your Appwrite project. On the overview page, select the Dev keys tab under the Integrations section and create a new dev key. You can add whatever name and expiry date you like.

After creating this dev key, head to the app.js file and update the Appwrite client to the following:

const client = new Appwrite.Client()
    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
    .setProject('<YOUR_PROJECT_ID>')
    .setDevKey('<YOUR_DEV_KEY>'); // Your dev key

Step 4: Test the app

Reopen the HTML page in your browser. Clicking the Add documents button will allow all 200 requests to execute successfully.

Next steps

And with that, you have successfully tested dev keys! Learn more about Appwrite by visiting the docs and joining the Discord community.

Announcing Hosting for Flutter Web: deploy your Flutter web apps with Appwrite

Steven — Thu, 22 May 2025 07:14:44 +0000

Appwrite has long been a powerful backend platform for Flutter developers building mobile applications. Today, we’re bringing that same seamless experience to the web. With full support for Flutter in Appwrite Sites, you can now deploy Flutter web apps directly from your Appwrite project. No extra configuration, no added complexity.

This means you can use your existing Dart and Flutter knowledge to create fast, responsive web apps without needing to learn HTML, CSS, or JavaScript. Build once with Flutter and deploy to mobile, desktop, and web. All from a single codebase, all hosted on Appwrite.

Why native Flutter web support matters

While most web environments are made for Node, Deno, or Bun runtimes, only a few are tailored for the needs of Flutter developers. Appwrite Sites is different. It’s designed with full Flutter web support in mind, not just as an afterthought. That means native framework detection, optimized build settings, and direct integration with your Appwrite backend products like databases, authentication, storage, and functions.

More importantly, it eliminates the common friction points of mobile app deployment. You don’t need to pay for developer accounts ($25 for Android, $99/year for Apple), wait days for store approvals, or navigate restrictive platform policies. With web deployment, your app is live the moment you push it.

And because web apps run anywhere with a browser, you’re no longer limited to iOS or Android. Your Flutter app can be accessed from a desktop, tablet, mobile phone, or even a smart fridge. The web is universal, and Appwrite makes it easy to reach your users.

Not just for full web apps

Even if you're not targeting the web as your primary platform, Appwrite Sites still solves real needs for Flutter developers.

Many apps include flows that rely on external links, such as email verification, password reset, or payments. These typically direct users to a browser. With Sites, you can now create and host those supporting pages using the same Flutter tooling you're already familiar with.

Instead of stitching together HTML pages or managing another stack, you can build these "satellite" pages as lightweight Flutter web apps, and deploy them effortlessly with Appwrite. It's a way you leverage your existing knowledge and a more consistent way to build, with fewer moving parts and one unified codebase.

Key features

Full Flutter framework support: Sites now recognizes and supports Flutter as a framework during setup.
Auto-detection: Flutter web projects are automatically identified. No manual config required.
Optimized static hosting: Deployed like any other static site, but with Flutter-first optimizations.
GitHub integration: Automatically deploy on every push from your GitHub repository.
Works on Cloud and Self-Hosted: Whether using Appwrite Cloud or Self-hosting, Sites for Flutter works everywhere.

How to get started

Step 1: Create Flutter Web app

First, you must either create a Flutter Web app or set up the Flutter Web starter template.

Open your terminal, and run the following command.

flutter create my_app

In case you have an existing Flutter app and want to add web support to it, you need to run the following command in your project directory:

flutter create . --platforms web

Push this project to a GitHub repo.

Step 2: Create Appwrite project

Head to the Appwrite Console.

If this is your first time using Appwrite, create an account and create your first project.

Step 3: Create site

Head to the Sites page in your Appwrite project, click on the Create site button, and select Connect a repository.

Connect your GitHub account and select the repository you intend to deploy.

Select the production branch and root directory from your repo.
Verify that the correct framework is selected. In case an incorrect framework is visible, pick Flutter Web from the drop-down list.
Confirm the install command, build command, and output directory in the build settings. The default build settings for Flutter Web are:
- Install command: N/A (leave empty)
- Build command: flutter build web
- Output directory: ./build/web
Add any environment variables required by the site.

Click on the Deploy button.

Step 4: Visit site

After successful deployment, click on the Visit site button.

Simplifying development

Sites for Flutter is part of Appwrite’s larger mission to simplify the developer experience. With support for backend and frontend services, including static hosting, databases, functions, and auth, Appwrite is the all-in-one platform to build any application.

Try it today on Appwrite Cloud or self-hosted, and you can take your Flutter app live in just a few clicks.

More resources

How to setup the SvelteKit starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 15:08:48 +0000

Building web applications requires both front-end expertise and back-end infrastructure. Appwrite Sites simplifies this process by providing a platform for deploying, hosting, and scaling web applications.

To ease this process even further, Appwrite Sites offers a variety of starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, SvelteKit, and Flutter. In this blog, you will learn how to set up the SvelteKit starter template and deploy it to Appwrite Sites.

Overview of the starter template

SvelteKit is a modern web framework built on top of Svelte that enables fast, server-rendered and client-enhanced web applications with powerful routing, data loading, and deployment features out of the box.

Appwrite's SvelteKit starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' SSR rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Head to the Sites page from the left sidebar, click on the Create site button, and select the Clone a template option. This will take you to the Appwrite Sites templates listing, where you should search Svelte starter and click on the template.

After selecting the template, you can choose to connect a GitHub repository now or at a later time. If you choose to connect a repository, ensure you select a production branch (leave the root directory as is). Then, review the preset environment variables, update the domain name if you want, and click on the Deploy button. You can watch the deployment logs as the site is built.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your SvelteKit starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Svelte starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? SvelteKit (sveltekit)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

After your site has been successfully deployed, Appwrite will show you a Congratulations page. You can then either choose to view the site by clicking on the Visit site button or view the site configuration (deployments, logs, domains, usage, and settings) by clicking on the Go to dashboard button.

Next steps

And with that, the SvelteKit starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How to setup the Nuxt starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 13:47:42 +0000

To ease this process even further, Appwrite Sites offers a variety of starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, SvelteKit, and Flutter. In this blog, you will learn how to set up the Nuxt starter template and deploy it to Appwrite Sites.

Overview of the starter template

Nuxt is a framework built on top of Vue.js that makes it easy to develop server-rendered, statically generated, or single-page applications with features like routing, SEO optimization, and modular architecture out of the box.

Appwrite's Nuxt starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' SSR rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your Nuxt starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Nuxt starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? Nuxt (nuxt)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

Next steps

And with that, the Nuxt starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How to setup the Next.js starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 13:10:06 +0000

To ease this process even further, Appwrite Sites offers a variety of starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, SvelteKit, and Flutter. In this blog, you will learn how to set up the Next.js starter template and deploy it to Appwrite Sites.

Overview of the starter template

Next.js is a React framework that enables developers to build fast, scalable web applications with features like server-side rendering, static site generation, and API routes out of the box.

Appwrite's Next.js starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' SSR rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your Next.js starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Next.js starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? Next.js (nextjs)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

Next steps

And with that, the Next.js starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How to setup the Flutter starter template on Appwrite Sites

Aditya Oberai — Wed, 21 May 2025 13:02:09 +0000

Most web hosting platforms don't support Flutter Web out of the box, often forcing developers to jump through hoops just to get their apps online. This lack of native support can make deploying Flutter Web projects unnecessarily complex and time-consuming.

Appwrite Sites changes that by offering built-in support for Flutter Web, making it easy to host and scale your applications. Alongside Flutter, Appwrite also provides starter kits for popular frameworks like Next.js, React, Vue, Nuxt, Angular, and SvelteKit. In this blog, you'll learn how to set up the Flutter starter template and deploy it to Appwrite Sites.

Overview of the starter template

Flutter Web is a part of the Flutter framework that allows developers to build responsive, high-performance web applications using a single Dart codebase.

Appwrite's Flutter starter template includes:

A clean, single-page UI
Integration with Appwrite's SDK
Pre-configured deployment settings for Appwrite Sites' Static rendering strategy

Deploy the starter template on Appwrite

Firstly, you must head to Appwrite Cloud and create an account if you haven't already (or self-host Appwrite 1.7). Next, create your first project, which will lead you to the project overview page.

Alternative method to deploy starter template

As an alternative to the Appwrite console, you can create and deploy websites using the Appwrite CLI. Create your Flutter starter using the following shell command and configuration:

appwrite init sites
? What would you like to name your site? Flutter starter
? What ID would you like to have for your site? unique()
? What framework would you like to use? Flutter (flutter)
? What specification would you like to use? 0.5 CPU, 512MB RAM

You can then make any edits to the website and deploy it using the following command:

appwrite push sites

Test the starter template

Next steps

And with that, the Flutter starter kit is deployed to Appwrite Sites. You can explore other templates or deploy any other websites you'd like.

For more information about Appwrite Sites:

How to host SSR web apps on Appwrite Sites

Ebenezer Don — Tue, 20 May 2025 13:34:40 +0000

When you're building a modern web app, how you serve your content matters. Some pages need to be pre-rendered ahead of time for speed. Others need to be generated dynamically on the server for personalization or real-time data. This process is called Server-Side Rendering (SSR), and Appwrite Sites supports SSR, just like it supports Client-Side Rendering (CSR) and Static Site Generation (SSG).

If you've used platforms like Vercel before, this will feel familiar. You can connect your GitHub repository, choose a branch, and Appwrite will build your app and deploy it to a server.

In this post, we'll show you exactly how to host an SSR-capable web app using Appwrite Sites, from repository connection to framework-specific configurations. Whether you're migrating from Vercel or starting from scratch, this guide will walk you through every step.

What is SSR, and why does it matter?

Server-Side Rendering (SSR) means your web app's pages are rendered on the server at request time. Unlike pre-rendered static pages, SSR allows your app to respond to each request with dynamic content that's fully rendered before it reaches the browser. It's a powerful approach for apps that need authentication, personalization, real-time data, or SEO-friendly dynamic content.

Appwrite Sites supports SSR by allowing you to configure your framework's build settings and output behavior, and by running your app on a server runtime (Node.js) where needed.

Hosting an SSR app on Appwrite Sites

Let's walk through the process step by step.

1. Open the Appwrite Console

Log in to your Appwrite Console. In the left sidebar, you'll see a section labeled Sites. Click on it. This will take you to the Sites dashboard, where you can manage existing sites or deploy a new one.

Click the Create Site button to get started.

At this point, you have two options:

Clone a template , If you're starting fresh, this is a quick way to scaffold a new site.
Connect a repository , If you already have a working app in GitHub, this is what you'll want.

Choose Connect a repository. Appwrite will walk you through selecting a GitHub repository and giving the necessary permissions if you haven't already.

2. Configure your deployment settings

Once your repository is connected, you'll land on the deployment configuration page. Here's what you'll see:

Name: A name for your site, usually taken from your repository.
Branch: The branch you want to use for production (typically main or master).
Root directory: Leave this as ./ unless your app lives in a subfolder.
Silent mode: This prevents Appwrite from adding GitHub comments when changes are pushed.
Framework: Optional, but recommended. Selecting your framework here helps Appwrite apply sensible defaults and display SSR instructions specific to your setup.

Now, scroll down to the Build settings section. This is where you define how your app gets built:

Install command: The default npm install usually works unless your app uses a different package manager or custom setup.
Build command: For most frameworks, this is npm run build.
Output directory: For Next.js, this would typically be ./.next. Different frameworks may use different output paths.

If your app needs environment variables, like API keys, secrets, or runtime flags, you can define them in the Environment variables section. You can also import them from an existing .env file.

When you're done, click Deploy. Appwrite will pull your code, run your build steps, and deploy your site.

Framework-specific SSR tips

While Appwrite Sites supports SSR, not every framework behaves the same out of the box. If your app was previously deployed on Vercel, there's a good chance it was configured with a Vercel-specific adapter, especially if you used Next.js or SvelteKit.

These adapters are tailored for Vercel's environment and won't run properly on Appwrite, which expects Node.js as the runtime. To make SSR work on Appwrite, you'll need to switch to the appropriate Node.js adapter.

Let's go through a few popular frameworks and what to look out for:

Next.js

If you're using Next.js, SSR is supported. In your next.config.js file, make sure you do not set the output field. That's specific to Vercel and can interfere with the way Appwrite handles the build output.

Just let Next.js use its default behavior, and in your site settings, keep the output directory as ./.next.

SvelteKit

SvelteKit sites hosted on Vercel typically use @sveltejs/adapter-vercel. That won't work on Appwrite. To fix this, open your svelte.config.js file and switch to the Node.js adapter:

import adapter from '@sveltejs/adapter-node'

export default {
  kit: {
    adapter: adapter(),
  },
}

Once that's set, rebuild and redeploy your site.

Nuxt

Nuxt works quite seamlessly on Appwrite. In your site settings, make sure the build command is set to:

npm run build

SSR is supported out of the box with no additional adapter configuration needed.

Angular (with SSR)

If you've enabled SSR in your Angular app, make sure your src/server.ts file is using the @angular/ssr/node package. This enables Angular Universal to run properly in a Node.js environment.

Astro

For Astro apps, you'll want to install and configure the Node adapter. In astro.config.mjs, update your adapter:

import node from '@astrojs/node'

export default {
  output: 'server',
  adapter: node(),
}

This tells Astro to render pages server-side using Node.js.

Remix

Remix apps should be configured to use @remix-run/node in the server entry file. Make sure your entry.server.tsx file imports from:

import { createRequestHandler } from '@remix-run/node'

This ensures the server runtime is correctly set for Node environments like Appwrite.

Analog (Angular meta-framework)

Analog supports SSR via Vite. To enable it, set the ssr property to true inside your vite.config.ts file:

export default defineConfig({
  plugins: [
    analog({
      ssr: true,
    }),
  ],
})

This activates server-side rendering in your build pipeline.

How to check or change framework instructions

If you're not sure what to do for your specific framework, you can find help directly in the Appwrite Console.

Just open your deployed site from the Sites dashboard, click on Settings, and scroll down to the Build settings section. When you select a framework from the dropdown, Appwrite will show instructions for SSR configuration, specific to your chosen stack.

That way, you'll know exactly what needs to change, and how.

Final thoughts

Hosting SSR apps with Appwrite Sites gives you a lot of flexibility. You get a Git-powered workflow, server runtime support, and integration with frameworks you already use. But more importantly, you're in control. You're not locked into a proprietary environment, and you can configure the exact build behavior you need.

If you're switching from Vercel, just remember to revisit your framework's adapter and build setup. Most of the time, it's just a matter of switching to a Node.js adapter and updating a couple of config files.

Once you've set that up, Appwrite Sites takes care of the rest, from cloning your repo to deploying server-rendered content.

Try it out, and let us know how it works for your stack.ed to be generated dynamically on the server for personalization or real-time data. This process is called Server-Side Rendering (SSR), and Appwrite Sites supports SSR, just like it supports Client-Side Rendering (CSR) and Static Site Generation (SSG).

If you've used platforms like Vercel before, this will feel familiar. You can connect your GitHub repository, choose a branch, and Appwrite will build your app and deploy it to a server.

What is SSR, and why does it matter?

Appwrite Sites supports SSR by allowing you to configure your framework's build settings and output behavior, and by running your app on a server runtime (Node.js) where needed.

Hosting an SSR app on Appwrite Sites

Let's walk through the process step by step.

1. Open the Appwrite Console

Click the Create Site button to get started.

At this point, you have two options:

Clone a template , If you're starting fresh, this is a quick way to scaffold a new site.
Connect a repository , If you already have a working app in GitHub, this is what you'll want.

Choose Connect a repository. Appwrite will walk you through selecting a GitHub repository and giving the necessary permissions if you haven't already.

2. Configure your deployment settings

Once your repository is connected, you'll land on the deployment configuration page. Here's what you'll see:

Name: A name for your site, usually taken from your repository.
Branch: The branch you want to use for production (typically main or master).
Root directory: Leave this as ./ unless your app lives in a subfolder.
Silent mode: This prevents Appwrite from adding GitHub comments when changes are pushed.
Framework: Optional, but recommended. Selecting your framework here helps Appwrite apply sensible defaults and display SSR instructions specific to your setup.

Now, scroll down to the Build settings section. This is where you define how your app gets built:

Install command: The default npm install usually works unless your app uses a different package manager or custom setup.
Build command: For most frameworks, this is npm run build.
Output directory: For Next.js, this would typically be ./.next. Different frameworks may use different output paths.

If your app needs environment variables, like API keys, secrets, or runtime flags, you can define them in the Environment variables section. You can also import them from an existing .env file.

When you're done, click Deploy. Appwrite will pull your code, run your build steps, and deploy your site.

Framework-specific SSR tips

Let's go through a few popular frameworks and what to look out for:

Next.js

Just let Next.js use its default behavior, and in your site settings, keep the output directory as ./.next.

SvelteKit

SvelteKit sites hosted on Vercel typically use @sveltejs/adapter-vercel. That won't work on Appwrite. To fix this, open your svelte.config.js file and switch to the Node.js adapter:

import adapter from '@sveltejs/adapter-node'

export default {
  kit: {
    adapter: adapter(),
  },
}

Once that's set, rebuild and redeploy your site.

Nuxt

Nuxt works quite seamlessly on Appwrite. In your site settings, make sure the build command is set to:

npm run build

SSR is supported out of the box with no additional adapter configuration needed.

Angular (with SSR)

If you've enabled SSR in your Angular app, make sure your src/server.ts file is using the @angular/ssr/node package. This enables Angular Universal to run properly in a Node.js environment.

Astro

For Astro apps, you'll want to install and configure the Node adapter. In astro.config.mjs, update your adapter:

import node from '@astrojs/node'

export default {
  output: 'server',
  adapter: node(),
}

This tells Astro to render pages server-side using Node.js.

Remix

Remix apps should be configured to use @remix-run/node in the server entry file. Make sure your entry.server.tsx file imports from:

import { createRequestHandler } from '@remix-run/node'

This ensures the server runtime is correctly set for Node environments like Appwrite.

Analog (Angular meta-framework)

Analog supports SSR via Vite. To enable it, set the ssr property to true inside your vite.config.ts file:

export default defineConfig({
  plugins: [
    analog({
      ssr: true,
    }),
  ],
})

This activates server-side rendering in your build pipeline.

How to check or change framework instructions

If you're not sure what to do for your specific framework, you can find help directly in the Appwrite Console.

That way, you'll know exactly what needs to change, and how.

Final thoughts

Once you've set that up, Appwrite Sites takes care of the rest, from cloning your repo to deploying server-rendered content.

Try it out, and let us know how it works for your stack.