Moli selbst hosten: Headless-Browser für KI-Agenten

Ein Headless-Browser, der auf einen kleinen VPS passt

Moli ist ein Headless-Browser für KI-Agenten. Er ist klein genug, um auf einem VPS selbst gehostet zu werden, auf dem Headless Chrome nicht ausreichend Platz findet. Es handelt sich um eine in Rust geschriebene Browser-Engine, nicht um einen Wrapper um Chromium. Sie unterstützt das Chrome DevTools Protocol (CDP), das Protokoll, mit dem Ihre Automatisierungsbibliothek bereits arbeitet. Sie installieren eine Binärdatei, führen moli serve aus und richten anschließend Playwright oder Ihren eigenen Agent-Code auf http://127.0.0.1:9222.

Lesen Sie die Einschränkungen, bevor Sie etwas installieren. Das Projekt beschreibt seinen Umfang eindeutig: kein GUI-Browser, kein GPU-Compositor, keine pixelgenaue Übereinstimmung mit Chrome und keine hohe Wiedergabetreue bei Canvas oder Medienwiedergabe. Seiten, die diese Funktionen benötigen, schlagen fehl. Echtes Chrome unter Playwright bleibt die Ausweichlösung. Im letzten Abschnitt erfahren Sie, wie Sie entscheiden, welche Seiten es benötigen.

Jeder folgende Befehl stammt aus der README des Projekts und seinen veröffentlichten Skill-Dateien, die im August 2026 geprüft wurden. Jede Zahl in den Diagrammen ist ein Wert, den das Projekt zu seiner eigenen Engine veröffentlicht hat, und keine Messung dieser Website. Die Bildunterschrift jedes Diagramms weist darauf hin. Wenn Sie noch eine Engine auswählen, behandelt die umfassendere Übersicht zu Headless-Browsern für Agenten auf einem VPS die Alternativen.

Warum benötigt headless Chrome so viel Speicher?

Chrome ist ein Browser mit mehreren Prozessen. Jeder Tab und jedes siteübergreifende iframe erhält einen eigenen Renderer-Prozess. Jeder Renderer verfügt über einen eigenen V8-Heap und eigene Grafikpuffer. Dieses Design ist für einen Desktop sinnvoll, weil ein abgestürzter Tab nicht das gesamte Fenster mitreißt. Auf einem VPS mit 2 GB bedeutet das, dass ein einzelner Browsing-Schritt mehr Speicher benötigen kann als die eigentliche Anwendung.

Das Projekt hat 192 gemischte öffentliche URLs mit vier Engines gecrawlt und das Ergebnis veröffentlicht.

[
  {
    "engine": "Moli",
    "useful_pages": 103,
    "median_rss_mib": 73
  },
  {
    "engine": "Chrome Headless",
    "useful_pages": 101,
    "median_rss_mib": 773
  },
  {
    "engine": "Lightpanda",
    "useful_pages": 85,
    "median_rss_mib": 40
  },
  {
    "engine": "Obscura",
    "useful_pages": 57,
    "median_rss_mib": 39
  }
]

Chrome Headless gab 101 nützliche Seiten zurück, Moli dagegen 103. In dieser Stichprobe haben die beiden Engines also ungefähr denselben Anteil des Webs gelesen. Beim Speicherverbrauch gibt es jedoch einen deutlichen Unterschied: Der mediane RSS (Resident Set Size, also der Speicher, den ein Prozess tatsächlich im RAM belegt) lag bei Chrome bei 773 MiB und bei Moli bei 73 MiB. Diese Richtung ist plausibel, weil sie sich aus der Prozessarchitektur ergibt. Das genaue Verhältnis auf Ihren Seiten sollten Sie jedoch nicht voraussetzen.

Der Median ist nicht der Wert, der Probleme verursacht. Entscheidend ist der Spitzenwert. Wenn einem Rechner mit 2 GB der Speicher ausgeht, wählt der Kernel einen Prozess aus und beendet ihn. Der Eintrag erscheint dann in dmesg -T oder journalctl -k:

Out of memory: Killed process 4211 (chrome) total-vm:2318936kB, anon-rss:1418324kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:3540kB oom_score_adj:0

Ihr Agent sieht diese Zeile nicht. Er sieht einen Browser, der nicht mehr antwortet, meist als Playwright-Fehler wie page.goto: Page crashed oder als geschlossenes Target. Keine dieser Fehlermeldungen erwähnt den Speicher. Deshalb sollte der OOM-Killer (Out-of-Memory-Killer) die erste Prüfstation sein, wenn ein Agent auf einem kleinen Rechner zufällig ausfällt. Die Dimensionierung für den Spitzenwert entspricht der Auswahl von RAM und CPU für einen Agent-VPS.

Moli-Binary installieren und auf eine Version festlegen

Das Projekt veröffentlicht ein Shell-Installationsprogramm und vorkompilierte Tarballs in den GitHub-Releases. Im August 2026 ist die aktuelle Version 1.0.1, veröffentlicht am 18. August 2026. Die in diesem Leitfaden genannten Benchmarkwerte wurden vom Projekt mit 0.1.1 gemessen. Betrachten Sie sie daher als grobe Einschätzung der Engine und nicht als Zusage für den von Ihnen installierten Build.

Legen Sie die Version fest. Ein Installationsprogramm, das immer latest auflöst, verwendet beim nächsten Rebuild eine andere Browser-Engine. Eine Änderung des Browserverhaltens sollten Sie planen und nicht erst beim Auftreten feststellen.

Das Shell-Installationsprogramm ist der schnellste Einstieg. Lesen Sie es trotzdem, bevor Sie es ausführen.

curl --proto '=https' --tlsv1.2 -fsSL \
  -o /tmp/moli-installer.sh \
  https://github.com/lexmount/moli/releases/download/v1.0.1/moli-installer.sh
less /tmp/moli-installer.sh
sh /tmp/moli-installer.sh

Lesen Sie das Skript, bevor Sie es ausführen. Es ist kurz. Es wählt ein Archiv aus uname -m und entpackt anschließend ein einzelnes Binary nach ~/.local/bin. Unter x86_64 verwendet es moli-x86_64-unknown-linux-gnu.tar.gz. Auf einem Arm-Server verwendet es das Archiv aarch64. Damit werden VPS-Tarife für Arm und x86 abgedeckt. Setzen Sie MOLI_INSTALL_DIR, um einen anderen Installationsort zu verwenden. Achten Sie darauf, wie das Skript die Version auflöst: Es verwendet das neueste Release und nicht den Tag, von dem Sie das Skript abgerufen haben. Für einen ersten Test ist das in Ordnung. Für einen reproduzierbaren Rebuild ist es ungeeignet.

Für eine dauerhafte Installation führen Sie daher manuell dieselben Schritte wie das Installationsprogramm aus und geben das genaue Archiv selbst an. So legen Sie das Binary außerdem an einem Ort ab, den ein Systemdienst erreichen kann. Zudem müssen Sie kein heruntergeladenes Skript an eine Shell weiterleiten.

cd /tmp
curl --proto '=https' --tlsv1.2 -fsSLO \
  https://github.com/lexmount/moli/releases/download/v1.0.1/moli-x86_64-unknown-linux-gnu.tar.gz
mkdir -p moli-pkg
tar -xzf moli-x86_64-unknown-linux-gnu.tar.gz -C moli-pkg --strip-components=1
sudo install -m 0755 moli-pkg/moli /usr/local/bin/moli
moli --version

moli --version, das Ausgeben der festgelegten Version, ist die vollständige Prüfung. moli: command not found direkt nach dem Installationsprogramm bedeutet, dass das Installationsverzeichnis nicht in Ihrem PATH enthalten ist. Das Installationsprogramm gibt eine Zeile aus, die das hinzuzufügende Verzeichnis nennt.

Einmalige Extraktion mit moli fetch

Viele Aufgaben, die ein Agent an einen Browser übergibt, lauten sinngemäß: „Lade diese URL und sage mir, was dort steht.“ Dafür ist kein Server erforderlich. moli fetch startet die Engine, lädt eine Seite, schreibt ein Artefakt nach stdout und beendet sich anschließend. Zwischen den Aufrufen bleibt daher kein Speicher belegt.

moli fetch --dump markdown --wait-until networkidle https://example.com
moli fetch --dump semantic_tree_text --wait-selector "main" https://example.com
moli fetch --dump json --wait-until networkidle https://example.com > page.json

Der erste Befehl gibt die Seite als Markdown aus, beginnend mit # Example Domain. Markdown lässt sich besonders effizient an ein Modell übergeben, weil es das Markup entfernt und den Text beibehält. semantic_tree_text erhält Rollen und Struktur. Das ist auf Seiten mit umfangreicher Navigation sinnvoll, auf denen die Links genauso wichtig sind wie der Fließtext. --dump json enthält den HTTP-Status und den Request-Trace. Verwenden Sie diese Option, wenn ein Abruf leer zurückkommt und Sie die Ursache ermitteln müssen.

Die Warte-Strategie entscheidet, ob Sie Inhalte oder eine leere Hülle erhalten. --wait-until networkidle gibt die Ausgabe zurück, sobald der Netzwerkverkehr zum Erliegen kommt. --wait-until domstable gibt sie zurück, sobald sich das DOM nicht mehr ändert. Das ist die bessere Wahl für eine Seite, die im Hintergrund regelmäßig Anfragen sendet und deshalb nie vollständig zur Ruhe kommt. --wait-selector wartet auf einen von Ihnen angegebenen Selektor. Nur diese Strategie berücksichtigt die abzurufende Seite selbst. Dadurch ist sie am zuverlässigsten, wenn Sie das Ziel kennen.

Screenshots und PDF-Dateien benötigen ein echtes Layout. Das Layout ist standardmäßig deaktiviert:

moli fetch --layout --dump screenshot https://example.com > page.png
moli fetch --layout --dump screenshot_full https://example.com > full-page.png
moli fetch --layout --dump pdf https://example.com > page.pdf

Die README bezeichnet die standardmäßige Layout-Richtlinie als LayoutPolicy::Mock: Die Geometrie wird simuliert und es wird nichts gerendert, weil Layout und Rendering den aufwendigeren Teil eines Browsers ausmachen. Deshalb sehen die oben genannten Speicherwerte so aus. Das bedeutet außerdem, dass ein leeres PNG in der Regel auf ein fehlendes --layout-Flag und nicht auf eine fehlerhafte Seite hindeutet.

Für URLs, die Ihr Agent gefunden hat, statt von Ihnen ausgewählte URLs, fügen Sie --block-private-networks hinzu. Ein Agent, der auf einer Seite gefundene Links verfolgt, könnte dazu gebracht werden, http://169.254.169.254/ für Zugangsdaten einer Cloud-Instanz oder einen Datenbank-Port auf localhost abzurufen, der nie aus dem Internet erreichbar sein sollte. Dieses Flag verhindert die Navigation in private Adressbereiche. --block-cidrs schränkt sie noch weiter ein. Wenn der Job nicht nur eine Seite liest, sondern ein Crawling durchführt, wird die Struktur dieser Pipeline in selbst gehosteten Firecrawl-Alternativen beschrieben. Der vorherige Schritt, also das Ermitteln von URLs, wird in einem von SearXNG unterstützten Search-Skill für Agents beschrieben.

Einen Agenten über CDP mit Moli verbinden

Wenn ein Agent viele Schritte lang navigiert und klickt, starten Sie stattdessen den Server.

moli serve --host 127.0.0.1 --port 9222

127.0.0.1 und Port 9222 sind die Standardwerte. Ein einfaches moli serve bindet daher bereits nur an Loopback. Schreiben Sie in dauerhaften Konfigurationen trotzdem beide Werte aus. Die nächste Person, die Ihre Service-Datei liest, sollte sich nicht an den Standardwert erinnern müssen.

Prüfen Sie den Server, bevor Sie einen Client damit verbinden:

curl -s http://127.0.0.1:9222/json/version

Ein funktionierender Server antwortet mit einem JSON-Objekt, das ein Feld webSocketDebuggerUrl enthält. An diese URL verbindet sich ein CDP-Client. curl: (7) Failed to connect to 127.0.0.1 port 9222: Connection refused bedeutet, dass kein Prozess lauscht. Lesen Sie dann das Terminal, in dem Sie den Server gestartet haben. Wenn der Server als Dienst läuft, verwenden Sie journalctl -u moli -n 50. /json/list listet die offenen Ziele auf. /json/protocol listet die Domänen auf, die dieser Build implementiert. So prüfen Sie, ob eine benötigte CDP-Methode hier vorhanden ist.

Playwright verbindet sich mit diesem Endpunkt, statt einen eigenen Browser zu starten:

import { chromium } from "playwright";

const browser = await chromium.connectOverCDP("http://127.0.0.1:9222");
const context = browser.contexts()[0];
const page = context.pages()[0] ?? await context.newPage();

await page.goto("https://example.com");
console.log(await page.locator("body").innerText());

await browser.close();

Entscheidend ist die Zeile connectOverCDP, nicht chromium.launch(). Hier läuft kein untergeordneter Chromium-Prozess. Daher haben executablePath und die üblichen Container-Flags wie --no-sandbox keine Wirkung. Proxy-, Cookie- und User-Agent-Einstellungen übergeben Sie aus demselben Grund als eigene Flags an den Moli-Server. Rechnen Sie mit einer ausgewählten CDP-Abdeckung und nicht mit dem vollständigen Chrome-Protokoll. Ein ausdrücklicher Fehler wegen einer nicht unterstützten Methode kennzeichnet die Grenze der Engine und ist kein Fehler in Ihrem Code.

Zwei Server-Flags legen fest, was der Agent tun kann. --layout aktiviert die tatsächliche Geometrie. Diese wird für Klicks anhand von Koordinaten und für Screenshots benötigt. --resource lädt die optionalen Bilder, Schriftarten und Medien. Das kostet bei jedem Seitenaufruf Bandbreite und Arbeitsspeicher. Lassen Sie das Flag deaktiviert, bis eine Seite diese Ressourcen nachweislich benötigt. --profile-dir speichert Cookies und den Storage zwischen den Durchläufen. Ohne dieses Flag ist jeder Durchlauf nicht persistent.

[
  {
    "engine": "Moli",
    "cdp_ready_ms": 34.85,
    "peak_pss_mib": 102.46,
    "processes": 1
  },
  {
    "engine": "Chromium",
    "cdp_ready_ms": 169.37,
    "peak_pss_mib": 348.82,
    "processes": 11
  }
]

Beim Beispiel-Workload des Projekts akzeptierte Moli eine CDP-Verbindung nach 34.85 ms gegenüber 169.37 ms für Chromium. Der Spitzenwert des PSS (proportional set size, wobei der Arbeitsspeicher gemeinsam genutzter Seiten auf die Prozesse aufgeteilt wird, die sie gemeinsam nutzen) lag bei 102.46 MiB gegenüber 348.82 MiB. Der strukturelle Unterschied zeigt sich in der letzten Spalte: 1 Prozess gegenüber 11. Ein Prozess ist für systemd eine einzelne zu überwachende Einheit und für die Begrenzung durch ein einzelnes cgroup zuständig. Dadurch bleibt der nächste Abschnitt kurz.

moli serve als systemd-Dienst auf Loopback ausführen

Führen Sie den Server als Dienst aus, wenn ein Agent einen darauf wartenden Browser benötigt. Verwenden Sie weiterhin moli fetch pro URL, wenn dies nicht erforderlich ist, weil ein ungenutzter Server weiterhin Speicher belegt.

Binden Sie Port 9222 nicht an eine öffentliche Schnittstelle. CDP verfügt über keinerlei Authentifizierung. Jeder, der diesen Port erreichen kann, kann den Browser steuern und alles lesen, worauf der Browser zugreifen kann, einschließlich aller Cookies in Ihrem Profilverzeichnis. Lassen Sie den Dienst auf 127.0.0.1 lauschen. Greifen Sie von einem anderen Rechner über einen SSH-Tunnel (ssh -L 9222:127.0.0.1:9222 user@your-vps) oder über eine private VPN-Schnittstelle darauf zu, und lassen Sie den Agenten auf seiner Seite des Tunnels eine Verbindung zu http://127.0.0.1:9222 herstellen.

Erstellen Sie einen Dienstbenutzer und anschließend die Unit-Datei:

sudo useradd --system --home-dir /var/lib/moli --shell /usr/sbin/nologin moli

Schreiben Sie /etc/systemd/system/moli.service:

[Unit]
Description=Moli headless browser CDP server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=moli
Group=moli
ExecStart=/usr/local/bin/moli serve --host 127.0.0.1 --port 9222 --profile-dir /var/lib/moli/profile --block-private-networks
Restart=on-failure
RestartSec=2
StateDirectory=moli
MemoryAccounting=yes
MemoryMax=768M
NoNewPrivileges=yes
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=strict

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now moli.service
systemctl status moli.service
curl -s http://127.0.0.1:9222/json/version

systemctl status sollte active (running) anzeigen, und curl sollte das Discovery-JSON zurückgeben. ProtectSystem=strict bindet das gesamte Dateisystem für diese Unit schreibgeschützt ein. Deshalb ist StateDirectory=moli hier nicht optional: Der Befehl erstellt /var/lib/moli, setzt den Dienstbenutzer als Eigentümer und macht diesen einen Pfad beschreibbar. Wenn eine Unit startet und anschließend mit einem Berechtigungsfehler in journalctl -u moli beendet wird, versucht sie fast immer, in einen Pfad zu schreiben, den ProtectSystem gerade schreibgeschützt gemacht hat. Verschieben Sie diesen Pfad daher unter das Statusverzeichnis.

MemoryMax=768M sorgt dafür, dass der Dienst sicher neben Ihrer Anwendung ausgeführt werden kann. Die Unit erhält eine eigene cgroup. Wenn diese cgroup ihr Limit überschreitet, beendet der Kernel einen Prozess innerhalb dieser cgroup und lässt den restlichen Rechner unverändert. Das Journal protokolliert den Vorgang:

moli.service: A process of this unit has been killed by the OOM killer.

Werten Sie diese Zeile als Hinweis für die Dimensionierung aus. Entweder benötigen die Seiten mehr Speicher als geplant, oder das Limit ist zu niedrig. Legen Sie den Wert anhand einer Messung Ihrer eigenen Seiten fest. Das ist das Thema des nächsten Abschnitts. Die gleichen Accounting-Flags begrenzen auch jeden anderen Dienst auf dem Rechner, und Speicher und CPU mit systemd begrenzen funktioniert bei den übrigen Diensten auf dieselbe Weise.

Peak-Speicherverbrauch selbst messen

Die veröffentlichten Werte stammen von fremder Hardware und anderen Seiten. Der Spitzenwert des Speicherverbrauchs entscheidet darüber, ob Ihr Server stabil läuft. Dieser Spitzenwert hängt vollständig davon ab, welche Inhalte Sie laden. Messen Sie daher, bevor Sie die Größe festlegen.

Für das einmalige Abrufen verwenden Sie das time-Binary. Es liefert deutlich mehr Informationen als das gleichnamige Shell-Builtin:

sudo apt update && sudo apt install -y time
/usr/bin/time -v moli fetch --dump markdown --wait-until networkidle https://example.com > /dev/null

Die Ausgabe endet mit einem Block von Ressourcenstatistiken, der Maximum resident set size (kbytes) enthält. Teilen Sie den Wert durch 1024, um MiB zu erhalten. Führen Sie den Test für zehn Seiten aus, die Ihr Agent tatsächlich aufruft, und nicht für example.com. Verwenden Sie den höchsten Wert statt des Durchschnitts, weil der OOM-Killer auf Spitzenwerte reagiert.

Für den Dienst lesen Sie den Zähler aus, den der Kernel bereits für dessen cgroup führt:

cat /sys/fs/cgroup/system.slice/moli.service/memory.peak
systemd-cgtop -m

memory.peak ist eine Byteanzahl. Der Wert ist der Höchststand seit dem letzten Start der Unit. Ein Neustart setzt ihn daher zurück. Dieser Wert muss unter MemoryMax liegen. Planen Sie zusätzlich Reserve für die schwerste Seite ein, die Sie bisher noch nicht aufgerufen haben. systemd-cgtop -m zeigt die aktuelle Auslastung pro Unit. Damit sehen Sie am schnellsten, welcher Dienst auf dem Server heute den meisten Speicher verbraucht.

Wo scheitert Moli, und wann benötigen Sie weiterhin Chrome?

Das Projekt führt außerdem einen Benchmark mit 1,308 vergleichbaren Aufgaben zur Browserautomatisierung durch und veröffentlicht die Ergebnisse für mehrere Engines.

[
  {
    "engine": "Chrome",
    "success_rate_pct": 99.85
  },
  {
    "engine": "Moli 0.1.1",
    "success_rate_pct": 81.88
  },
  {
    "engine": "Kitesurf",
    "success_rate_pct": 62.08
  },
  {
    "engine": "Lightpanda",
    "success_rate_pct": 53.29
  },
  {
    "engine": "Obscura",
    "success_rate_pct": 44.88
  }
]

Von diesen 5 Engines hat Moli 0.1.1 81.88 Prozent der Aufgaben abgeschlossen. Chrome, die Referenz-Engine, erreichte 99.85 Prozent. Das Projekt bewertet sich hier selbst anhand seiner eigenen Testsuite. Lesen Sie das daher als Angabe des Projekts und nicht als unabhängiges Ergebnis.

Die praktische Bedeutung ist einfach. Bei ungefähr einer von fünf Aufgaben scheiterte Moli, während Chrome sie abschloss. Wenn Ihr Agent eine feste, von Ihnen kontrollierte Gruppe von Seiten aufruft, sagt dieses Verhältnis nur wenig aus. Ihre Seiten funktionieren entweder, oder sie funktionieren nicht. Das können Sie noch am selben Nachmittag prüfen. Wenn Ihr Agent im offenen Web browsed, handelt es sich um eine reale Fehlerquote, die Sie beim Entwurf berücksichtigen müssen.

Welche Fälle scheitern, lässt sich aus dem angegebenen Projektumfang ableiten.

• Anwendungen, die ihre Benutzeroberfläche in ein Canvas-Element statt in das DOM zeichnen, weil die Canvas-Treue ausdrücklich nicht zum Umfang gehört
• Alles, was WebGL oder GPU-Kompositing benötigt, weil kein GPU-Kompositor vorhanden ist
• DRM-geschützte Videos und anspruchsvolle Medienwiedergabe
• Visuelle Tests, die pixelgenaue Screenshots im Vergleich zu Chrome prüfen, da die Parität mit Chrome kein Ziel ist

Die andere vom Projekt genannte Zahl, nach der ein vollständiger Durchlauf 1.612 Millionen Web-Platform-Tests besteht, beschreibt die Abdeckung von Standards. Sie ist keine Zusage für die Websites, die Ihr Agent aufruft. Eine Seite kann ausschließlich gut unterstützte Standards verwenden und trotzdem an einer Bot-Prüfung scheitern. Keine Engine-Bewertung deckt diesen Fall ab.

Planen Sie daher einen Fallback ein. Senden Sie jede URL zuerst an Moli. Wenn eine Seite leer zurückkommt oder ein Selektor nie erscheint, wiederholen Sie den Aufruf dieser URL mit Playwright und echtem Chrome. Verwenden Sie dafür eine größere Maschine oder einen Zeitplan, bei dem ein Prozess mit 773 MiB Arbeitsspeicher vertretbar ist. Die meisten Agents verbringen den größten Teil ihrer Zeit auf gewöhnlichen Seiten. Die kleine Engine übernimmt daher das Volumen, während die teure Engine die seltenen Problemfälle abdeckt.

FAQ

Kann Moli Chrome im Headless-Modus für meinen Agenten ersetzen?

Zum Lesen von Seiten, Extrahieren von Text und gewöhnlichen Klicks in der Regel ja. Im eigenen Benchmark des Projekts erledigte Moli bei 1,308 Aufgaben 81.88 Prozent gegenüber 99.85 Prozent bei Chrome. Das bedeutet, dass etwa jede fünfte Aufgabe Funktionen benötigt, die Moli nicht bietet. Bekannte Lücken sind Canvas-gerenderte Anwendungen, WebGL und DRM-Video. Leiten Sie diese URLs an echtes Chrome weiter, statt vollständig zurückzuwechseln.

Wie viel RAM benötigt Moli auf einem VPS?

Das Projekt meldet einen medianen RSS von 73 MiB bei einem Crawl mit 192 URLs und einen maximalen PSS von 102.46 MiB bei einem Beispiel-Agentenlauf. Bei Headless Chrome lag der Median bei 773 MiB. Das sind die Werte des Projekts auf dessen Seiten. Messen Sie bei einer einmaligen Verwendung mit /usr/bin/time -v rund um einen Aufruf von moli fetch. Für den Dienst lesen Sie /sys/fs/cgroup/system.slice/moli.service/memory.peak aus. Setzen Sie anschließend MemoryMax über den höchsten gemessenen Wert.

Ist es sicher, Port 9222 im Internet bereitzustellen?

Nein. CDP bietet keine Authentifizierung. Jeder, der diesen Port erreichen kann, kann Ihren Browser steuern und alles lesen, worauf der Browser zugreifen kann. Behalten Sie --host 127.0.0.1 bei. Erreichen Sie den Endpunkt von einem anderen Rechner aus über einen SSH-Tunnel oder eine private VPN-Schnittstelle. Wenn Sie zwingend eine andere Adresse binden müssen, verwenden Sie eine private Schnittstelle und beschränken Sie den Zugriff mit der Firewall.

Warum ist mein Screenshot leer oder landet mein Klick an einer falschen Stelle?

Das Layout ist standardmäßig deaktiviert. Die README bezeichnet die Standardrichtlinie als LayoutPolicy::Mock. Daher sind die Geometriedaten der Elemente nicht real, und alles, was auf einer Box auf der Seite basiert, kann nicht funktionieren. Starten Sie den Server mit moli serve --layout oder fügen Sie --layout zu moli fetch hinzu. Danach funktionieren der Screenshot und die Koordinatenpfade. Fehlende Bilder werden durch ein anderes Flag verursacht: --resource.

Welche Moli-Version sollte ich installieren?

Legen Sie eine Version fest und dokumentieren Sie diese. Im August 2026 ist 1.0.1 die aktuelle Version. Die vom Projekt veröffentlichten Benchmarkwerte wurden dagegen mit 0.1.1 ermittelt. Beim Vergleich mit anderen Ergebnissen sind diese Versionen daher nicht austauschbar. Laden Sie das moli-x86_64-unknown-linux-gnu.tar.gz dieses Tags herunter und installieren Sie die Binärdatei selbst. Verwenden Sie nicht den Shell-Installer, da dieser die neueste Version statt des abgerufenen Tags ermittelt. Überprüfen Sie die Installation anschließend mit moli --version.