Appwrite 2.0 is now available for self-hosting_

Appwrite 2.0 is available for self-hosting today. The server runs on a coroutine engine, the Console has been rebuilt, PostgreSQL is the default database, and a default instance now runs on roughly half the containers it used to.

Here is what Appwrite 2.0 changes for self-hosting, and how to install or upgrade.

A rebuilt Console

Appwrite 2.0 ships Console IV, the fourth generation of the Appwrite Console, rebuilt from scratch. Self-hosted 1.9.6 ran appwrite/console, a Svelte app. Appwrite 2.0 runs appwrite/new, built on TanStack Start.

Every route prefetches its data while the router is still resolving. The page opens with rows already in the table, avoiding the layout shift when rows replace a loading spinner.

The Console includes two developer tools. Appwrite Terminal runs the Appwrite CLI in the browser, already signed in and configured for your current project. Open it with ⌘ + ;. Appwrite Explorer builds and sends live API requests against that project from its OpenAPI specification.

Your projects are untouched. Console IV is a new interface over the same APIs, so your API keys and SDK code keep working.

PostgreSQL, MariaDB, or MongoDB as the underlying database

Appwrite 2.0 runs on PostgreSQL, and new installations use it by default. MariaDB and MongoDB remain supported, and you pick one in the first step of the installer.

Your application code does not change based on the choice. The Appwrite APIs are the same on all three.

The database is fixed for the lifetime of an instance. If you upgrade an existing instance to Appwrite 2.0, it keeps the database it was installed with, so moving to PostgreSQL means a fresh install.

Hyperloop B

Appwrite 2.0 runs on Hyperloop B, the Swoole coroutine engine in utopia-php/http. One process serves many concurrent requests by yielding whenever a request waits on I/O. This replaces a model that holds a whole process for each request until it finishes.

There is nothing to configure and no API to call. Your instance runs on it after you install or upgrade.

Worker topologies

Appwrite 2.0 introduces worker topologies.

Appwrite runs background work such as mail, builds, TLS certificates, function executions, and screenshots on queues. In 1.9.6, every queue had its own container, so a single-project instance with almost no traffic still ran eighteen idle worker and scheduler processes. Each held its own PHP runtime, connection pools, and memory.

The combined topology, which is the default, runs every queue inside one appwrite-worker container and every scheduler inside one appwrite-task-scheduler container. Each queue keeps its own pool of coroutines, so a busy queue does not block the others. The behavior of every queue is unchanged.

For a default PostgreSQL install, the container counts for the whole stack are:

For a hobby instance or a small team, that is sixteen fewer PHP processes holding connection pools, and one place to read worker logs:

docker compose logs -f appwrite-worker

The separate topology remains available. Use it when one queue needs more replicas than the rest, or when you want per-queue metrics and resource limits. Choose it under Advanced settings during installation, or pass --topology=separate to the installer. Switching later takes one command and does not touch your data.

Usage metrics

Self-hosted instances now record usage per project resource. The numbers go to a bundled clickhouse container rather than your project database, so reading them does not compete with your application's queries.

More Git providers

Functions and Sites now deploy from GitHub, GitLab, Bitbucket, and Gitea. 1.9.6 supported GitHub only.

You can also let developers sign in to the Console with GitHub, GitLab, Bitbucket, or Google by setting the matching _APP_CONSOLE_* variables.

Also in this release

• Functions and Sites build through a new orchestrator container.
• The Console has a notifications inbox, served by a new notifications queue.
• A realtime event tail streams live project events into the Console.
• A new appwrite-geo container resolves IP addresses for locale and session data.
• The avatars API can fetch a user's profile photo from Gravatar or their OAuth2 provider.
• The separate audits worker is gone. Audit retention now runs in the deletes worker and the maintenance task.

One organization in the Console

On Appwrite Cloud, organizations have plans and billing. A self-hosted instance has neither, so the Console simplifies organization management. It creates one organization the first time you sign in, puts every project you create from the Console under it, and does not offer a way to create more. While your account belongs to that one organization, the Console hides the organization switcher.

Multi-tenancy is still supported. An organization is a team, and the API still takes a teamId when you create a project. Creating another team through the API creates another organization. Once your account belongs to more than one, because you created teams through the API or upgraded an instance that already had several organizations, the Console shows the organization switcher, lists every organization in the project selector, and lets you transfer projects between them.

Coming to self-hosted

A few of the Init products are on Cloud first. Appwrite Firewall, the S3 API for Storage, and the activity log for project events will be coming to self-hosted Appwrite very soon. Watch the release notes for the version that adds each.

Install Appwrite 2.0

Run the installer. Then open http://localhost:20080 and follow the wizard.

docker run -it --rm \
    --publish 20080:20080 \
    --volume /var/run/docker.sock:/var/run/docker.sock \
    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
    --entrypoint="install" \
    appwrite/appwrite:2.0.0

If you would rather write the Compose files yourself, the installation guide has a generator that produces docker-compose.yml and .env for your database and topology.

Upgrade an existing instance

Back up your data first. Upgrade to 1.9.6 before you upgrade to 2.0.0.

From the directory that contains your appwrite directory:

docker run -it --rm \
    --publish 20080:20080 \
    --volume /var/run/docker.sock:/var/run/docker.sock \
    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
    --entrypoint="upgrade" \
    appwrite/appwrite:2.0.0

Then run the migration from inside the appwrite directory:

cd appwrite/
docker compose exec appwrite migrate

The upgrade keeps your database and your worker topology. To change topology while you upgrade, add --topology=combined or --topology=separate to the upgrade command.

Resources