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 ? Vérifiez-le vous-même

« Mort » n’est pas un état que GitHub signale. Consultez donc les deux indicateurs disponibles et tirez votre propre conclusion. Le premier consiste à vérifier si le dépôt est archivé et à déterminer à 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 22 août 2026, la première commande affiche false et 2026-05-14T10:02:22Z. La seconde affiche false et un horodatage correspondant au jour où vous l’exécutez. 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 la question revient régulièrement.

pushed_at est un indicateur faible à 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])'

En août 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  Bump selenium from 4.7.2 to 4.8.3 (#3490)

Lisez la liste de bas en haut. Le développement 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 original est passé à Hister, un outil de recherche qui indexe les pages et les fichiers de votre choix au lieu d’interroger d’autres moteurs. Il s’agit d’une approche différente, utile si vous cherchez réellement un moteur de recherche personnel pour votre propre contenu.

Le deuxième indicateur concerne le packaging, dont dépendent discrètement la plupart des anciens tutoriels.

• PyPI contient une seule release searx, la version 0.17.0, publiée en juillet 2020. pip install searx réussit et vous fournit du code datant de neuf mois avant la création du fork.
• Debian a fourni searx 1.1.0 dans Debian 12 (bookworm) et le conserve toujours 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 22.04, en version 1.0.0. Sur Ubuntu 24.04, sudo apt install searx se termine par E: Unable to locate package searx.
• searx.space, l’annuaire des instances publiques vers lequel le projet a toujours orienté les utilisateurs, répertorie désormais des instances SearXNG.

Voici donc l’état réel du projet. Le code est public, il fonctionne toujours, 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 fournisseurs. Une instance non maintenue renvoie moins de résultats chaque mois, sans qu’il soit nécessaire de modifier le serveur.

Ce que le fork a changé pour une nouvelle instance

Le fichier de configuration a changé d’emplacement et sert désormais 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 via 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 option, votre fichier ne contient que les surcharges, et chaque clé que vous omettez reprend la valeur par défaut fournie dans le paquet. Sans cette option, votre fichier doit décrire toute la configuration, moteur par moteur. C’est ainsi qu’une instance peut démarrer correctement tout en ne trouvant aucun moteur. Un ancien fichier de configuration Searx copié à cet emplacement constitue une configuration complète avec des noms de clés différents. Il emprunte donc la seconde méthode, mais de manière incorrecte.

La clé secrète arrête le processus

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’oubliez, SearXNG écrit une ligne dans les journaux puis quitte avec le statut 1, car webapp.py compare la clé à la valeur du modèle avant de commencer à traiter les requêtes :

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

Le contrôle est ignoré lorsque general.debug vaut true. Une instance peut donc fonctionner dans une session de débogage, puis refuser de démarrer sous systemd ou dans un conteneur. Si un conteneur redémarre en boucle avec cette ligne dans docker compose logs, c’est ce contrôle qui échoue, et non l’image qui est endommagée.

Le limiteur est nouveau et nécessite Valkey

Searx n’intégrait aucune limitation de débit dans l’application. Les instances Searx publiques plaçaient des services distincts devant l’application : filtron pour filtrer les requêtes et morty pour faire transiter le contenu des résultats par un proxy. Ces deux dépôts n’ont reçu aucun commit depuis 2023.

SearXNG gère lui-même ces fonctions. La limitation de débit et la détection des bots sont assurées par le limiteur, activé avec server.limiter. Cette option vaut false dans les valeurs par défaut fournies et true dans le modèle de l’installateur. Le limiteur a besoin d’une base de données Valkey pour stocker ses compteurs. Valkey est un fork de Redis, et Ubuntu 24.04 fournit un 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 plutôt un bloc redis:. Reprenez donc le nom de clé de la documentation actuelle du limiteur. 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 du jeton de lien. Concrètement, certaines requêtes reçoivent une réponse HTTP 429 au lieu de résultats, y compris vos propres requêtes si vous utilisez un script avec l’instance. Ce comportement 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 amont répond avec un CAPTCHA ou une page indiquant une limitation de débit, SearXNG lève une exception typée et cesse d’interroger ce moteur pendant un délai défini, au lieu de continuer les tentatives 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 août 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 d’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 valeurs élevées sont intentionnelles : réinterroger un service qui a déjà signalé l’adresse est le moyen de faire bloquer définitivement 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 », tandis que /stats/errors répertorie les échecs. 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 tous les 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 contenait aucune clé formats. Sa sortie JSON était donc simplement disponible sur demande. Tous les scripts et extraits de code de cette époque partent du même principe, et l’échec se manifeste par une réponse 403 vide, sans explication. Si vous connectez une instance à des 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, mais chacune échoue ou induit en erreur sur une installation actuelle.

• sudo apt install searx sur Ubuntu 24.04 s’arrête à E: Unable to locate package searx, car le paquet a été publié pour la dernière fois dans 22.04.
• pip install searx réussit et installe la version 0.17.0 de juillet 2020. Rien ne vous indique 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 et vous fournit l’arborescence d’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 reconstruisent des composants déjà intégrés à SearXNG.
• Une URL redis: pour le limiter correspond à un renommage de retard 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 distinct. Ce dépôt a été archivé en mars 2026 et ses fichiers ont été déplacés dans container/ du dépôt principal. Le démarrage rapide actuel avec un conteneur, fourni par la documentation, est le suivant :

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 scriptée sur l’hôte suit un autre chemin, mais 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 constitue la configuration de référence dans la documentation SearXNG. La procédure détaillée correspondante est disponible ici : installer SearXNG sur votre propre VPS.

Instance publique ou instance personnelle

Une instance publique est un serveur administré par un tiers qui termine votre connexion TLS (transport layer security). Le logiciel qui y est exécuté lit donc votre requête en clair. La documentation de SearXNG formule 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 des informations visibles est courte et exhaustive. La stack de l’opérateur peut voir le texte de la requête, l’heure, l’adresse IP d’origine de la requête, le user agent du navigateur et le cookie de préférences contenant vos paramètres. L’opérateur contrôle également le code : tout patch qu’il applique s’exécute donc lors de chacune de vos recherches sur cette instance.

Un réglage par défaut facilite cette journalisation involontaire. Searx envoyait les recherches avec POST. SearXNG est livré avec method: "GET", en précisant que POST évite d’enregistrer les requêtes 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 se retrouve donc par défaut dans le access log du reverse proxy et dans l’historique du navigateur. C’est le comportement normal d’un serveur web. Il est utile de le savoir avant de choisir le serveur qui traitera vos recherches.

Héberger votre propre instance déplace la relation de confiance, mais ne la supprime pas. Vous contrôlez le code et les journaux. Si vous préférez ne pas publier de hostname ni de certificat TLS pour une simple machine personnelle, y accéder via un service onion v3 permet de garder l’instance hors du DNS public tout en y accédant depuis n’importe où. En contrepartie, les moteurs en amont voient une seule adresse pour toutes vos recherches. Sur une instance personnelle, chaque requête peut être reliée à vous, au lieu d’être mélangée à celles d’un grand nombre d’utilisateurs. Une instance publique active vous apporte cet anonymat collectif et vous retire la gestion des journaux. Choisissez la propriété qui compte pour vous. Si vous voulez d’abord consulter la liste complète des risques, SearXNG peut-il être utilisé en toute sécurité ? les présente.

Une remarque pratique concernant un VPS. Les plages d’adresses des datacenters sont signalées plus rapidement que les connexions résidentielles. Une nouvelle instance rencontre donc des CAPTCHA sur certains moteurs après seulement quelques recherches. Il s’agit du comportement de suspension décrit plus haut, et non d’une mauvaise configuration.

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. Une date de push peut correspondre uniquement à une modification de la documentation. Pour un moteur de métarecherche, l’absence de maintenance signifie que les résultats se dégradent progressivement, car chaque module dépend d’un site tiers qui continue d’évoluer.

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 fourni searx pour la dernière fois dans 22.04, en version 1.0.0. Ainsi, 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 retirée de testing en octobre 2023. Debian 13 ne contient donc aucun paquet. PyPI fournit encore la version 0.17.0 de juillet 2020, qui est antérieure au fork lui-même. Installez plutôt SearXNG.

Mon ancien fichier settings.yml de searx fonctionnera-t-il 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 sert donc de 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éintroduisez vos modifications une par une.

Pourquoi mon 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 indiquant une limite de débit, SearXNG cesse de l’interroger pendant une durée fixe : de 180 secondes pour un refus simple à 1,296,000 secondes pour un CAPTCHA Cloudflare. La page de résultats l’indique sous « Messages from the search engines », et /stats/errors répertorie les échecs avec leur motif. Les adresses des centres de données sont signalées plus rapidement que les connexions domestiques. Une nouvelle instance sur un VPS le constate donc rapidement.

Dois-je utiliser une instance publique de SearXNG 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 en amont voient alors une seule adresse pour toutes vos recherches. Utilisez une instance publique si le fait de mélanger vos requêtes avec celles d’autres utilisateurs 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. Il peut aussi modifier le code à tout moment. Une politique de journalisation déclarée ne peut pas être vérifiée depuis l’extérieur.