2.0.0-rc.1 Release Candidate

First release candidate for the self-hosted 2.0.0 release. Pre-release — not recommended for production.

Try it

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

Upgrading from 1.9.x uses the same command with --entrypoint="upgrade". Back up your data first — this is a release candidate.

Release-blocking fixes since 1.9.6

Found while testing the upgrade path end to end.

Postgres data is now persisted. The named volume was mounted at /var/lib/postgresql/18/data, but the image sets PGDATA=/var/lib/postgresql/18/docker. Docker satisfied the image's declared VOLUME with a throwaway anonymous volume, so data survived a restart but was destroyed by any container recreate — down, --force-recreate, an image bump, or the documented upgrade entrypoint. Postgres is the 2.0 default, so a stock install lost everything on its first upgrade.

APP_CACHE_BUSTER no longer collides with 1.9.6. Both releases shipped 4327, so an upgraded installation kept serving responses cached under 1.9.6 keys.

V25 migrates two console schema changes it was missing. projects.onboarding and schedules.projectInternalId never reached an upgraded installation: boot-time sync only creates missing collections, never new attributes on existing ones. The console "Get started" checklist stayed empty forever as a result.

DocumentsDB and VectorsDB are reachable and optional. Their connections were pinned to hardcoded hosts that compose never forwarded, so a default install returned 201 on database create and then failed on the first write. Both are now configurable, both can be turned off, and the installer deploys only the engines the enabled products actually need.

utopia-php/platform is pinned to a released tag. The build previously resolved a mutable branch reference under an invented version, so a force-push or branch deletion would have broken every build.

upgrade --database warns instead of silently ignoring the flag. An upgrade always keeps the engine the installation already uses; the flag was accepted and discarded without a word.

New

_APP_LIMIT_DATABASE_BATCH makes the bulk-operation limit configurable. Previously a hard-coded 100, so bulk row and document writes rejected anything larger and self-hosted operators had no way to raise it. Defaults to 100, so existing installations are unchanged.

DocumentsDB and VectorsDB can be turned off through _APP_DOCUMENTSDB and _APP_VECTORSDB, asked for during install. A disabled product's routes return general_service_disabled and its engine is left out of the deployment.

Known limitations

• utopia-php/http still resolves to 2.0.0-rc23. Tagged and reproducible, but an RC dependency to resolve before GA.
• The general_service_disabled message says the service can be enabled from the console; for these products it is an operator setting, not a console one.

Feedback

Please report anything you hit against this candidate — upgrade paths from 1.9.x on MariaDB and MongoDB are the most valuable to exercise.