Aller au contenu principal
Gaprod

Nextcloud AppAPI : configurer un Deploy Daemon en 2026

Billy Rousseau— Fondateur de Gaprod10 min read

Vous voulez installer une application externe dans Nextcloud, mais l'App Store réclame d'abord un Nextcloud AppAPI Deploy Daemon ? En 2026, ce composant sert d'intermédiaire entre Nextcloud et les ExApps exécutées hors du processus PHP, le plus souvent dans des conteneurs. Il ne suffit pas d'activer AppAPI : il faut aussi choisir une architecture, relier le moteur de déploiement, configurer le proxy et tester le chemin complet.

Ce guide explique le rôle de chaque brique, le choix entre HaRP et les méthodes historiques, l'enregistrement du daemon, les contrôles de sécurité et le diagnostic avant production. Pour replacer ces éléments dans l'ensemble de la plateforme, commencez par le guide complet de Nextcloud.

À quoi servent AppAPI, les ExApps et le Deploy Daemon ?

Les applications Nextcloud classiques s'exécutent en PHP dans l'environnement du serveur. Les ExApps, contraction de « External Apps », permettent d'utiliser d'autres langages et des dépendances séparées. Elles sont généralement distribuées sous forme d'images de conteneur. Cette architecture convient notamment à plusieurs applications d'intelligence artificielle, mais AppAPI n'est pas limité à l'IA.

AppAPI assure l'intégration avec Nextcloud. Toutes les ExApps en dépendent, et la documentation officielle indique que l'application est installée automatiquement par défaut depuis Nextcloud 30.0.1. Elle reste facultative : une instance qui n'utilise aucune application externe peut la désactiver depuis la gestion des applications.

Le Deploy Daemon fournit le chemin opérationnel entre AppAPI et l'environnement d'exécution. Il permet à Nextcloud d'installer, de joindre, de contrôler et de mettre à jour les ExApps. Le daemon n'est donc ni l'ExApp elle-même, ni un simple réglage d'interface. Sa configuration décrit notamment le type de déploiement, l'hôte, le réseau, l'URL de l'instance et les ressources accessibles.

ÉlémentRôlePoint de contrôle
AppAPIIntégrer les ExApps à NextcloudVersion compatible et application activée
Deploy DaemonPiloter le déploiement et la communicationConnexion, réseau, secret et méthode
HaRPRelayer les appels vers Docker et les ExAppsProxy, ports internes et clé partagée
ExAppFournir la fonction installéeImage, version, ressources et provenance

AppAPI seul ne déploie pas une ExApp

Avant de cliquer sur Installer dans l'App Store, le Deploy Daemon doit être enregistré, joignable et validé avec l'action Test Deploy.

Quel Deploy Daemon choisir pour une instance Nextcloud ?

Nextcloud présente HaRP comme la méthode recommandée pour installer les ExApps. HaRP agit à la fois comme intermédiaire vers Docker et comme proxy vers les applications externes. Son tunnel FRP évite, dans une configuration standard, d'exposer chaque port d'ExApp sur l'hôte ou de rendre chaque conteneur directement joignable depuis le serveur Nextcloud.

HaRP peut aussi acheminer directement certaines requêtes venant du navigateur ou d'une API vers l'ExApp. Le serveur Nextcloud reste impliqué dans la validation de l'utilisateur, mais ne relaie pas nécessairement tout le contenu applicatif. Ce chemin prend en charge des usages que le proxy historique gère moins bien, notamment les connexions WebSocket.

Le Docker Socket Proxy reste documenté et pris en charge lorsque l'administrateur ne peut pas modifier le reverse proxy principal. Il transmet à AppAPI un accès filtré au moteur Docker, mais les appels applicatifs suivent un chemin différent. La méthode manual-install est réservée aux développements ou aux architectures particulières dans lesquelles l'ExApp est lancée manuellement.

SituationChoix à évaluerLimite principale
Nextcloud et ExApps sur le même hôte ou réseau DockerHaRPModification du reverse proxy requise
Nextcloud AIO avec conteneur HaRP activéDaemon créé automatiquementVérifier tout de même Test Deploy
Aucun accès à la configuration du reverse proxyDocker Socket ProxyRoutage moins direct vers les ExApps
Développement ou processus lancé hors Dockermanual-installDéploiement et exploitation à votre charge

L'Assistant IA de Nextcloud est un cas d'usage possible, pas un synonyme d'AppAPI. Un projet IA ajoute ses propres modèles, bases, volumes et besoins de calcul. Configurez d'abord une chaîne AppAPI stable avec une ExApp de test avant d'ajouter une charge lourde.

Quels prérequis préparer avant d'enregistrer HaRP ?

Relevez d'abord la version exacte de Nextcloud, d'AppAPI et de l'ExApp visée. Une fiche App Store peut imposer une branche minimale ou maximale. Vérifiez ensuite que le moteur de conteneurs fonctionne et que son stockage dispose d'une marge suffisante pour télécharger une image, créer un nouveau conteneur et conserver temporairement l'ancienne version pendant une intervention.

Le réseau doit permettre trois communications distinctes : AppAPI vers HaRP, l'ExApp vers HaRP et l'ExApp vers l'URL Nextcloud déclarée. Pour une installation sur l'hôte, la documentation utilise par défaut le port HTTP 8780 pour HaRP et le port 8782 pour le serveur FRP. Dans un réseau Docker commun, utilisez les noms de services et gardez ces ports internes au réseau lorsque l'architecture le permet.

Préparez aussi une clé partagée longue et propre à cette instance. La variable HP_SHARED_KEY du conteneur HaRP et le champ correspondant dans AppAPI doivent contenir la même valeur. Ne reprenez pas le secret d'exemple de la documentation, ne le placez pas dans le dépôt Git et ne l'affichez pas dans un ticket.

Le paramètre NC_INSTANCE_URL doit désigner une URL que HaRP et les ExApps peuvent réellement joindre. Cette URL technique peut différer de l'adresse utilisée par l'administrateur pour ouvrir l'interface, à condition que Nextcloud l'accepte et que le certificat, le DNS et le proxy soient cohérents.

Architecture d'un Deploy Daemon Nextcloud reliant le reverse proxy, AppAPI, HaRP et des ExApps isolées

Enfin, décidez où passent les requêtes destinées aux ExApps. HaRP exige une règle dans le reverse proxy principal de Nextcloud. Reprenez l'exemple officiel correspondant à Nginx, Apache, Caddy ou Traefik, puis adaptez uniquement les hôtes et réseaux de votre installation. Une configuration copiée depuis une autre topologie peut réussir le contrôle Docker tout en laissant les appels du navigateur en erreur.

Comment enregistrer et tester le Deploy Daemon ?

La méthode la plus lisible passe par Administration > AppAPI, puis Register Daemon. Pour une installation locale classique, choisissez le modèle HaRP adapté à l'hôte ou au réseau Docker. Contrôlez le nom, la méthode docker-install, l'adresse HTTP de HaRP, l'URL Nextcloud, le réseau, la clé partagée et le périphérique de calcul.

Cliquez d'abord sur Check connection. Ce contrôle vérifie la communication lors de la saisie, mais ne remplace pas un déploiement réel. Enregistrez ensuite le daemon, ouvrez son menu à trois points et lancez Test Deploy. La documentation demande ce second test pour confirmer que la chaîne peut réellement créer, joindre puis contrôler une ExApp de test.

L'enregistrement peut aussi être automatisé avec OCC. Cet exemple reprend la syntaxe officielle pour un HaRP exposé uniquement sur l'hôte. Adaptez le compte système, le chemin d'occ, les adresses et le secret :

sudo -u www-data php occ app_api:daemon:register \
  harp_proxy_host "HaRP Proxy Host" \
  docker-install http 127.0.0.1:8780 \
  https://cloud.exemple.fr \
  --harp \
  --harp_frp_address 127.0.0.1:8782 \
  --harp_shared_key "REMPLACER_PAR_UN_SECRET_LONG" \
  --set-default \
  --compute_device cpu

Listez ensuite les daemons enregistrés sans modifier l'instance :

sudo -u www-data php occ app_api:daemon:list

Les valeurs 127.0.0.1 ne conviennent pas lorsque Nextcloud s'exécute dans un autre conteneur ou sur une autre machine. Dans ce cas, utilisez une adresse joignable depuis chaque composant et appliquez l'exemple officiel correspondant au réseau Docker ou au serveur distant.

Un bouton vert ne valide pas toute l'application

Après Test Deploy, installez une seule ExApp non critique, ouvrez son interface avec un compte pilote, redémarrez son conteneur et vérifiez les journaux. La recette doit couvrir le navigateur, AppAPI, HaRP, le moteur de conteneurs et le retour vers Nextcloud.

Comment limiter les ressources et sécuriser les ExApps ?

Un Deploy Daemon peut appliquer une limite de mémoire et de CPU à chaque conteneur qu'il crée. Dans l'interface, la mémoire est saisie en Mio et le processeur en nombre de cœurs. Sans limite configurée, les conteneurs concernés peuvent utiliser les ressources disponibles sur l'hôte. Fixez une première enveloppe selon la documentation de l'ExApp, puis mesurez les erreurs, la latence et la consommation réelle.

Le périphérique de calcul se choisit au niveau du daemon. Ne sélectionnez pas CUDA ou ROCm uniquement parce qu'un accélérateur existe sur le serveur. L'image de l'ExApp, son moteur et sa documentation doivent prendre en charge ce chemin. Pour plusieurs applications IA, le guide de recherche plein texte Nextcloud rappelle aussi qu'un index ou un service externe ajoute ses propres données et sauvegardes.

La documentation de sécurité Nextcloud demande de traiter chaque conteneur comme s'il disposait d'un accès puissant sur son propre périmètre. N'installez pas une ExApp inconnue, vérifiez son éditeur, son dépôt, son image et les permissions demandées. Séparez le réseau des ExApps des services inutiles et n'exposez pas directement le moteur Docker sur Internet.

Ajoutez ces contrôles à votre procédure :

  1. conserver la clé HaRP dans un gestionnaire de secrets ;
  2. limiter l'accès aux réglages AppAPI aux administrateurs nécessaires ;
  3. appliquer des limites CPU et mémoire avant le pilote ;
  4. sauvegarder la configuration Nextcloud et les volumes propres à l'ExApp ;
  5. relever l'image et le tag réellement déployés ;
  6. tester l'arrêt, le redémarrage, la mise à jour et la désinstallation ;
  7. examiner les journaux sans y copier de secret ni de donnée utilisateur.

Le guide de sécurité Nextcloud complète cette liste pour les comptes, les mises à jour, l'authentification et la surveillance générale. AppAPI n'annule aucun de ces contrôles : il ajoute une couche à inventorier.

Pourquoi Test Deploy ou l'installation d'une ExApp échoue ?

Commencez par le message exact et l'heure du test. Une erreur de connexion immédiate pointe souvent vers l'adresse 8780, le protocole HTTP ou HTTPS, le pare-feu ou une clé partagée différente. Une création de conteneur impossible oriente plutôt vers l'accès au moteur Docker, le réseau déclaré, le stockage ou l'image indisponible.

Si le conteneur démarre mais que l'interface reste inaccessible, contrôlez l'adresse FRP 8782, la route du reverse proxy et la capacité de l'ExApp à joindre NC_INSTANCE_URL. Une URL publique peut fonctionner depuis votre navigateur tout en échouant depuis un réseau Docker qui résout le domaine vers une mauvaise adresse.

Une image qui ne se télécharge pas peut aussi venir du registre. AppAPI permet de remplacer un registre déclaré par un miroir, mais le chemin et le tag de l'image restent inchangés. La documentation précise également que les identifiants d'un simple docker login ne sont pas transmis aux téléchargements demandés par AppAPI. Pour un registre privé authentifié, suivez la méthode officielle de préchargement ou la configuration propre à votre orchestrateur.

Avant de relancer au hasard, vérifiez dans cet ordre :

  1. version de Nextcloud, d'AppAPI et de l'ExApp ;
  2. daemon présent dans app_api:daemon:list et défini par défaut si nécessaire ;
  3. adresse HaRP et égalité de la clé partagée ;
  4. réseau Docker et résolution de l'URL Nextcloud ;
  5. règle du reverse proxy pour les appels ExApp ;
  6. accès au registre et présence du tag attendu ;
  7. limites de ressources, espace disque et journaux du conteneur ;
  8. nouveau Test Deploy après une seule correction mesurable.

Conclusion

AppAPI ouvre Nextcloud aux ExApps, mais le Deploy Daemon porte la partie sensible du déploiement. Pour une nouvelle installation, partez de HaRP, gardez ses ports sur un réseau privé, générez une clé unique et adaptez le reverse proxy à votre topologie. Enregistrez ensuite le daemon, imposez des limites de ressources et exigez un Test Deploy réussi avant toute application métier. Terminez par un pilote réversible qui couvre installation, accès, redémarrage, mise à jour et suppression.

Découvrir l'offre Nextcloud GaprodCompatibilité AppAPI et ExApps à confirmer avant commande

Sources officielles

Articles similaires

Prêt à démarrer avec Gaprod ?

Hébergement web, VPS et solutions cloud 100% français, avec support expert inclus.

30j rembourséMigration gratuiteSupport 7j/7