Det här är berättelsen om hur jag gick från en ganska kaotisk och spretig bare‑metal‑installation av SearXNG, full av uWSGI‑konfigurationer, pyenv‑miljöer, npm‑rester och systemd‑tjänster som inte riktigt ville samarbeta, till en modern, ren och stabil Docker‑baserad installation som bara fungerar. Det är en resa som började med frustration, fortsatte med felsökning och slutade med en lösning som är både enklare, snabbare och mer framtidssäker än allt jag hade innan.

Jag vill beskriva vad som gick fel, vad som gick rätt, och framför allt varför Docker‑lösningen blev den naturliga slutpunkten. Jag skriver det här både för mig själv och för andra som kanske sitter fast i samma typ av installation och undrar om det finns ett bättre sätt. Det gör det.

Början: en installation som växte okontrollerat.

När jag först installerade SearXNG gjorde jag det på det sätt som kändes mest naturligt: direkt på systemet. Jag följde guider, dokumentation, blogginlägg och forumtrådar. Jag installerade Python, uWSGI, NGINX, npm, node‑modules, virtualenv, pyenv, systemd‑tjänster och allt annat som behövdes. Det var inte fel — det var bara väldigt mycket.

Det började som en ren installation, men med tiden blev det mer och mer fragmenterat. Jag hade:

• en pyenv‑miljö i /usr/local/searxng/venv
• en uWSGI‑socket i /usr/local/searxng/run/socket
• en systemd‑tjänst som försökte starta uWSGI
• en annan systemd‑tjänst som försökte starta SearXNG
• en NGINX‑konfiguration som pekade på en socket som ibland fanns och ibland inte
• npm‑rester från frontend‑kompilering
• loggar på flera olika platser
• en blandning av Debian‑paket och manuella installationer

Det var inte en katastrof, men det var inte heller stabilt. Varje gång jag gjorde en uppdatering behövde jag tänka efter: vilken del av installationen påverkas nu? Vilken tjänst startar vad? Vilken socket används? Vilken version av Python körs? Varför startar inte uWSGI? Varför ligger det två olika installationer av SearXNG på systemet?

Det var som att ha en verkstad där alla verktyg låg utspridda på golvet. Allt fanns där, men inget var organiserat.

Problemen började märkas.

Till slut började problemen bli mer än bara små irritationsmoment. Det var saker som:

• uWSGI startade inte automatiskt
• systemd‑tjänsten hittade inte rätt socket
• NGINX klagade på att backend inte svarade
• loggar saknades eller låg på fel plats
• uppdateringar av SearXNG bröt installationen
• pyenv‑miljön behövde uppdateras manuellt
• npm‑beroenden behövde byggas om
• vissa filer låg kvar från gamla installationer och orsakade konflikter

Det värsta var att jag ibland inte ens visste vilken del som var ansvarig för ett visst fel. Var det uWSGI? Var det Python‑miljön? Var det systemd? Var det NGINX? Var det en gammal fil som låg kvar? Var det en ny version av SearXNG som ändrat något?

Det var som att felsöka ett hus där någon byggt om rummen flera gånger utan att riva de gamla väggarna.

Insikten: det här är inte hållbart.

Efter ett tag insåg jag att jag inte längre hade en installation — jag hade ett lapptäcke. Varje gång jag ville göra en ändring behövde jag tänka på fem olika komponenter. Varje gång jag ville uppdatera behövde jag läsa changelogs och hoppas att inget bröt sig. Varje gång jag ville felsöka behövde jag leta i flera olika loggar.

Det var då tanken slog mig: varför gör jag det här på bare metal över huvud taget?

SearXNG är ett perfekt exempel på en applikation som borde köras i Docker:

• den har flera komponenter (core, valkey, caddy)
• den uppdateras ofta
• den har tydliga beroenden
• den har en officiell Docker‑image
• den är byggd för att vara containeriserad

Det var egentligen självklart. Jag hade bara inte tagit steget tidigare.

Beslutet: nu går jag över till Docker.

När jag väl bestämde mig gick det snabbt. Jag ville ha en installation som:

• är ren
• är reproducerbar
• är lätt att uppdatera
• inte blandar systemfiler och applikationsfiler
• inte kräver pyenv, npm eller uWSGI
• inte kräver systemd‑tjänster
• inte kräver manuell felsökning av sockets
• inte lämnar kvar gamla filer som stör

Docker löste allt detta.

Jag bestämde mig för att bygga en stack med tre containrar:

• searxng-core

Själva applikationen.

• searxng-valkey

Redis‑ersättaren som SearXNG använder.

• searxng-caddy

Frontend‑proxy med HTTPS, HTTP/3 och allt annat.

Det var en ren, modern och framtidssäker arkitektur.

Första steget: rensa bort allt gammalt.

Innan jag kunde gå vidare behövde jag städa.

Jag tog bort:

• gamla systemd‑tjänster
• gamla sockets
• gamla loggar
• gamla pyenv‑miljöer
• gamla npm‑mappar
• gamla konfigurationsfiler
• gamla installationer i /usr/local/searxng/
• gamla uWSGI‑filer

Det var som att rensa ut ett förråd som man inte vågat öppna på länge. Ju mer jag tog bort, desto lättare kändes det.

När jag var klar hade jag ett rent system. Inga rester. Inga konflikter. Inga gamla tjänster som försökte starta något som inte längre fanns.

Andra steget: skapa en ren Docker‑miljö.

Nu började det roliga. Jag skapade en enkel docker-compose.yml med tre tjänster:

• core
• valkey
• caddy

Jag definierade volymer för:

• settings.yml
• templates
• valkey‑data
• caddy‑config

Jag såg till att allt låg i en tydlig struktur:

searxng/
  docker-compose.yml
  core-config/
    settings.yml
  caddy/
    Caddyfile
  valkey/
    data/

searxng/
  docker-compose.yml
  core-config/
    settings.yml
  caddy/
    Caddyfile
  valkey/
    data/

Det var ordning och reda. Inget låg utspritt. Allt var samlat.

Tredje steget: konfigurera settings.yml.

Det fina med Docker‑versionen av SearXNG är att den använder en enda konfigurationsfil: settings.yml.

Jag mappade den direkt in i containern:

./core-config/settings.yml:/etc/searxng/settings.yml

./core-config/settings.yml:/etc/searxng/settings.yml

Det gjorde att jag kunde ändra konfigurationen utan att behöva bygga om containern. Jag kunde bara:

docker compose restart searxng-core

docker compose restart searxng-core

Och allt uppdaterades.

Fjärde steget: starta stacken.

När allt var klart körde jag:

docker compose up -d

docker compose up -d

Och plötsligt hade jag:

• en fungerande core
• en fungerande valkey
• en fungerande caddy‑proxy
• automatiska loggar
• inga sockets att felsöka
• inga systemd‑tjänster att starta
• inga pyenv‑miljöer att uppdatera
• inga npm‑beroenden att kompilera

Det bara fungerade.

Skillnaden: det här är en helt annan värld.

När jag jämförde min gamla installation med den nya var skillnaden enorm.

Gamla installationen:

• många rörliga delar
• svårt att uppdatera
• svårt att felsöka
• svårt att reproducera
• risk för konflikter
• beroende av systemets Python
• beroende av uWSGI
• beroende av NGINX
• beroende av npm

Nya installationen:

• tre containrar
• inga konflikter
• inga systemberoenden
• inga manuella tjänster
• inga sockets
• inga pyenv‑miljöer
• inga npm‑rester
• inga loggar utspridda
• enkel uppdatering
• enkel backup
• enkel felsökning

Det var som att gå från en gammal bil som man måste meka med varje vecka till en ny bil som bara startar och kör.

Uppdateringar blev plötsligt enkla.

Tidigare behövde jag:

• uppdatera Python‑miljön
• uppdatera uWSGI
• uppdatera SearXNG‑koden
• uppdatera npm‑beroenden
• uppdatera systemd‑tjänster
• uppdatera NGINX‑konfigurationen

Nu behövde jag bara:

docker compose pull
docker compose up -d

docker compose pull
docker compose up -d

Det var allt.

Stabilitet: inga fler mysterier.

Det som tidigare kunde ta timmar att felsöka tog nu minuter. Om något gick fel kunde jag:

• läsa loggar direkt i containern
• starta om en enskild tjänst
• rulla tillbaka till en tidigare version
• testa ändringar utan att påverka systemet

Det var en helt annan nivå av kontroll.

Framtiden: nu är installationen hållbar.

Det bästa med Docker‑lösningen är att den är framtidssäker. Oavsett vad som händer med:

• Python‑versioner
• uWSGI‑stöd
• systemd‑ändringar
• Debian‑paket
• npm‑beroenden

… så påverkar det inte min installation.

Containrarna är isolerade. De är självförsörjande. De är lätta att byta ut.

Slutsats: det här var rätt val.

När jag ser tillbaka på allt känns det självklart. Min gamla installation var ett lapptäcke. Min nya installation är en ren, modern och stabil lösning som jag kan lita på.

Jag har gått från:

• frustration till kontroll
• kaos till ordning
• manuellt arbete till automatisering
• osäkerhet till stabilitet

Docker‑versionen av SearXNG är inte bara bättre — den är överlägsen.

Ha det bra där ute … 😉
//Anders