Comment auto-héberger SearXNG en 2026 : Search API, limites de débit et TLS

La plupart des guides d’installation de SearXNG s’arrêtent au premier chargement de page. C’est trop tôt : les moteurs peuvent bloquer l’adresse IP du serveur, ou certains formats peuvent ne pas inclure json pour les clients d’API. Un test de production utile est plus exigeant : effectuer des recherches HTML et JSON, vérifier que plusieurs moteurs fournissent des résultats et déclencher le limiteur configuré depuis un client de test.

Le rôle de SearXNG est simple : un moteur de métarecherche axé sur la confidentialité et une Search API. Son périmètre opérationnel ne se limite pas au processus web. La dépendance, l’état stocké et la route publique doivent donc être explicitement définis avant l’arrivée des données réelles.

Définir d’abord les critères de réussite de SearXNG

Ne laissez pas l’image SearXNG déterminer par inadvertance l’architecture de production. L’image fournit un processus sur le port 8080 ; le stockage, le routage et les exigences externes nécessitent toujours des cycles de vie définis avec soin. Le contrat réseau de SearXNG prévoit Redis ou Valkey lorsque les fonctionnalités de limitation et de détection des bots sont activées. Conservez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à SearXNG un identifiant de service aux permissions limitées.

Le déploiement est prêt pour des tests plus approfondis lorsqu’il peut effectuer des recherches HTML et JSON, vérifier que plusieurs moteurs fournissent des résultats et déclencher le limiteur configuré depuis un client de test. Suivez la transaction dans les logs et surveillez la latence des moteurs en amont, les requêtes simultanées, l’analyse des résultats et les blocages appliqués à l’adresse IP du serveur. Ces observations permettent de déterminer si la topologie actuelle isole correctement chaque composant.

Séparer les conteneurs remplaçables des données persistantes

Créez un manifeste de récupération pour SearXNG : settings.yml, la configuration du limiteur et les plugins locaux éventuels. Montez /etc/searxng avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Vérifiez dès maintenant les propriétaires et l’espace libre, car un chemin monté mais non accessible en écriture ne fournit aucune persistance réelle.

Effectuez les sauvegardes dans un domaine de panne distinct du serveur en fonctionnement. Recréez SearXNG à partir de son image épinglée et vérifiez que les moteurs personnalisés, les formats, les règles du limiteur et les paramètres du proxy sont restaurés, puis qu’une requête connue produit des résultats provenant de plusieurs moteurs. Le guide des volumes persistants vous aide à traduire cet exercice en politique de snapshots et de rétention.

Fermer les accès temporaires de configuration

Les identifiants de bootstrap sont temporaires ; le modèle de confiance est permanent. Avec SearXNG, veillez notamment à ne pas déployer le secret_key d’exemple fourni par défaut ni à désactiver les contrôles de débit sur un endpoint public. Conservez une clé secrète différente de la valeur par défaut, activez les contrôles anti-abus et n’exposez JSON que lorsqu’un agent ou une application en a besoin.

Traitez SEARXNG_SECRET selon son rôle dans SearXNG : gardez les valeurs sensibles hors de Git, documentez les effets d’une rotation et ne remplacez jamais un exemple public par une valeur de production. Exécutez l’image sans capabilities Linux superflues et n’exposez que la route applicative publique. Gardez une visibilité sur l’activité des administrateurs sans enregistrer les valeurs secrètes.

Documenter un déploiement SearXNG validé

Transformez le smoke test de SearXNG en commande de release reproductible ou en runbook succinct. Sa sortie doit démontrer le résultat suivant : effectuer des recherches HTML et JSON, vérifier que plusieurs moteurs fournissent des résultats et déclencher le limiteur configuré depuis un client de test. Enregistrez avec le résultat la version de l’application, le digest du conteneur, le hostname de la route et l’identifiant des données de test.

Exécutez la même vérification après un remplacement standard du conteneur et après la restauration de settings.yml, de la configuration du limiteur et des plugins locaux éventuels dans un autre environnement. La restauration est réussie lorsque les moteurs personnalisés, les formats, les règles du limiteur et les paramètres du proxy sont restaurés, et qu’une requête connue produit des résultats provenant de plusieurs moteurs. Comparez les délais et la consommation liés à la latence des moteurs en amont, aux requêtes simultanées, à l’analyse des résultats et aux blocages appliqués à l’adresse IP du serveur ; une variation importante mérite une investigation, même si l’action finale réussit toujours.

Testez ensuite une panne sans danger : refusez temporairement à l’identité de test l’accès à Redis ou Valkey lorsque les fonctionnalités de limitation et de détection des bots sont activées. Vérifiez que SearXNG signale l’erreur et revient à un état normal sans modifications manuelles destructrices. Conservez uniquement l’extrait de log nécessaire, après l’avoir expurgé. Cette validation en quatre parties couvre le démarrage, la persistance, la récupération et la gestion des pannes.

Exécuter la première instance représentative de la production

Utilisez le conteneur comme un runtime remplaçable, et non comme la source de vérité.

docker run -d \
  --name searxng \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v searxng-data:/etc/searxng \
  -e SEARXNG_SECRET=replace-with-a-long-random-value \
  searxng/searxng:latest

Ajoutez les paramètres de connexion validés pour Redis ou Valkey lorsque les fonctionnalités de limitation et de détection des bots sont activées ; utilisez des noms privés pour les services privés. Inspectez l’utilisateur du conteneur, les chemins accessibles en écriture et le listener lié avant de l’exposer. Exécutez l’action complète — effectuer des recherches HTML et JSON, vérifier que plusieurs moteurs fournissent des résultats et déclencher le limiteur configuré depuis un client de test — puis enregistrez la référence exacte de l’image ayant produit le résultat.

Éviter qu’un proxy fonctionnel ne masque une panne applicative

Exposez un seul hostname HTTPS pour SearXNG et gardez le port brut 8080 privé. Définissez server base_url et trusted proxy headers pour HTTPS. Les navigateurs et les clients d’API ne découvriront ainsi pas deux adresses concurrentes.

Depuis un client vierge, exécutez la transaction validée et examinez la première requête en échec. Utilisez le guide des domaines personnalisés lorsque le DNS ou TLS est incorrect. Considérez « les moteurs bloquent l’adresse IP du serveur ou certains formats n’incluent pas json pour les clients d’API » comme un diagnostic applicatif distinct une fois la route validée.

Des logs qui répondent à la prochaine question

La première métrique opérationnelle utile pour SearXNG est sa capacité à effectuer des recherches HTML et JSON, à vérifier que plusieurs moteurs fournissent des résultats et à déclencher le limiteur configuré depuis un client de test. Associez-la aux signaux de saturation liés à la latence des moteurs en amont, aux requêtes simultanées, à l’analyse des résultats et aux blocages appliqués à l’adresse IP du serveur. Une probe limitée au processus ne doit pas appeler de dépendances coûteuses ni redémarrer le conteneur parce qu’un service en amont est brièvement indisponible.

Traitez les mises à niveau comme des changements de données, car la syntaxe des paramètres, les définitions des moteurs et le comportement du limiteur peuvent évoluer. Déployez donc les changements de configuration et d’image dans une même review. Épinglez les versions, répétez la procédure sur un état restauré et conservez l’image précédente tant qu’un rollback reste possible. Lorsque les moteurs bloquent l’adresse IP du serveur ou que certains formats n’incluent pas json pour les clients d’API, conservez les logs précédant le redémarrage ; ils contiennent généralement le message causal.

Intégrer SearXNG au cycle de vie de Dockup

La couche plateforme de SearXNG comprend le port 8080, l’ingress, TLS, la configuration du runtime, le stockage et l’accessibilité des dépendances. Dockup peut reproduire ces éléments pour sa propre infrastructure ou pour un serveur connecté par le client.

L’opérateur termine ensuite la couche produit : définir server base_url et trusted proxy headers pour HTTPS ; appliquer cette règle d’accès — conserver une clé secrète différente de la valeur par défaut, activer les contrôles anti-abus et n’exposer JSON que lorsqu’un agent ou une application en a besoin ; puis exécuter « effectuer des recherches HTML et JSON, vérifier que plusieurs moteurs fournissent des résultats et déclencher le limiteur configuré depuis un client de test ». L’enregistrement de ce test avec le déploiement évite de confondre le provisioning automatisé avec la disponibilité de l’application.

Foire aux questions

De quoi SearXNG a-t-il besoin pour un déploiement de production ?

Acheminez le conteneur SearXNG sur le port 8080 via une seule origine HTTPS. La dépendance réseau est Redis ou Valkey lorsque les fonctionnalités de limitation et de détection des bots sont activées. Ne considérez pas SearXNG comme prêt tant que vous ne pouvez pas effectuer des recherches HTML et JSON, vérifier que plusieurs moteurs fournissent des résultats et déclencher le limiteur configuré depuis un client de test.

Quelles données SearXNG faut-il sauvegarder ?

Conservez /etc/searxng et incluez settings.yml, la configuration du limiteur et les plugins locaux éventuels dans le même manifeste de récupération. Une restauration propre de SearXNG n’est validée que lorsque les moteurs personnalisés, les formats, les règles du limiteur et les paramètres du proxy sont restaurés, et qu’une requête connue produit des résultats provenant de plusieurs moteurs.

SearXNG a-t-il besoin de HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de SearXNG et gardez le port 8080 sur la route interne. Appliquez correctement le paramètre SearXNG : définir server base_url et trusted proxy headers pour HTTPS. Pour SearXNG, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transport et garantit un comportement cohérent des clients dépendant de l’origine.

Comment tester une mise à niveau de SearXNG ?

Restaurez l’état actuel de SearXNG dans un déploiement isolé, appliquez la version candidate et répétez sa transaction de validation. Soyez particulièrement attentif, car la syntaxe des paramètres, les définitions des moteurs et le comportement du limiteur peuvent évoluer. Déployez donc les changements de configuration et d’image dans une même review. Conservez l’image SearXNG précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.