Searx est-il mort ? Installez plutôt SearXNG

Searx ou SearXNG : lequel installer ?

Searx et SearXNG sont deux projets différents qui portent presque le même nom, et un seul reçoit encore des correctifs. Installez SearXNG. Le projet Searx d’origine n’a reçu aucun commit depuis avril 2023, et son propre README résume la situation en une ligne : « Searx n’est plus maintenu. »

Le problème est donc pratique, et non philosophique. Les deux projets utilisent une même capture d’écran, partagent la majeure partie d’un fichier de configuration et la moitié de leur nom. Un guide écrit pour l’un semble donc s’appliquer à l’autre. Ce n’est pas le cas. Le fichier de configuration se trouve ailleurs, la protection contre les bots est nouvelle et le nom du paquet a disparu des versions actuelles d’Ubuntu. La suite présente la distinction entre les deux projets, les commandes permettant de vérifier vous-même leur état et les changements à connaître avant de mettre une instance en service.

Ce qu’est Searx et l’origine de SearXNG

Searx est un métamoteur de recherche. Il ne conserve pas son propre index. Il prend votre requête, la transmet à d’autres services de recherche comme Bing, DuckDuckGo ou Wikipedia, puis regroupe les résultats dans une seule page. Ces services voient ainsi l’adresse du serveur au lieu de la vôtre. En contrepartie, il faut assurer la maintenance. Chaque moteur est un petit morceau de code qui analyse le HTML ou l’API d’un autre service. Il cesse donc de fonctionner dès que ce service en amont change. La fiabilité d’un métamoteur dépend entièrement des personnes qui corrigent ses modules de moteurs.

Le dépôt searx a été créé en octobre 2013. En avril 2021, un ancien mainteneur a créé SearXNG sous la forme d’un fork. « NG » signifie next generation. Le README de searx décrit les deux projets côte à côte. Cette description reste le résumé le plus clair de leur séparation :

SearxNG est un fork de searx, créé par un ancien mainteneur de searx.

SearxNG propose des rolling releases, des dépendances mises à jour plus fréquemment et des moteurs corrigés plus rapidement.

Le désaccord à l’origine du fork portait sur les diagnostics. Searx considérait que l’instance ne devait pas conserver les données d’utilisation. Ses paramètres par défaut le déclarent explicitement : enable_stats: False # activate /stats page - note: it may leak usage data. SearXNG a fait le choix inverse et inclut enable_metrics: true dans ses paramètres par défaut. Ces métriques alimentent les barres de temps de réponse et les pages d’erreur, ce qui permet de repérer et de corriger facilement un moteur défaillant. Les deux positions peuvent se défendre. Une seule a continué à publier du code.

Searx est-il mort ? Comment le vérifier vous-même

« Mort » n’est pas un état signalé par GitHub. Lisez donc les deux indicateurs disponibles et tirez-en votre conclusion. Le premier consiste à vérifier si le dépôt est archivé et à quelle date il a reçu son dernier push.

curl -s https://api.github.com/repos/searx/searx | jq -r '.archived, .pushed_at'
curl -s https://api.github.com/repos/searxng/searxng | jq -r '.archived, .pushed_at'

Le 18 octobre 2026, la première commande affiche false et 2026-05-14T10:02:22Z. La seconde affiche false et un horodatage récent, généralement daté du dernier jour ou des deux derniers jours. Notez la première valeur. Le dépôt searx n’est pas archivé et personne n’en a verrouillé l’accès. C’est pourquoi cette question revient régulièrement.

pushed_at est un indicateur peu fiable à lui seul, car sa valeur change après un push vers n’importe quelle branche, y compris pour une modification d’une seule ligne de documentation. Consultez plutôt la liste des commits.

curl -s 'https://api.github.com/repos/searx/searx/commits?per_page=5' \
  | jq -r '.[] | .commit.committer.date[:10] + "  " + (.commit.message | split("\n")[0])'

Au 18 octobre 2026, cette commande affiche :

2026-05-14  [doc] add hister reference
2023-09-07  Searx is no longer maintained
2023-04-05  Fix quoting issue in search_operator plugin (#3479)
2023-04-04  Bump pallets-sphinx-themes from 2.0.2 to 2.0.3 (#3450)
2023-04-04  Update searx.data - update_wikidata_units.py (#3454)

Lisez la liste de bas en haut. Le travail courant s’arrête en avril 2023. Le commit de septembre 2023 correspond à l’ajout de l’avis par les mainteneurs dans le README. Le seul commit effectué depuis concerne la documentation, car l’auteur d’origine est passé à Hister, un outil de recherche qui indexe les pages et les fichiers que vous choisissez au lieu d’interroger d’autres moteurs. C’est une approche différente, et elle peut être utile si ce que vous voulez réellement est un moteur de recherche personnel pour votre propre contenu.

Le deuxième indicateur est le packaging, et c’est précisément ce dont dépendent discrètement la plupart des anciens tutoriels.

• PyPI contient vingt searx releases, de la version 0.1.2 en janvier 2014 à la version 0.17.0 en juillet 2020, et elles sont toutes encore téléchargeables. pip install searx réussit et vous fournit la plus récente, la version 0.17.0, qui correspond à du code datant de neuf mois avant l’existence du fork.
• Debian a fourni searx 1.1.0 dans Debian 12 (bookworm) et le conserve encore dans unstable. Le paquet a été retiré de testing en octobre 2023. Debian 13 (trixie) ne contient donc aucun paquet searx.
• Ubuntu l’a fourni pour la dernière fois dans la version 23.10 (mantic), en version 1.1.0. La dernière version LTS qui l’inclut est la 22.04, en version 1.0.0, et le paquet a été supprimé de la version 24.04 avant sa sortie. Sur Ubuntu 24.04, sudo apt install searx se termine par E: Unable to locate package searx.
• searx.space, l’annuaire d’instances publiques vers lequel le projet orientait toujours les utilisateurs, répertorie désormais des instances SearXNG.

Voici donc la situation réelle. Le code est public, il fonctionne encore et vous pouvez le cloner et le démarrer aujourd’hui. En revanche, vous n’obtenez ni correctifs pour les moteurs ni mises à jour de sécurité. Or, pour un métamoteur de recherche, c’est l’essentiel. Les moteurs se dégradent selon le calendrier de leurs propriétaires. Une instance non maintenue renvoie chaque mois moins de résultats, sans que personne n’ait besoin d’intervenir sur le serveur.

Ce que le fork a changé pour une nouvelle instance

Le fichier de configuration a changé d’emplacement et sert maintenant de surcharge

Avec Searx, vous modifiiez searx/settings.yml dans l’arborescence des sources. Avec SearXNG, le fichier se trouve dans /etc/searxng/settings.yml, et le processus le localise grâce à la variable d’environnement SEARXNG_SETTINGS_PATH. Le modèle que l’installateur y copie est court :

use_default_settings: true

general:
  debug: false
  instance_name: "SearXNG"

search:
  safe_search: 2
  autocomplete: 'duckduckgo'
  formats:
    - html

server:
  # Is overwritten by ${SEARXNG_SECRET}
  secret_key: "ultrasecretkey"
  limiter: true
  image_proxy: true

valkey:
  # URL to connect valkey database. Is overwritten by ${SEARXNG_VALKEY_URL}.
  url: valkey://localhost:6379/0

use_default_settings: true est la ligne qui change votre méthode de travail. Avec cette ligne, votre fichier ne contient que les surcharges, et chaque clé absente reprend la valeur par défaut fournie dans le paquet. Sans cette ligne, votre fichier doit décrire toute la configuration, moteur par moteur. C’est ainsi qu’une instance démarre correctement, mais ne trouve aucun résultat. Un ancien fichier de configuration Searx copié à cet emplacement constitue une configuration complète avec des noms de clés différents. Il suit donc la seconde méthode, et échoue de cette façon.

La clé secrète empêche le processus de démarrer

sudo -H sed -i -e "s/ultrasecretkey/$(openssl rand -hex 16)/g" \
              "/etc/searxng/settings.yml"

Exécutez cette commande une fois, après avoir copié le modèle. Si vous l’omettez, SearXNG écrit une ligne dans les journaux et quitte avec le statut 1, car webapp.py compare la clé à la valeur du modèle avant de servir la moindre requête :

server.secret_key is not changed. Please use something else instead of ultrasecretkey.

Le contrôle est ignoré lorsque general.debug est vrai. Une instance peut donc fonctionner correctement dans une session de débogage, puis refuser de démarrer sous systemd ou dans un conteneur. Un conteneur qui redémarre en boucle avec cette ligne dans docker compose logs est soumis à ce contrôle. L’image n’est pas défectueuse.

Le limiter est nouveau et nécessite Valkey

Searx ne faisait aucun rate limiting dans l’application. Les instances Searx publiques plaçaient des services distincts devant l’application : filtron pour filtrer les requêtes et morty pour proxyfier le contenu des résultats. Aucun des deux dépôts n’a reçu de commit depuis janvier 2023 : le dernier commit de filtron date de ce mois-là, et celui de morty date d’avril 2021.

SearXNG assure lui-même ces fonctions. Le rate limiting et la détection des bots sont gérés par le limiter, activé avec server.limiter. Il vaut false dans les valeurs par défaut fournies et true dans le modèle de l’installateur. Il nécessite une base de données Valkey pour stocker ses compteurs. Valkey est un fork de Redis, et Ubuntu 24.04 le fournit sous forme de paquet :

sudo apt install -y valkey-server

server:
  limiter: true

valkey:
  url: valkey://localhost:6379/0

Les guides rédigés avant ce changement de nom configurent à la place un bloc redis:. Reprenez donc le nom de clé indiqué dans la documentation actuelle du limiter. Le réglage détaillé se trouve dans un second fichier, /etc/searxng/limiter.toml, et server.public_instance: true active la détection plus stricte des bots nécessaire à une instance publique, notamment la méthode par jeton de lien. Concrètement, certaines requêtes reçoivent une réponse HTTP 429 au lieu de résultats. Cela concerne aussi vos propres requêtes si vous interrogez l’instance depuis un script. Ce sujet fait l’objet d’une page dédiée : pourquoi une instance SearXNG répond 429 Too Many Requests.

Les moteurs se suspendent eux-mêmes et les délais d’attente sont longs

Lorsqu’un service en amont répond avec un CAPTCHA ou une page indiquant une limite de débit, SearXNG lève une exception typée et cesse d’interroger ce moteur pendant une durée donnée, au lieu de réessayer jusqu’au blocage. Les valeurs par défaut se trouvent dans searx/settings.yml, sous search.suspended_times. Voici les 6 valeurs publiées en octobre 2026 :

[
  {
    "label": "SearxEngineAccessDenied",
    "suspend_seconds": "180"
  },
  {
    "label": "SearxEngineCaptcha",
    "suspend_seconds": "3,600"
  },
  {
    "label": "SearxEngineTooManyRequests",
    "suspend_seconds": "180"
  },
  {
    "label": "cf_SearxEngineCaptcha",
    "suspend_seconds": "1,296,000"
  },
  {
    "label": "cf_SearxEngineAccessDenied",
    "suspend_seconds": "86,400"
  },
  {
    "label": "recaptcha_SearxEngineCaptcha",
    "suspend_seconds": "604,800"
  }
]

Une réponse indiquant simplement un accès refusé suspend ce moteur pendant 180 secondes. Un CAPTCHA le suspend pendant 3,600 secondes. Un CAPTCHA Cloudflare le suspend pendant 1,296,000 secondes, soit quinze jours, et un Google reCAPTCHA pendant 604,800 secondes, soit une semaine. Ces durées longues sont intentionnelles : réessayer après qu’un service a déjà signalé l’adresse peut entraîner le blocage définitif de l’adresse IP de l’instance.

Pendant la suspension d’un moteur, la page de résultats l’ignore et l’indique dans le bloc latéral intitulé « Messages from the search engines ». /stats/errors répertorie les moteurs qui ont échoué. Une nouvelle instance qui renvoie peu de résultats présente généralement ce comportement. L’installation n’est pas nécessairement défectueuse.

L’API JSON est désactivée par défaut

La valeur par défaut fournie est formats: [html], et rien d’autre. L’API dont vos scripts ont besoin reste donc fermée tant que vous ne l’activez pas.

curl -s -o /dev/null -w '%{http_code}\n' \
  'http://127.0.0.1:8888/search?q=test&format=json'

Cette commande affiche 403, car la route de recherche appelle flask.abort(403) lorsque le format demandé ne figure pas dans search.formats. Ajoutez le format, puis redémarrez le service :

search:
  formats:
    - html
    - json

Le fichier de configuration de searx ne contient aucune clé formats. Sa sortie JSON était donc directement disponible. Tous les scripts et extraits de code de cette époque partent de la même hypothèse, et l’échec se résume à une réponse 403 sans explication. Si vous intégrez une instance à vos outils, fournir à un agent un endpoint SearXNG pour effectuer des recherches commence par ce réglage.

Pourquoi les tutoriels Searx copiés-collés échouent

Chacune de ces lignes apparaît dans des guides qui restent bien classés, et chacune échoue ou induit en erreur sur une installation actuelle.

• sudo apt install searx sur Ubuntu 24.04 s’arrête sur E: Unable to locate package searx, car le paquet a été publié pour la dernière fois dans 23.10, puis supprimé de 24.04 avant sa sortie.
• pip install searx réussit et installe la version 0.17.0 de juillet 2020. Rien ne vous avertit qu’elle est antérieure au fork.
• git clone https://github.com/asciimoo/searx fonctionne toujours, car GitHub redirige l’ancien nom du propriétaire. La commande récupère la branche par défaut actuelle, où un commit de documentation de mai 2026 se trouve sur du code applicatif qui n’a plus changé depuis avril 2023.
• Les étapes qui modifient searx/settings.yml dans l’arborescence des sources ne changent rien sur SearXNG, qui lit /etc/searxng/settings.yml.
• Les étapes qui installent filtron ou morty recompilent des composants que SearXNG contient déjà.
• Une URL redis: pour le limiter porte un ancien nom par rapport à la clé valkey: actuelle.

Les guides SearXNG deviennent eux aussi obsolètes, et l’URL de clonage est le moyen le plus rapide de dater un guide. Les fichiers Compose se trouvaient auparavant dans un dépôt searxng-docker séparé. Ce dépôt est maintenant archivé, son dernier push date de mars 2026, et ses fichiers ont été déplacés dans container/ du dépôt principal. La procédure actuelle de démarrage rapide avec un conteneur, issue de la documentation, est la suivante :

mkdir -p ./searxng/core-config/
cd ./searxng/
curl -fsSL \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/docker-compose.yml \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/.env.example
cp -i .env.example .env
nano .env
docker compose up -d

Modifiez .env avant la dernière commande. L’image associe les variables d’environnement aux clés de configuration : SEARXNG_SECRET devient server.secret_key et SEARXNG_BASE_URL devient server.base_url. L’installation de l’hôte par script suit un autre chemin et produit le même résultat :

git clone https://github.com/searxng/searxng.git searxng
cd searxng
sudo -H ./utils/searxng.sh install all

Cette procédure crée l’utilisateur searxng, l’environnement virtuel sous /usr/local/searxng et le service uWSGI, qui constituent la configuration de référence dans la documentation SearXNG. La procédure détaillée correspondante est décrite dans l’installation de SearXNG sur votre propre VPS.

Instance publique ou instance personnelle

Une instance publique est un serveur appartenant à un tiers qui termine votre connexion TLS (transport layer security) ; le logiciel y lit donc votre requête en clair. La documentation de SearXNG pose clairement la question de la confiance : vous devez faire confiance à l'administrateur, et vous ne pouvez pas savoir si les requêtes sont journalisées, agrégées ou transmises à un tiers. La liste visible est courte et complète. La pile technique de l'opérateur peut voir le texte de la requête, l'heure, l'adresse IP d'origine, le user agent du navigateur et le cookie de préférence contenant vos paramètres. L'opérateur contrôle également le code, donc tout correctif qu'il applique s'exécute sur chacune de vos recherches.

Un paramètre par défaut facilite accidentellement la journalisation. Searx envoyait les recherches via POST. SearXNG est livré avec method: "GET", accompagné d'un commentaire indiquant que POST évite d'inscrire les requêtes de recherche dans l'historique du navigateur, mais pose des problèmes d'ergonomie. Avec GET, la requête figure dans la ligne de requête ; elle finit donc par défaut dans les journaux d'accès du reverse proxy, ainsi que dans l'historique du navigateur. C'est un comportement standard de serveur web. Il est utile de le savoir avant de choisir sur quel serveur cela se produit.

Héberger votre propre instance déplace la confiance plutôt qu'elle ne la supprime. Vous contrôlez le code et les journaux. Si vous préférez ne pas publier de nom d'hôte ni de certificat TLS pour une machine mono-utilisateur, y accéder via un service onion v3 permet de garder l'instance hors du DNS public tout en restant accessible depuis n'importe où. En contrepartie, les moteurs de recherche en amont voient une seule adresse pour toutes vos recherches, et sur une instance mono-utilisateur, chaque requête est liée à vous au lieu de se fondre dans la masse. Une instance publique très utilisée vous apporte cette masse d'utilisateurs, mais l'opérateur prend le contrôle des journaux à votre place. Choisissez la propriété qui vous importe le plus. Si vous souhaitez consulter la liste complète des risques, la sécurité de SearXNG détaille le sujet. L'historique de localisation mérite la même réflexion avec des enjeux plus élevés, car un téléphone signalant sa position toute la journée révèle davantage qu'un journal de recherche. Comparer les outils de suivi de localisation auto-hébergés est le point de départ si vous souhaitez conserver ces données sur une machine que vous contrôlez.

Une remarque pratique pour un VPS : les plages d'adresses des centres de données sont signalées plus rapidement que les connexions résidentielles. Une nouvelle instance rencontre donc des CAPTCHA sur certains moteurs dès les premières recherches. Il s'agit du comportement de suspension décrit plus haut qui fait son travail, et non d'une mauvaise configuration. Si les mêmes moteurs restent bloqués après l'expiration de leur suspension, lire l'erreur réelle avant de modifier quoi que ce soit vous évitera de tenter des correctifs au hasard.

Si vous utilisez déjà une instance Searx

Rien ne casse le jour où vous lisez ceci. Le serveur continue de fonctionner jusqu’à ce qu’une modification upstream casse un autre moteur, après quoi l’instance reste en panne. Planifiez la migration et ne reprenez pas le fichier de configuration. Partez du modèle SearXNG, puis rajoutez uniquement ce que vous avez volontairement modifié : le nom de l’instance, safe_search, les moteurs activés ou désactivés en les indiquant par leur nom, ainsi que les paramètres par défaut de l’interface. Les noms et les options des moteurs ont changé dans le fork. Vérifiez donc chacun d’eux dans la documentation actuelle au lieu de supposer que la clé existe toujours. Les règles Filtron et une URL morty n’ont pas d’équivalent, car ces fonctions ont été intégrées à l’application.

Lancez la nouvelle instance sur un autre port tant que l’ancienne fonctionne encore. Elle fonctionne lorsque la page d’accueil renvoie 200, qu’une recherche renvoie des résultats provenant de plusieurs moteurs et que /stats/errors est vide ou ne liste que des échecs que vous comprenez. Basculez ensuite le reverse proxy vers la nouvelle instance et arrêtez l’ancien service.

FAQ

Searx est-il mort en 2026 ?

Le dépôt n’est pas archivé. Rien ne vous empêche donc de le cloner, mais le projet n’est plus maintenu. Le dernier commit de code date d’avril 2023 et le README contient la phrase « Searx is no longer maintained. ». Vérifiez-le vous-même avec curl -s https://api.github.com/repos/searx/searx | jq -r '.pushed_at', puis consultez les messages des commits récents, car une date de push peut simplement correspondre à une modification de la documentation. Pour un moteur de métarecherche, l’absence de maintenance signifie que les résultats se dégradent spontanément, puisque chaque module de moteur dépend d’un site upstream qui continue de changer.

Puis-je encore installer Searx avec apt ou pip ?

Pas sur les systèmes actuels, et pas de manière utile là où c’est encore possible. Ubuntu a intégré searx pour la dernière fois dans 23.10, en version 1.1.0. La dernière version LTS qui l’inclut est 22.04, en version 1.0.0. Le paquet a été supprimé de 24.04 avant la publication. Par conséquent, sudo apt install searx sur 24.04 renvoie E: Unable to locate package searx. Debian a fourni la version 1.1.0 dans Debian 12, puis l’a supprimée de testing en octobre 2023. Debian 13 ne contient donc aucun paquet. PyPI fournit encore toutes les versions de searx. La plus récente est la version 0.17.0, publiée en juillet 2020, donc antérieure au fork lui-même. Installez plutôt SearXNG.

Mes anciens paramètres searx dans settings.yml fonctionneront-ils avec SearXNG ?

Non. Copiez les valeurs, pas le fichier. SearXNG lit /etc/searxng/settings.yml et attend use_default_settings: true au début du fichier. Votre fichier est donc interprété comme une surcharge des valeurs par défaut fournies. Un ancien fichier searx constitue une configuration complète avec des noms de clés différents. Il ne contient ni limiter, ni bloc valkey, ni liste formats. Partez du modèle situé à utils/templates/etc/searxng/settings.yml et réintégrez vos modifications une par une.

Pourquoi ma propre instance SearXNG renvoie-t-elle moins de résultats qu’une instance publique ?

Certains moteurs sont suspendus. Lorsqu’un moteur répond avec un CAPTCHA ou une page de limitation de débit, SearXNG cesse de l’interroger pendant une durée fixe : 180 secondes pour un refus simple, jusqu’à 1,296,000 secondes pour un CAPTCHA Cloudflare. La page de résultats signale ce problème sous « Messages from the search engines » et /stats/errors répertorie les échecs avec leurs raisons. Les adresses de datacenters sont signalées plus tôt que les connexions domestiques. Une nouvelle instance VPS le constate donc rapidement.

Dois-je utiliser une instance SearXNG publique ou gérer la mienne ?

Gérez votre propre instance si vous voulez contrôler le code et les journaux, et si vous acceptez que les moteurs upstream voient alors une seule adresse pour toutes vos recherches. Utilisez une instance publique si le fait de mélanger vos requêtes à celles d’autres personnes compte davantage pour vous que de savoir ce qui est journalisé. Sur une instance publique, l’opérateur peut voir le texte de la requête, l’heure, votre adresse IP et votre user agent, et modifier le code quand il le souhaite. Une politique de journalisation déclarée ne peut pas être vérifiée depuis l’extérieur.