Appwrite 2.0 s’auto-héberge avec 16 conteneurs au lieu de 33
Appwrite a rendu la version 2.0 disponible en auto-hébergement le 7 septembre 2026. Dans une nouvelle installation PostgreSQL, la topologie combinée choisie par défaut fait fonctionner la pile avec 16 conteneurs, contre 33 en topologie séparée, selon l’annonce détaillée d’Appwrite.
Pour une instance existante, cette sortie du 7 septembre ne déclenche toutefois ni passage automatique à PostgreSQL ni changement imposé de topologie. La mise à niveau conserve ces deux choix et nécessite une migration des données après l’installation de la nouvelle version.
Les 16 conteneurs correspondent à une topologie précise
Le nombre mis en avant ne décrit pas toutes les configurations d’Appwrite 2.0. Il correspond à la pile PostgreSQL standard utilisant la nouvelle topologie combinée; la topologie séparée reste disponible et porte cette même pile à 33 conteneurs.
En mode combiné, les files de travaux asynchrones — courriels, certificats TLS, compilations, exécutions de fonctions ou captures — sont réunies dans un conteneur de workers. Les tâches planifiées partagent de la même manière un conteneur de scheduler, tandis que chaque file conserve son propre groupe de coroutines.
Le bénéfice immédiatement vérifiable est donc une surface d’exploitation plus compacte: moins de services permanents et un point commun pour consulter les journaux des workers. Cette réduction ne permet pas, à elle seule, de promettre que la mémoire ou les besoins en calcul seront divisés dans la même proportion; Appwrite ne fournit pas de mesure générale reliant directement le nombre de conteneurs à une économie de ressources.
La topologie séparée conserve son intérêt lorsqu’une file doit disposer de réplicas, de limites de ressources ou de métriques qui lui sont propres. Le choix oppose ainsi une administration simplifiée à la possibilité de dimensionner indépendamment chaque catégorie de tâches.
PostgreSQL devient le défaut, sans remplacer les bases existantes
Le programme d’installation sélectionne désormais PostgreSQL pour une nouvelle instance, mais MariaDB et MongoDB restent proposés. Les API exposées aux applications demeurent les mêmes avec les trois moteurs, et le choix effectué lors de l’installation reste attaché à l’instance.
Une mise à niveau en place conserve donc MariaDB, MongoDB ou PostgreSQL selon la configuration d’origine. Passer simultanément d’un ancien moteur à PostgreSQL demande une nouvelle installation et un transfert de projets: ce n’est pas un effet automatique de la mise à niveau du serveur.
Il faut aussi distinguer cette base interne de l’offre de bases PostgreSQL natives, directement accessibles avec des outils SQL. Une analyse indépendante de la version 2.0 précise que ces bases natives sont des services Cloud dédiés, tandis que PostgreSQL devient le moteur interne par défaut des nouvelles installations auto-hébergées.
La migration impose un passage préalable par Appwrite 1.9.6
La procédure officielle ne prévoit pas un saut direct depuis n’importe quelle version 1.x. Les instructions de mise à niveau vers Appwrite 2.0.0 exigent de passer d’abord à la version 1.9.6, de sauvegarder les données, d’installer 2.0.0 puis d’exécuter la commande de migration.
Appwrite recommande également d’examiner les changements incompatibles et de répéter l’opération sur une instance hors production. La durée de la migration dépend du volume de données; le processus utilise plusieurs threads, de sorte que les ressources processeur disponibles peuvent influer sur son exécution.
Avant de modifier une instance de production, la décision porte sur cinq éléments distincts:
- amener l’instance source à la version intermédiaire requise;
- sauvegarder la base, les volumes et la configuration nécessaires à une restauration;
- conserver le moteur actuel ou traiter séparément un transfert vers une nouvelle instance PostgreSQL;
- maintenir la topologie existante ou demander explicitement le mode combiné ou séparé;
- vérifier sur une copie les API, les permissions, le stockage, les fonctions et les tâches planifiées.
L’outil de mise à niveau lit la topologie du fichier Compose existant et la reproduit. L’administrateur peut la remplacer pendant l’opération avec l’option correspondante, mais ce choix reste indépendant de la migration du schéma, exécutée ensuite dans la pile Appwrite.
ClickHouse ajoute une nouvelle donnée à exploiter ou à sauvegarder
Appwrite 2.0 enregistre les mesures d’usage par ressource de projet dans un conteneur ClickHouse fourni avec la pile. Les lectures analytiques sont ainsi séparées des requêtes adressées à la base interne, au prix d’un composant persistant supplémentaire à surveiller.
Pour l’exploitation, le passage à 16 conteneurs ne dispense donc pas d’un nouvel inventaire. Il faut décider si l’historique de ces métriques doit entrer dans la politique de sauvegarde, puis adapter la surveillance du disque et la rétention à cette décision. Il s’agit d’un choix opérationnel: la documentation de sortie ne promet pas que la sauvegarde de la base principale couvre automatiquement ClickHouse.
La pile reçoit également un conteneur d’orchestration pour les compilations de Functions et Sites ainsi qu’un service de géolocalisation des adresses IP. La baisse du total provient du regroupement des workers et des schedulers malgré l’arrivée de ces composants.
L’édition auto-hébergée ne reprend pas encore toute l’offre Cloud
La version auto-hébergée apporte notamment Console IV, construite avec TanStack Start, Hyperloop B, les nouvelles topologies de workers, les métriques d’usage et des intégrations Git supplémentaires. Elle ne doit cependant pas être confondue avec l’ensemble des services lancés parallèlement dans Appwrite Cloud.
Appwrite Firewall, l’API S3 pour Storage et le journal d’activité des événements de projet ont été présentés comme disponibles d’abord dans le Cloud, avec une arrivée ultérieure en auto-hébergement mais sans version ni date ferme. Les bases PostgreSQL et MySQL natives restent elles aussi distinctes du moteur interne sélectionné par l’installateur communautaire.
L’état confirmé au 7 septembre est donc celui d’Appwrite 2.0.0 disponible pour une installation autonome, avec une pile PostgreSQL combinée de 16 conteneurs et un parcours de migration documenté. La parité avec les fonctions Cloud encore absentes dépendra de prochaines versions, dont le calendrier n’a pas été précisé.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.