DEV Community: Appwrite

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.

Appwrite Sites vs Vercel: Choosing the right web hosting platform

Ebenezer Don — Tue, 20 May 2025 13:33:57 +0000

Deploying modern web applications should be fast, flexible, and reliable. As developers, we've come to expect instant previews, custom domain support, seamless environment configuration, automatic HTTPS, and the ability to deploy everything from static pages to full server-rendered apps.

Vercel has been a default choice for frontend teams building with Next.js. But with the launch of Appwrite Sites, you now have a new, integrated way to deploy web apps, especially when you want your front end to live alongside your backend, database, authentication, and storage.

In this post, we'll take a look at how Appwrite Sites compares to Vercel. We'll explore everything from framework support to deployment workflows, logging, performance, and how each platform fits into a larger developer workflow.

What is Appwrite Sites?

Appwrite Sites is Appwrite's new deployment and hosting platform, designed to support both static (including single-page applications) and server-side rendered (SSR) web applications. It's tightly integrated into the Appwrite ecosystem, so if you're already using Appwrite for authentication, database, storage, or functions, you can now deploy your front end in the same place, with automatic access to shared environment variables and services.

Whether you're building with Vite, Next.js, Nuxt, SvelteKit, Astro, or something simpler like Vanilla JS or even Flutter Web and Lynx, Appwrite Sites provides a unified deployment workflow for both static and dynamic applications.

Integrated, full-stack hosting with Sites

One of the biggest differences between Appwrite Sites and Vercel is how they fit into your application architecture.

Vercel focuses primarily on frontend deployment. It excels at handling static assets and serverless-rendered content, especially from Next.js. It also supports other frontend frameworks like Astro, SvelteKit, Nuxt, and Remix, although it's deeply optimized for Next.js and includes native support for features like ISR (Incremental Static Regeneration) and Edge Middleware.

Appwrite Sites, on the other hand, is part of a complete development platform. You're not just deploying your frontend. You're deploying it in the same environment that already knows about your database collections, users, sessions, cloud functions, storage buckets, and APIs. That means the same platform handles everything from user auth to file uploads to server-side logic, and your frontend can interact with it all without any manual configuration.

This level of integration also means less risk of misconfiguration when connecting your services. Your environment variables, domain rules, CORS policies, and secrets are all managed within one project scope, reducing the friction between your frontend and backend.

Deployment workflows

Both platforms support Git-based workflows, which means you can deploy by connecting a GitHub repo and pushing changes to a selected branch. Each deployment also generates automatic screenshots, giving you a quick visual snapshot of the deployed result.

Deploying on Vercel

You connect your GitHub, GitLab, or Bitbucket repo.
Vercel auto-detects your framework and sets up sensible defaults.
Every push to your production branch triggers a build and deployment.
Pull requests automatically create preview deployments with unique URLs.
Each deployment includes a UI to inspect build logs, preview the deployment and view associated metadata.
You can redeploy any previous commit and view full deployment history.
There's no manual UI deployment support, although, there’s a CLI option.

Deploying on Appwrite Sites

You connect a GitHub repo to your Appwrite project.
Appwrite auto-detects your framework and applies default build, install, and output settings.
You choose a production branch.
Each commit triggers a build and deploy.
You can preview pull requests, commits, and even branches, each with their own URLs.
Manual deployment is supported, with a simple drag-and-drop interface in the Console. This lets you deploy without needing Git or the CLi.
Rollbacks are instant. You can restore a previous deployment with one click.
Deployment output is available as a downloadable folder you can inspect locally.

Manual deployment with Appwrite Sites offers an extra layer of flexibility, especially for small and simple static sites, which makes it easy to get started or quickly publish content without relying on Git or command-line tools.

Framework support

Vercel is best known for its deep Next.js integration, but it also supports other frameworks like Astro, SvelteKit, Nuxt, Angular, and Remix. However, its serverless and edge rendering infrastructure is most optimized for Next.js. Features like API Routes, Middleware, and ISR work out of the box with Next.js and require extra configuration or aren't supported at the same level with other frameworks.

Appwrite Sites offers SSR and static support for a wide range of frameworks, including:

Next.js
Nuxt
SvelteKit
Angular
Astro
Remix
Flutter Web (static)
Lynx
Analog
Vanilla JS and other static site generators

Each framework comes with its own build recommendations, and Appwrite Sites allows you to customize build and install commands, as well as define the output directory for compatibility.

Any static framework works well with Appwrite out of the box. For popular tools like Next.js, Nuxt, and SvelteKit, Appwrite offers presets that auto-configure your build and output settings. If your framework isn’t listed, you can choose “Other” and manually set the commands and output directory.

Most static and SPA setups work seamlessly. The only exception is SSR support for certain metaframeworks like Lit, which aren’t yet supported in SSR mode, but they still work fine as static sites.

If you're using a framework outside of Next.js, Appwrite Sites provides a more consistent experience across the board. This is also an advantage for teams that use different frameworks for different parts of their stack.

Hosting options: Static vs SSR

Appwrite Sites supports both Static/SPA hosting and Server-Side Rendering (SSR), much like Vercel. But there are a few differences in how they operate.

Static hosting

On both platforms, static content is pre-rendered at build time and served via a CDN. This gives you fast cold starts and simple deploys. Appwrite Sites provides build-time environment variables and supports any static framework or tool.

Server-side rendering

With SSR, both platforms render pages on demand.

Vercel runs SSR via serverless functions or edge functions depending on your configuration and framework. Its default serverless runtime supports dynamic SSR, and Next.js projects get special handling for API routes, dynamic rendering modes, and edge cache rules.

Appwrite Sites runs SSR apps in isolated containers, which means:

You get full runtime access to environment variables
Console output from server-side code is captured in logs
The SSR runtime can access Appwrite services directly

That container-based model gives you more flexibility, especially if you're doing server-side API calls, interacting with Appwrite's SDK, or running custom logic during rendering.

Environment variables

Both platforms offer strong environment variable support, with scope control and secrets handling.

Environment variables on Vercel

You define environment variables per environment: Development, Preview, and Production.
You can override variables per branch.
Secrets are encrypted and only available at build or runtime (depending on the variable).
You can manage them from the dashboard or CLI.

Environment variables on Appwrite Sites

You define project-wide and site-specific variables.
Variables can be exposed at build time, runtime, or both.
Appwrite injects built-in environment variables for your site, project, region, version, framework, and more.
You can define secret variables that are hidden after creation and not exposed via Console or API.

These built-in variables make it much easier to integrate your front end with the rest of your Appwrite services. You don't have to manually pass your API endpoint or project ID because it's already available.

Appwrite also provides a dynamic API key automatically, scoped and injected for both the build process and runtime (for SSR). This makes it easier to create or configure collections at build time, or securely perform server-to-server operations during SSR. If you were deploying on Vercel, you’d need to manually generate an Appwrite API key, store it as a secret, and rotate it regularly to maintain security.

Domains, CORS, and routing

Both Vercel and Appwrite Sites allow you to connect custom domains and use automatically generated subdomains for previews.

Vercel provides:

Auto-generated domains per project and deployment.
Custom domain support with DNS configuration.
Wildcard and branch subdomains.
HTTPS with automatic renewal via Let's Encrypt.

Appwrite Sites offers:

Auto-generated domain.
Custom domain support via CNAME records or full nameserver (NS) configuration
Branch and commit-specific URLs.
HTTPS enforcement and TLS certificates out of the box.

When you host both frontend and backend on Appwrite, your domain is trusted automatically. This eliminates the need to manually add frontend origins to your CORS settings because Appwrite already knows your Sites deployment is part of your project. This simplifies development and removes a common pain point: CORS errors.

It’s also important for preview deployments. Vercel assigns preview URLs under a shared namespace (e.g. *.vercel.app). If you try to allow previews with a wildcard like *.vercel.app, you’re not just allowing your previews, you’re allowing every Vercel preview domain to access your backend. That introduces unnecessary risk. Appwrite avoids this entirely. Since previews are scoped to your project, they’re trusted automatically, giving you tighter control without needing to expose your backend to external domains.

Logging and monitoring

Both platforms offer ways to monitor your applications and track issues in production, with some key differences in their approaches.

Vercel provides:

Build logs and deployment history.
Function execution logs (for serverless and edge functions).
Analytics for traffic and performance (on paid plans).

Appwrite Sites includes:

Request logs: status codes, duration, methods, headers, paths.
Console output: SSR logs from console.log() and console.error().
Log retention: 24 hours on the free plan, up to 7 days on Pro.
Optional log disabling: useful for privacy and performance-sensitive SSR routes.

These logs give you immediate visibility into how your app behaves in production and will help with troubleshooting issues when needed.

Performance and timeouts

Vercel uses edge functions and CDN caching for content delivery. Static content is served from edge locations, while serverless functions run in regional data centers. Performance varies by plan tier and deployment type.

Appwrite Sites uses a global CDN for static content, and container-based SSR for dynamic apps. You can configure timeouts (up to 30 seconds per request), and performance depends on your framework and hosting mode. Static hosting delivers near-instant responses through CDN caching, while SSR requires container initialization on cold starts but provides consistent performance afterward.

Security and isolation

Both platforms enforce HTTPS and protect secret environment variables.

Appwrite Sites also ensures:

Container isolation per deployment
TLS enforcement for all domains
Secret environment variables hidden after creation
Preview deployments can be restricted to team members

This is important for deploying apps that handle sensitive data or use server-side logic tied to specific users or accounts.

When to choose Appwrite Sites

If you're already building your backend with Appwrite, or want a single platform for your full-stack app, Appwrite Sites is a natural fit. You get integrated deployments, native access to your backend, and support for a wider range of frameworks with both static and SSR modes.

It's also a good choice if you:

Need SSR for frameworks beyond Next.js
Want to deploy front ends tightly coupled to backend services
Prefer to manage authentication, database, storage, and hosting in one place
Want rollback support, deployment visibility, and runtime logs built-in

Appwrite Sites vs Vercel: feature comparison

Feature	Appwrite Sites	Vercel
Full-stack integration	Yes	No
Static hosting	Yes	Yes
Server-side rendering	Yes (container-based)	Yes (serverless/edge)
Git-based deployment	Yes	Yes
Manual deployment via UI	Yes (drag-and-drop)	No
Preview deployments	Branch, commit, PR	Branch, commit, PR
Rollbacks	Yes	Yes
CORS with Appwrite backend	Automatic (trusted by default)	Manual setup
API key injection	Automatic (build + runtime)	Manual setup + rotation
Environment variables	Build + runtime, auto-injected Appwrite vars	Build + runtime, manual
Wide framework support	Yes	Yes
Templates	Yes (multi-framework)	Yes (mostly Next.js)
Timeout configuration	Yes (up to 30s)	Yes
Logging	Build logs, request logs, SSR console output	Build + function logs
Custom domains	Yes	Yes

Final thoughts

Both Appwrite Sites and Vercel are great platforms for deploying modern web applications. But they're built for slightly different workflows.

Vercel is an excellent frontend-focused host, especially for teams that are all-in on Next.js, or for static sites that don’t need a backend. Appwrite Sites, meanwhile, offers a deeply integrated full-stack environment, where your front end, backend, and services all live in the same project.

If you want to simplify your stack and keep everything in one place, from database to auth to hosting, Appwrite Sites offers a compelling alternative that brings clarity and flexibility to full-stack development.

You can get started today by heading to your Appwrite Console and creating a new Site. Appwrite Sites has templates, GitHub integrations, and framework guides ready to go.

If you have any questions, reach out to the Appwrite community on Discord or use the contact form on the website.

Appwrite Sites vs Netlify: Choosing the right web hosting platform

Ebenezer Don — Tue, 20 May 2025 13:33:25 +0000

Deploying frontend applications has gotten easier over the past decade, but also more complex behind the scenes. Most apps today need more than just HTML, CSS, and a CDN. They need authentication, secure APIs, environment configs, storage access, and sometimes server-side rendering.

Netlify helped kick off a modern approach to hosting, especially for static sites and JAMstack-style architectures. But if you're building an app that also depends on a backend, managing that split becomes a real part of your workflow.

With Appwrite Sites, you get an alternative that treats frontend deployment as part of a full-stack environment. Instead of connecting your frontend to a separate backend via API tokens and CORS rules, Sites lives in the same platform as your database, storage, authentication, and functions.

In this article, we'll break down how Appwrite Sites and Netlify compare, from framework support and SSR, to environment variables, deployment flows, and the developer experience of hosting modern apps.

What is Appwrite Sites?

Appwrite Sites is a deployment and hosting platform within the Appwrite ecosystem. It supports both static sites and server-side rendered applications, with built-in Git integration, preview deployments, custom domain support, and container-based SSR.

Because it's part of the same platform as Appwrite's backend services, like auth, database, storage, and cloud functions, you don't need to stitch together separate providers or manage secrets manually. Your frontend and backend live in the same project, with a shared security model and automatically scoped environment variables.

Sites supports a wide range of frameworks, from Next.js and Nuxt to Astro, SvelteKit, Angular, Remix, and Flutter Web. For static apps, you can deploy via Git or manually upload a .tar.gz. For SSR, Sites runs your app in a container with runtime access to secrets and Appwrite SDKs.

Netlify and the JAMstack model

Netlify pioneered the JAMstack movement, where apps are decoupled into static frontends + serverless functions + external APIs. That model works especially well for sites that are mostly static, with light dynamic behavior: marketing pages, documentation, or e-commerce frontends backed by third-party services.

Netlify offers automatic builds from Git, preview URLs, branch-based environments, edge functions, form handling, and even built-in identity support (though limited in scope). It also includes a CLI and plugin ecosystem for customizing builds.

But while it's flexible, it's not tightly integrated. You still need to bring your own database, authentication, file storage, and backend logic, and manage how your frontend connects to all of it.

If you're building a simple frontend, Netlify is fast and effective. But for applications where frontend and backend logic are deeply connected, managing those boundaries becomes the challenge.

Deployment workflows

Netlify

Netlify uses Git-based deployment as its primary model. You connect your GitHub, GitLab, or Bitbucket repository, and Netlify auto-detects your framework. Every push to a branch triggers a build, with a unique deployment URL.

Branch-based previews are automatically generated
Build settings can be customized via the UI or netlify.toml
Environment variables can be scoped to Production, Preview, and Dev
Rollbacks are supported
There's no drag-and-drop UI deployment option, manual deploys must go through the CLI

Netlify does provide build plugins, custom functions, and API routing, but you'll need to wire those up separately if you're using a custom backend.

Appwrite Sites

Appwrite Sites also supports Git-based deployment with preview environments:

You connect a GitHub repo to your Appwrite project
Framework detection sets defaults for build, install, and output
Pushes to the production branch deploy automatically
Every commit, branch, or pull request generates a unique URL for preview
All builds include downloadable artifacts
Manual deployments are supported via .tar.gz or drag-and-drop in the Appwrite Console

Rollbacks are instant and available through the UI. Because the deployment lives inside your Appwrite project, it inherits access to your backend services automatically, without needing to configure tokens, keys, or external origins.

This is especially helpful for teams working in mixed Git workflows, or solo developers who want a quick manual deploy option without setting up CI.

Framework support

Netlify supports most popular frontend frameworks, including Astro, Eleventy, SvelteKit, Nuxt, Next.js, and Angular. Most are treated as static frameworks unless you configure SSR explicitly using Netlify Functions or Edge Functions.

SSR support is more limited. While you can run serverless functions alongside your frontend, the integration varies depending on your framework. Next.js and Astro get the most complete support.

Appwrite Sites supports a similar set of frameworks, but adds SSR support via containers, which allows full runtime access to environment variables and Appwrite services:

Next.js – SSR and static
Nuxt – SSR and static
SvelteKit – SSR and static
Angular – SSR and static
Astro – SSR and static
Remix – SSR and static
Flutter Web – static only
Vanilla JS, Lynx, Analog, etc. – static

Each framework can be customized with its own build and install commands. If your framework isn't listed, you can use “Other” and specify custom config.

If you're using SSR with anything beyond Next.js or Astro, Appwrite Sites provides broader and more consistent support out of the box.

Hosting options: Static vs SSR

Both platforms support static and server-side rendered hosting, but their architectures differ significantly.

Netlify

Static: Content is pre-rendered and served from a global CDN
SSR: Pages are rendered using serverless or edge functions
Timeouts: Default timeout is 10s, up to 26s for Pro plans
Limitations: Memory and cold starts depend on function tier and region
Environment access: Functions get runtime env vars, but static content does not

Netlify's SSR works well for lightweight APIs and dynamic content, but lacks full access to services unless you add integrations or connect to external providers.

Appwrite Sites

Static: CDN-hosted HTML/CSS/JS, with build-time env vars
SSR: Full server-side rendering in isolated containers
Timeouts: Configurable up to 30s per request
Environment access: Both build-time and runtime variables are supported
Logging: Console output from SSR code is captured in logs

The container-based SSR model means you can use Appwrite's SDK at runtime, securely read secrets, and interact directly with databases, functions, or storage, all from your rendering logic.

If your SSR routes require access to auth tokens, protected storage, or custom logic, Appwrite's model gives you more control than Netlify's function-based execution.

Environment variables and secrets

Netlify uses a three-scope model, Production, Preview, Development, with env vars scoped accordingly. You define them in the dashboard or via the CLI, and they're injected at build or function runtime.

Appwrite Sites provides:

Project-wide variables shared across services
Site-specific variables
Secret variables (hidden after creation)
Built-in Appwrite variables (project ID, endpoint, region, etc.)
Automatic API key injection at build and runtime (for SSR)

You can define variables once in your Appwrite project and access them across deployments, functions, and services, without needing to sync values manually.

For example, instead of creating a token in Netlify and passing it to your frontend, Appwrite Sites automatically injects a scoped API key with access to your project, removing the need to manually rotate secrets or configure CORS.

Custom domains, CORS, and trust boundaries

Both platforms allow custom domains and HTTPS via auto-generated certificates.

Netlify:

Supports custom domains via DNS config
Wildcard subdomains and previews (e.g. .netlify.app)
Requires manual CORS configuration when connecting to external APIs

Appwrite Sites:

Supports custom domains via CNAME or NS records
Auto-generated domains for every branch and commit
Built-in CORS trust if your backend is hosted on Appwrite

Since Appwrite Sites and your backend live in the same project, deployed frontends are automatically recognized and trusted. You don't have to manually list frontend origins or manage preflight responses, Appwrite knows your Sites deployment is part of the same scope.

This eliminates one of the most common pitfalls in multi-platform deployments: CORS misconfigurations.

Logging and observability

Netlify provides basic logging:

Build logs for every deployment
Function logs for serverless execution
Analytics for traffic and latency (paid plans)

Appwrite Sites offers:

Build logs
Request logs (status code, path, duration, headers)
Console output for SSR apps
Log retention (24h on Free, 7d on Pro)
Optional log disabling (for performance-sensitive routes)

Appwrite's SSR logs include server-side console output, which is helpful when debugging SSR failures, auth edge cases, or unexpected rendering issues, without needing to integrate a third-party logging tool.

Security and isolation

Both platforms enforce HTTPS and offer secret management.

Appwrite adds additional safeguards:

Isolated containers for SSR deployments
Secrets not visible after creation
Automatic API key injection scoped to the current site
Project-based access controls
Preview deployment restrictions (e.g. team-only)

Since everything runs inside your Appwrite project, the surface area for misconfigurations is smaller. You're not exposing separate public APIs or managing external API keys, access happens within a single trusted environment.

Appwrite Sites vs Netlify: feature comparison

Feature	Appwrite Sites	Netlify
Static hosting	✅	✅
Server-side rendering	✅ (containers)	✅ (functions)
Git-based deployment	✅	✅
Manual deployment (UI)	✅	❌
Preview deployments	✅ (branch, PR, commit)	✅
Custom domains	✅ (CNAME + NS)	✅
Environment variables	✅ (build + runtime, project-wide)	✅ (scoped by env)
Secrets support	✅ (Option to hide after creation)	✅
Automatic API key injection	✅	❌
Auth, DB, storage integration	✅ (native)	❌ (external required)
SSR console logs	✅	Limited
CORS for Appwrite backend	✅ (auto-trusted)	❌ (manual config)
Timeout configuration	✅ (up to 30s, self-configurable)	✅ (10s default, requires support team on paid plans)

Final thoughts

Netlify is an excellent platform for static frontends and lightweight JAMstack sites. If you're building a marketing page, blog, or frontend that only talks to third-party APIs, it still delivers a clean and fast workflow.

But if your application needs more than that, auth flows, custom APIs, server-side logic, secure data access, etc., Appwrite Sites provides an integrated alternative. Instead of wiring together services across platforms, you keep your frontend and backend in one place, with fewer moving parts and tighter defaults.

Appwrite Sites is built for teams that want their frontends to do more, and for developers who want full control without unnecessary complexity.

Announcing Appwrite Sites: The open source Vercel alternative

Matej Bačo — Mon, 19 May 2025 08:24:26 +0000

You love using Appwrite to power your backend, but when it’s time to actually ship your website, you’re bouncing between tools, platforms, and extra accounts. That ends today.

Introducing Appwrite Sites.

A new Appwrite product that lets you deploy and host your websites and web apps right inside Appwrite. No more juggling services. No more gluing things together. No more multiple subscriptions. Just build, deploy, and go live. All in one place, and it's 100% open source, the kind that lets you (really) self-host and (really) own your data.

The all-in-one cloud platform

Appwrite has always been about giving you the tools you need to build fast, secure, and modern apps. However, while Appwrite has always worked hard to deliver a great backend experience, one big piece was missing: web hosting.

Until now, you had to rely on external platforms like Vercel or Netlify to get your web app live. That meant extra configs, more integrations, and one more invoice to worry about. With Sites, that gap is gone.

The best part: Appwrite is a fully open-source platform to offer both frontend hosting and your entire backend. All under one roof. From static sites and SSR apps to databases, authentication, storage, messaging and serverless functions, you can now build, deploy, and scale your entire app stack using just Appwrite.

Important Sites features

Building Sites as part of the Appwrite ecosystem was a deliberate choice to deliver a seamless experience from crafting your backend to deploying your web apps and websites. To ensure your usage of the platform feels consistent and robust, we set out to match the high standards of other Appwrite products when developing Sites over the past year.

We’ve introduced several critical features to elevate the hosting experience. Helping you scale efficiently, keep data secure, and deliver lightning-fast performance.

What’s part of Sites?

Static hosting: Ideal for single-page applications (SPAs), landing pages, documentation sites, and any project that compiles down to static files.
Server-side rendering (SSR): Full support for frameworks like Flutter, React, Next.js, Nuxt, SvelteKit, Astro, Remix, and more right out of the box.
Git integrations: Connect your GitHub repository to enable automatic deployments on every push.
Deployment previews: Get a unique preview URL for each pull request—review, test, and merge with confidence.
Global CDN: Distribute your content worldwide with a powerful content delivery network to ensure low-latency access from anywhere.
DDoS protection: Built-in protection mechanisms to help safeguard your apps from denial-of-service attacks.
The Appwrite Network: Take advantage of a growing number of cloud regions, Points of Presence (PoPs), and edge network capabilities, reducing latency and enhancing performance globally.
The Appwrite DNS: Appwrite provides a dedicated DNS (Domain Name System) service through its appwrite.zone nameservers to help you manage domain records for your applications.

All this is managed from your Appwrite Console or CLI, and deployable in both **Cloud and self-hosted environments.

Sites templates: One-Click websites

To make building your website even easier, we created ready-to-use customizable templates that you can deploy with one click, directly from Appwrite. Because not every project needs custom design, and not every team has the time to build from scratch.

We partnered with open-source maintainers like Docusaurus, ReactAdmin, and many more to bring you diverse templates. We will continue to add more templates to ensure we have everything you need.

From polished landing pages to waitlist forms and simple promo sites, Sites templates let you go live faster. Read more on how to get started with Sites templates in our docs.

How to get started with Sites

Cloud

Getting started with Sites Templates takes just a few clicks:

In the Appwrite Console's sidebar, click Sites.
Click on the Create site button.
After clicking on Connect Git repository, select your repository.
After connecting to GitHub, (optionally) add a name and site ID.
Verify that the correct framework is selected.
Confirm the install command, build command, and output directory in the build settings. To learn more, visit your preferred framework quick-start.
Add any environment variables required by the site.
The site will be created, and a build will begin. Once the build is completed, you'll have created your first site. You can use your site's domain to access the deployment.

We have added quick starts for popular frameworks to help you set up faster with your preferred framework, with more to come. As of today you can follow quick starts for Flutter, Nuxt, Next.js, Angular, SvelteKit, Remix, Astro, Vue.js, React, and Vanilla.JS.

Self-hosted

If you prefer to use Appwrite Sites open-source version, you can visit the self-hosting documentation and review the Appwrite repository.

Appwrite Sites pricing

Appwrite Sites is free to use until July 1st, 2025. We will inform you before introducing pricing so that you know well beforehand and have no surprises.

One platform to build, host, scale

Like many developer tools, we are here to make you more productive. By bringing hosting into Appwrite, you spend less time on setup and more time on what matters: building. Fewer moving parts means fewer things to break, and everything works seamlessly with your existing Appwrite services like Databases, Functions, Storage, and Auth. It’s Appwrite’s goal to improve your time to production. We make you move faster with Sites.

Sites will be available on both Appwrite Cloud and self-hosted deployments.

Spin up your first site from the Console or CLI and go live in minutes. No more stitching platforms together, no more waiting for deploys, just fast, integrated shipping.

Announcing Appwrite’s Hacktoberfest 2024 Hackathon: Build, innovate, and win!

Aditya Oberai — Tue, 01 Oct 2024 17:15:58 +0000

Hacktoberfest is almost here, and we’re excited to announce that Appwrite will be hosting our own Hacktoberfest 2024 Hackathon! Whether you're a seasoned developer or just dipping your toes into open-source, this is the perfect opportunity to create something impactful while being part of the global Hacktoberfest movement.

From October 1st to October 31st, join thousands of developers worldwide as we work together to push the boundaries of creativity and innovation. This year, we’re looking for projects that showcase not only technical skills but also a fresh perspective on the tools and problems that matter most to the developer community.

What you need to know:

Dates: The hackathon will run for the entire month of October, kicking off on October 1st and concluding on October 31st.
Team size: You can work solo or with a team of up to 4 members.
Project requirements: Your submission must be a brand-new project. Whether it's a web app, a mobile app, a game, or a tool, we want to see something fresh and innovative.
Focus areas: We're looking for projects that highlight creativity and innovation. Don't be afraid to push the envelope and try something out of the ordinary!
Prizes:
- The top team will each walk away with The Appwriter, an exclusive award for the best overall project.
- 2nd and 3rd-place teams will receive the Appwrite swag kit.

Why join the Appwrite Hackathon?

Aside from being part of one of the most exciting open-source events of the year, this hackathon is your chance to:

Collaborate with like-minded developers across the world.
Showcase your skills by building something new and exciting.
Learn and grow, whether you’re deepening your knowledge of Appwrite or trying it out for the first time.
Win awesome prizes and, of course, eternal bragging rights.

This Hacktoberfest, we’re focusing on innovation and creativity. Developers who are given the space to experiment and push their boundaries can build extraordinary things. We want to see your ideas come to life! Read this article about hackathon ideation to get your creative juices flowing.

How to get involved

Gather your team (or get ready to fly solo) and start brainstorming!

Don’t forget to register your team and project for a chance to win the prizes. Registration is open here from today until October 31st.

Join our Discord server to keep up with all future Hackathon news, and mark your calendars for the official kickoff on October 1st!

Get ready to build, innovate, and show the world what you can create. Let’s make Hacktoberfest 2024 unforgettable!

How to optimize your Appwrite project for cost and performance

Ebenezer Don — Mon, 23 Sep 2024 09:02:42 +0000

As your Appwrite project scales, performance and resource management become critical, not just to keep your app running smoothly, but also to avoid unexpected usage spikes. While Appwrite is designed to scale effortlessly, it's important to proactively optimize your usage so you don't reach resource limits prematurely. Effective optimization helps reduce costs, improves performance, and enhances user experience without compromising on functionality.

This guide provides a detailed overview of techniques to optimize your Appwrite project, covering API request management, caching strategies, file compression, image optimization, and other methods to ensure your app performs well while staying within your desired resource limits.

1. Reducing API requests: Smart querying and consolidation

Every API request consumes resources, and when requests are made inefficiently, they can consume substantial resources and increase usage costs. Here are strategies to help reduce unnecessary API calls:

Efficient use of `listDocuments` with queries

In Appwrite, fetching multiple documents from a database is made easy with the listDocuments method. This method allows you to retrieve all documents in a collection or apply filters using the Query API. Instead of making multiple requests for each document, you can fetch only the relevant data with a single request.

For example, in a content management system where you need to load blog posts written by a particular author, rather than making individual requests for each document, use Appwrite's listDocuments method with a filter:

const blogPosts = await databases.listDocuments(
  '<DATABASE_ID>',
  '<COLLECTION_ID>',
  [Query.equal('author', 'Michael Scott')],
)

By fetching all the documents you need in one go and applying filters, you reduce the number of requests and improve performance. However, as we'll see in the next section, you should use the listDocuments method carefully to avoid fetching unnecessary data, else you might end up with a large dataset that could slow down your application.

Optimize pagination and filtering

For applications with large datasets (e.g., e-commerce platforms with thousands of products), retrieving all data at once can overwhelm your system. Use Appwrite’s pagination and filtering feature to only fetch what’s immediately needed.

For example, if you’re loading products from a database, instead of fetching all products, fetch them in batches using pagination.

const firstPage = await databases.listDocuments(
  '<DATABASE_ID>',
  '<COLLECTION_ID>',
  [
    Query.equal('author', 'Meredith Palmer'),
    Query.limit(20),
    Query.offset(0),// Fetch the first 20 records
  ],
)

const secondPage = await databases.listDocuments(
  '<DATABASE_ID>',
  '<COLLECTION_ID>',
  [
    Query.equal('author', 'JaneDoe'),
    Query.limit(20),
    Query.offset(20),// Fetch the next 20 records
  ],
)

This strategy will not only conserve bandwidth but will ensure that your queries return faster results, improving your user experience.

For more information on querying documents, the Appwrite Queries documentation provides detailed examples and options.

Utilizing Appwrite’s realtime API for data updates

When building real-time applications (e.g., chat apps or collaborative tools), polling APIs frequently can result in unnecessary usage and increased server load. Appwrite’s Realtime API solves this by allowing you to subscribe to events and receive updates in real time via WebSockets. This ensures that your app remains responsive without the need for constant polling.

For example, you can subscribe to file upload events in real-time:

const unsubscribe = client.subscribe('files', (response) => {
  if (response.events.includes('buckets.*.files.*.create')) {
    console.log('New file uploaded:', response.payload)
  }
})

In addition to handling real-time updates, Appwrite's Realtime API can help decide when further requests are needed. Instead of continuously fetching data to check for updates, you can create a versioning system.

Versioning Document: Create a document with a single column, version, to track updates.
Subscribe to Changes: Use the Realtime API to monitor changes in this document. If the version field updates, it signals that the data has changed and needs re-fetching.

Appwrite’s Realtime API supports multiple channels, such as files, account, and specific collections, ensuring updates from any part of your app. To learn more about the Realtime API, refer to the Appwrite Realtime documentation.

By using Appwrite's real-time feature, you drastically reduce API request overhead, especially for high-traffic apps like live dashboards or messaging platforms, while maintaining instant, event-driven updates.

2. Effective caching: Reducing redundant data fetching

Caching is one of the most important strategies for improving both performance and resource management in your Appwrite project. By caching frequently accessed data, you reduce the number of redundant requests sent to your Appwrite instance.

Client-side caching with localStorage or IndexedDB

For non-sensitive or rarely changing data, client-side caching can significantly reduce server load and improve application responsiveness. Use the browser’s localStorage or IndexedDB to store data that users frequently access, such as user settings, app configurations, or product lists.

For instance, in a to-do list app, user preferences (e.g., preferred task view) can be cached locally so that the app doesn’t need to retrieve this data from Appwrite on every page load.

// Cache user preferences in localStorage
localStorage.setItem('userPreferences', JSON.stringify(preferences))

// Retrieve user preferences from cache
const cachedPreferences = JSON.parse(localStorage.getItem('userPreferences'))

This reduces unnecessary API requests and allows for instant access to cached data, improving performance.

Optimized cache expiry and invalidations

Caching data on the client side is effective, but it must be combined with intelligent cache expiry strategies to avoid serving stale data. Ensure that the cache is invalidated and refreshed when necessary, such as when the data changes or after a certain time period.

// Cache with expiration (using localStorage)
const saveToCache = (key, data) => {
  const item = {
    data,
    expiry: Date.now() + 1000 * 60 * 60, // Cache for 1 hour
  }
  localStorage.setItem(key, JSON.stringify(item))
}

const getFromCache = (key) => {
  const cachedItem = localStorage.getItem(key)
  if (!cachedItem) return null

  const item = JSON.parse(cachedItem)
  if (Date.now() > item.expiry) {
    localStorage.removeItem(key) // Invalidate stale cachereturn null
  }

  return item.data
}

This ensures your users get up-to-date data while reducing the number of requests made to the server.

Server-side caching with Redis

Redis is a widely-used, high-performance in-memory data store that can be an excellent choice for server-side caching in your Appwrite projects. Redis can be deployed alongside your Appwrite backend to cache frequently accessed data, reducing the load on your Appwrite instance and speeding up response times for users.

For example, in an e-commerce application, you could cache product categories, prices, or frequently queried data in Redis. This way, instead of hitting the database for every request, your application can retrieve data directly from Redis, which significantly improves performance for repeated requests. You can learn more about Redis in the Redis documentation.

3. Optimizing file storage: Compression and efficient file delivery

Managing large files can be a significant source of resource consumption. Optimizing file storage and delivery can help keep storage costs down and ensure faster data transfers.

Bucket compression

One of the most important optimizations for file storage is bucket compression. Appwrite allows you to compress files in your buckets using either the gzip or zstd compression algorithms. Enabling compression reduces the file size and conserves storage space, which is particularly useful for large files and media-heavy apps.

Gzip is a widely-used compression algorithm that offers good compression ratios for many types of files.
Zstd (Zstandard) is a modern, high-performance compression algorithm that provides better compression efficiency and decompression speed compared to gzip, making it a great choice for high-performance applications.

To enable compression for a bucket, you can set this up via the Appwrite Console or programmatically using the SDK:

const promise = storage.createBucket('bucketId', 'bucketName', {
  compression: 'zstd',
})

Keep in mind that files larger than 20MB are not compressed, even if compression is enabled. This is done to prevent performance bottlenecks when handling large files. Enabling compression at the bucket level not only helps reduce storage usage but also speeds up file transfers by reducing the amount of data sent over the network.

Optimizing image delivery with the Preview API

Appwrite allows you to serve compressed and optimized versions of your images to reduce bandwidth usage and improve performance. You can use the preview endpoint to adjust image quality, resolution, format, and more, without needing to modify the original file. This is useful for serving responsive images on the web, where you might want to reduce file sizes for faster load times.

// Serve an optimized image preview
const optimizedImage = storage.getFilePreview(
  'bucketId', // The bucket ID where the file is stored
  'fileId',   // The file ID of the uploaded image
  800,        // Resize the width to 800px
  0,          // Keep the original height (aspect ratio preserved)
  'center',   // Crop the image centered if cropping is needed
  80,         // Set image quality to 80%
  0,          // No border
  '',         // No border color
  0,          // No border radius
  1,          // Full opacity
  0,          // No rotation
  '',         // No background color
  'webp',     // Convert the image to WebP format for better compression
)

While this example shows how to serve an optimized image preview, and will greatly improve load times, it will not affect the original file size in your storage. So if you want to save storage space, consider compressing and optimizing files at the time of upload. A good practice for image optimization is to use formats like WebP, which offer better compression than JPEG or PNG.

Optimizing file delivery with CDNs and regional project deployment

For improved file delivery performance, especially in media-heavy applications, you can leverage a domain-level CDN like Cloudflare. A CDN caches files and serves them from locations closer to your users, reducing load times and improving the overall experience without overburdening your Appwrite server.

In addition, deploying your Appwrite project in a region near your user base can further reduce latency. Currently, Appwrite supports the FRA (Frankfurt) region, which is great for users in Europe. We're also expanding to more regions soon, giving you even more options to optimize performance based on your audience's location.

By combining CDNs and regional project deployments, you can enhance file delivery speeds, reduce latency, and ensure a more responsive user experience.

4. Using serverless functions for optimized workflows

Serverless functions in Appwrite are a powerful tool for optimizing resource usage. Instead of handling complex, resource-heavy operations on the client or in your core backend, offload these tasks to serverless functions that can execute asynchronously and on-demand.

Tasks like generating reports, processing data, or transforming files can be offloaded to serverless functions. This approach frees up the client and backend from performing expensive computations and ensures that heavy workloads don’t slow down your core application.

5. Setting up usage limits, alerts, and budget controls

Proactively managing your resource usage in Appwrite is key to avoiding unexpected overages and optimizing costs. Appwrite offers built-in tools for setting up usage alerts and budget controls to help developers manage their consumption.

Budget controls

You can also enable budget alerts to monitor your spending and prevent unexpected charges. For teams managing larger projects or multiple clients, setting budget limits ensures you stay within financial expectations.

To configure budget alerts, start by navigating to the Appwrite Cloud Console, then go to the Organisation section and select Billing. Here, you’ll find options to manage your budget. You can set a budget cap to define a hard limit on your spending, and in the Budget Alerts section, you can enable notifications that trigger when your spending reaches a certain threshold. This ensures you are alerted before exceeding your desired budget.

6. Monitoring and scaling your Appwrite project

Appwrite handles scalability efficiently, particularly in its cloud environment. Appwrite Cloud automatically scales resources as needed, ensuring that your application can handle increased traffic or workloads without requiring manual intervention. This automatic scaling allows you to focus on building your app, while Appwrite dynamically adjusts the resources behind the scenes to maintain optimal performance during traffic spikes.

While this is a significant advantage of using Appwrite Cloud, self-hosted instances also provide flexibility for custom scaling configurations. By monitoring your Appwrite project’s resource usage, you can identify bottlenecks, optimize your app, and scale horizontally as needed.

Automatic scaling in Appwrite

Appwrite's infrastructure is built on top of Docker, which allows for containerized scaling. Each service in Appwrite is containerized, meaning services like databases, storage, or functions can be scaled horizontally as demand increases. This happens automatically in the cloud version of Appwrite, making it easier for developers to handle surges in user traffic without experiencing downtime or performance degradation. For self-hosted Appwrite, scaling is also possible but requires setting up and managing Docker containers manually.

In Appwrite’s cloud environment, you don’t have to worry about manually configuring load balancers or managing server instances to scale your application. Appwrite automatically distributes workloads, ensuring smooth operation regardless of traffic volumes.

Monitoring resource usage

Appwrite provides built-in monitoring to help track API usage, database operations, storage, and other key metrics. This monitoring allows you to identify potential inefficiencies, such as high API request volumes or unnecessary data fetches, before they escalate into larger issues. While Appwrite handles automatic scaling, regular monitoring can help you optimize your application to avoid overuse of resources and prevent unnecessary costs.

You can monitor your Appwrite project's performance via the dashboard, which gives insights into your API request count, database operations, and storage usage. This data helps you manage your plan limits more effectively and optimize your app to avoid unexpected scaling needs.

Horizontal scaling

For self-hosted environments, Appwrite can be scaled horizontally by replicating containers across multiple servers. Stateless containers like those running functions or workers can be easily replicated to distribute workloads. However, for stateful services like databases, manual scaling configurations may be required.

Horizontal scaling ensures that the load is distributed evenly across multiple instances, making your application more resilient during high-traffic periods.

Conclusion

Optimizing your Appwrite project ensures you not only provide a better experience to your users but also prevent unnecessary resource overuse. By applying the techniques discussed in this guide, you can keep your project running smoothly while staying within your plan limits.

These optimizations aren’t just about cost savings—they are about making your app more scalable, efficient, and reliable as it grows. Rather than waiting until you hit plan limits, taking a proactive approach builds trust and ensures your users always experience the best possible performance, even as your app scales.