Moli self-host: Küçük VPS için headless browser

Küçük bir VPS üzerinde çalışabilen headless browser

Moli, AI agent'ları için geliştirilmiş bir headless browser'dır ve headless Chrome'un sığmayacağı kadar küçük bir VPS üzerinde self-host edilebilecek kadar hafiftir. Chromium etrafında oluşturulmuş bir wrapper değil, Rust ile yazılmış bir browser engine'dir ve otomasyon kitaplığınızın zaten kullandığı Chrome DevTools Protocol'ünü (CDP) destekler. Tek bir binary kurulur, moli serve çalıştırılır, ardından Playwright veya kendi agent kodunuz http://127.0.0.1:9222 adresine yönlendirilir.

Kurulumdan önce bu tercihin karşılığını değerlendirin. Proje kapsamını açıkça belirtir: GUI browser yoktur, GPU compositor yoktur, Chrome ile piksel düzeyinde eşdeğerlik yoktur ve Canvas veya media playback için yüksek uyumluluk sunulmaz. Bunlara ihtiyaç duyan sayfalar başarısız olur. Playwright altında gerçek Chrome kullanılmaya devam eden fallback seçenektir. Son bölümde, hangi sayfaların buna ihtiyaç duyduğunun nasıl belirleneceği gösterilir.

Aşağıdaki her komut, projenin README dosyasından ve Ağustos 2026 tarihinde incelenen yayımlanmış skill dosyalarından alınmıştır. Grafiklerdeki tüm sayılar, bu sitenin yaptığı ölçümler değil, projenin kendi engine'i hakkında yayımladığı değerlerdir. Her grafik açıklamasında bu durum belirtilir. Hâlâ bir engine seçiyorsanız, VPS üzerinde agent'lar için headless browser'lar hakkındaki daha kapsamlı incelemede alternatifler ele alınır.

Headless Chrome neden bu kadar fazla bellek kullanır?

Chrome, çok süreçli bir tarayıcıdır. Her sekme ve siteler arası her iframe kendi renderer sürecini alır. Her renderer kendi V8 heap alanını ve grafik buffer’larını taşır. Bu tasarım, bir sekmenin çökmesinin tüm pencereyi etkilememesi gereken masaüstü sistemler için uygundur. 2 GB VPS üzerinde ise tek bir tarama adımı, çalıştırılan asıl uygulamadan daha fazla bellek kullanabilir.

Proje, dört engine kullanarak 192 farklı herkese açık URL’yi taradı ve sonucu yayımladı.

[
  {
    "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, 101 yararlı sayfa döndürdü. Moli ise 103 yararlı sayfa döndürdü. Bu örnekte iki engine web’in yaklaşık aynı bölümünü okudu. Ayrım bellek kullanımında ortaya çıkar: Chrome için medyan RSS (resident set size, bir sürecin RAM’de gerçekten tuttuğu bellek) 773 MiB iken Moli için 73 MiB’dir. Bu farkın yönü güvenilirdir. Bunun nedeni süreç mimarisinden kaynaklanmasıdır. Ancak kendi sayfalarınızdaki kesin oranı varsaymamalısınız.

Sizi zorlayan değer medyan değildir. Tepe değerdir. 2 GB kapasiteli bir sistem belleği tükendiğinde kernel bir süreç seçerek onu sonlandırır. Kayıt dmesg -T veya journalctl -k içine yazılır:

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

Agent bu satırı hiçbir zaman görmez. Yanıt vermeyi durduran bir browser görür. Bu durum genellikle page.goto: Page crashed gibi bir Playwright hatasıyla veya kapatılmış bir target ile kendini gösterir. Bu hatada bellekten söz edilmez. Bu nedenle küçük bir sistemde agent rastgele başarısız olduğunda ilk kontrol edilmesi gereken OOM (out of memory) killer’dır. Tepe değere göre kapasite planlamak, bir agent VPS için RAM ve CPU seçmekle aynı işlemdir.

Moli binary dosyasını tek bir sürüme sabitleyerek yükleme

Proje, GitHub releases üzerinde bir shell yükleyicisi ve önceden derlenmiş tarball dosyaları yayımlar. Ağustos 2026 itibarıyla güncel sürüm 1.0.1'dir ve 18 Ağustos 2026 tarihinde yayımlanmıştır. Bu kılavuzda verilen benchmark sonuçları proje tarafından 0.1.1 üzerinde ölçülmüştür. Bu nedenle sonuçlar, yüklenen build için kesin bir vaat olarak değil, engine'in genel davranışını gösteren yaklaşık değerler olarak değerlendirilmelidir.

Sürümü sabitleyin. Her zaman latest çözen bir yükleyici, bir sonraki rebuild işleminde agent'ınızı farklı bir browser engine sürümüne taşır. Browser davranışındaki değişiklikleri önceden planlamak, bunları beklenmedik şekilde fark etmekten daha uygundur.

Shell yükleyicisi hızlı başlangıç sağlar. Ancak çalıştırmadan önce okunmalıdır.

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

Çalıştırmadan önce script'i okuyun. Kısadır. uname -m içinden bir arşiv seçer ve tek bir binary dosyasını ~/.local/bin içine açar. x86_64 üzerinde moli-x86_64-unknown-linux-gnu.tar.gz dosyasını, Arm sunucusunda ise aarch64 arşivini kullanır. Bu nedenle Arm ve x86 VPS planlarının ikisi de desteklenir. Başka bir konuma yüklemek için MOLI_INSTALL_DIR değerini ayarlayın. Sürüm için ne çözdüğüne dikkat edin: script'i aldığınız tag'i değil, en yeni release'i kullanır. İlk inceleme için bu kabul edilebilir. Tekrarlanabilir bir rebuild için ise uygun değildir.

Bu nedenle kalıcı kurulumlarda yükleyicinin yaptığı işlemleri elle gerçekleştirin ve tam arşiv adını kendiniz belirtin. Binary dosyasını bir system service tarafından erişilebilecek bir konuma yerleştirmenin yolu da budur. Ayrıca indirilen bir script'i shell'e pipe etme ihtiyacını ortadan kaldırır.

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

Sabitlenen sürümün yazdırılması, kontrolün tamamıdır: moli --version. Yükleyiciden hemen sonra moli: command not found çıktısının alınması, kurulum dizininin PATH içinde olmadığını gösterir. Yükleyici, eklemeniz gereken dizinin adını içeren bir satır yazdırır.

moli fetch ile tek seferlik veri çıkarma

Bir agent'a verilen görevlerin çoğu, "bu URL'yi yükle ve ne yazdığını söyle" şeklindedir. Bunun için sunucu gerekmez. moli fetch motoru başlatır, tek bir sayfa yükler, tek bir artifact'i standard output'a yazar ve çıkar. Böylece çağrılar arasında bellekte veri tutulmaz.

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

İlk komut, # Example Domain ile başlayan sayfayı Markdown olarak yazdırır. Markdown, markup'ı kaldırıp metni koruduğu için bir modele aktarılabilecek en düşük maliyetli biçimdir. semantic_tree_text rolleri ve yapıyı korur. Bu seçenek, bağlantıların metin kadar önemli olduğu, navigasyon ağırlıklı sayfalarda tercih edilmelidir. --dump json HTTP durumunu ve istek izini içerir. Bir fetch işlemi boş döndüğünde ve nedenini öğrenmek gerektiğinde bu seçenek kullanılmalıdır.

Bekleme stratejisi, içerik mi yoksa boş bir kabuk mu alınacağını belirler. --wait-until networkidle ağ trafiği durduğunda döner. --wait-until domstable DOM değişmeyi bıraktığında döner. Arka planda sürekli polling yapan ve bu nedenle ağ trafiğinin hiç durmadığı sayfalarda daha uygun seçenek budur. --wait-selector belirtilen tek bir selector için bekler. Fetch edilen sayfa hakkında bilgi sahibi olan tek strateji budur. Bu nedenle hedef biliniyorsa en güvenilir seçenektir.

Screenshot ve PDF için gerçek layout gerekir. Layout varsayılan olarak kapalıdır:

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

README'de varsayılan layout policy LayoutPolicy::Mock olarak belirtilir: geometry taklit edilir ve hiçbir şey render edilmez. Bunun nedeni, layout ve paint işlemlerinin browser kaynak tüketiminin pahalı bölümünü oluşturmasıdır. Yukarıdaki bellek değerlerinin bu şekilde görünmesinin nedeni de budur. Bu durum, boş bir PNG dosyasının genellikle bozuk bir sayfadan değil, eksik --layout flag'inden kaynaklandığı anlamına gelir.

Agent'ın sizin seçtiğiniz URL'ler yerine bulduğu URL'ler için --block-private-networks eklenmelidir. Bir sayfada okuduğu bağlantıları takip eden agent, cloud instance kimlik bilgileri için http://169.254.169.254/ adresine veya web'e açılması hiç amaçlanmamış bir localhost database portuna yönlendirilebilir. Bu flag, private address space içine yapılan navigation işlemlerini reddeder. --block-cidrs ise kapsamı daha da daraltır. İş tek bir sayfayı okumak yerine crawling yapıyorsa bu pipeline'ın yapısı self-hosted Firecrawl alternatifleri bölümünde ele alınır. Bundan önceki adım olan URL'leri bulma konusu ise agent'lar için SearXNG destekli search skill bölümünde ele alınır.

Moli'yi CDP üzerinden bir ajana bağlama

Birden fazla adımda gezinen ve tıklayan bir ajan için bunun yerine sunucuyu çalıştırın.

moli serve --host 127.0.0.1 --port 9222

127.0.0.1 ve 9222 numaralı port varsayılandır; bu nedenle yalnızca moli serve kullanıldığında da bind işlemi sadece loopback adresine yapılır. Yine de kalıcı yapılandırmalarda ikisini de açıkça yazın. Böylece service dosyasını daha sonra okuyacak kişinin varsayılan değeri hatırlaması gerekmez.

Bir istemciyi bağlamadan önce sunucuyu kontrol edin:

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

Çalışan bir sunucu, webSocketDebuggerUrl alanını içeren bir JSON nesnesi döndürür. CDP istemcisi bu URL'ye bağlanır. curl: (7) Failed to connect to 127.0.0.1 port 9222: Connection refused hiçbir sürecin dinlemediğini gösterir. Bu durumda sunucuyu başlattığınız terminali kontrol edin veya servis olarak çalışıyorsa journalctl -u moli -n 50 komutunu kullanın. /json/list açık hedefleri, /json/protocol ise bu derlemenin uyguladığı alanları listeler. Böylece kullandığınız bir CDP yönteminin burada mevcut olup olmadığını öğrenebilirsiniz.

Playwright, kendi tarayıcısını başlatmak yerine bu uç noktaya bağlanır:

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();

Önemli olan satır connectOverCDP satırıdır; chromium.launch() değildir. Burada alt süreç olarak çalışan bir Chromium süreci yoktur. Bu nedenle executablePath ve --no-sandbox gibi yaygın container flag'lerinin etkileyebileceği bir süreç bulunmaz. Proxy, cookie ve user-agent ayarları da aynı nedenle Moli sunucusuna kendi flag'leri olarak verilir. CDP'nin tamamı yerine desteklenen CDP kapsamını bekleyin. Açıkça bildirilen bir desteklenmeyen yöntem hatası, kodunuzdaki bir hatayı değil, engine sınırını gösterir.

İki sunucu flag'i, ajanın neler yapabileceğini belirler. --layout gerçek geometriyi etkinleştirir. Koordinatla tıklama ve screenshot işlemleri için bu gerekir. --resource isteğe bağlı image, font ve media kaynaklarını alır. Bu işlem her sayfa yüklemesinde bandwidth ve memory tüketir. Bu nedenle bir sayfanın ihtiyaç duyduğu kanıtlanana kadar kapalı bırakın. --profile-dir cookie ve storage verilerini çalıştırmalar arasında kalıcı hale getirir. Bu olmadan her çalıştırma geçicidir.

[
  {
    "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
  }
]

Projenin örnek agent workload'unda Moli, 34.85 ms içinde CDP bağlantısını kabul etti. Chromium için bu süre 169.37 ms idi. En yüksek PSS değeri, yani paylaşılan sayfaların bunları paylaşan süreçler arasında bölüştürülerek hesaba katıldığı proportional set size değeri, 102.46 MiB oldu. Chromium'da bu değer 348.82 MiB idi. Yapısal fark son sütundadır: 1 process yerine 11 process. Tek process, systemd tarafından denetlenecek tek bir bileşen ve sınırlandırılacak tek bir cgroup anlamına gelir. Bu nedenle sonraki bölüm kısa olur.

Loopback üzerinde moli serve uygulamasını systemd servisi olarak çalıştırma

Bir agent kendisini bekleyen bir tarayıcıya ihtiyaç duyduğunda sunucuyu servis olarak çalıştırın. Böyle bir ihtiyaç yoksa URL başına moli fetch kullanmaya devam edin; çünkü boşta bekleyen bir sunucu da belleği kullanmaya devam eder.

9222 numaralı portu public bir arayüzde dinlemeye açmayın. CDP hiçbir türde kimlik doğrulama adımı içermez. Bu porta erişebilen herkes tarayıcıyı yönetebilir ve tarayıcının erişebildiği her şeyi, profil dizininizdeki cookie değerleri dahil, okuyabilir. Servisi 127.0.0.1 üzerinde tutun. Başka bir makineden erişmek için SSH tunnel (ssh -L 9222:127.0.0.1:9222 user@your-vps) veya private VPN arayüzü kullanın ve agent'ın kendi tarafında http://127.0.0.1:9222 adresine bağlanmasını sağlayın.

Bir servis kullanıcısı oluşturun, ardından unit dosyasını oluşturun:

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

/etc/systemd/system/moli.service dosyasını yazın:

[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 çıktısında active (running) görünmelidir. curl ise discovery JSON verisini döndürmelidir. ProtectSystem=strict bu unit için tüm dosya sistemini salt okunur olarak mount eder. Bu nedenle StateDirectory=moli burada isteğe bağlı değildir: servis kullanıcısının sahip olduğu /var/lib/moli dizinini oluşturur ve yalnızca bu yolu yazılabilir hale getirir. Başlayıp ardından journalctl -u moli içinde permission error ile sonlanan bir unit, neredeyse her zaman ProtectSystem tarafından salt okunur hale getirilen bir konuma yazmaya çalışıyordur. Bu yolu state directory altına taşıyın.

MemoryMax=768M, bu servisin uygulamanızın yanında güvenli biçimde çalıştırılmasını sağlar. Unit kendisine ait bir cgroup alır. Bu cgroup limitini aştığında kernel içindeki bir süreci sonlandırır ve sunucunun geri kalanını etkilemez. journal bu olayı kaydeder:

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

Bu satırı boyutlandırma için bir sinyal olarak değerlendirin. Sayfalar planladığınızdan daha ağır olabilir veya limit çok düşük olabilir. Değeri kendi sayfalarınızdan alacağınız bir ölçüme göre belirleyin. Bu işlem sonraki bölümde açıklanır. Aynı accounting flag'leri sunucudaki diğer servisleri de kendi sınırları içinde tutar. systemd ile bellek ve CPU kullanımını sınırlandırma başlığı, bu servislerin geri kalanı için de aynı mekanizmayı kullanır.

Tepe bellek kullanımını kendiniz ölçün

Yayımlanan değerler başka birinin donanımından ve başka sayfalardan elde edilmiştir. Sunucunuzun çalışmaya devam edip edemeyeceğini tepe bellek kullanımı belirler ve tepe değer tamamen ne yüklediğinize bağlıdır. Boyutlandırma yapmadan önce ölçüm alın.

Tek seferlik veri çekme işlemleri için aynı adlı shell builtin komutundan çok daha fazla bilgi raporlayan time binary dosyasını kullanın:

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

Çıktı, Maximum resident set size (kbytes) değerini de içeren bir kaynak istatistikleri bloğuyla sona erer. MiB değerini elde etmek için bu değeri 1024'e bölün. Ölçümü example.com üzerinde değil, agent'ınızın gerçekten ziyaret ettiği on sayfa üzerinde gerçekleştirin ve ortalama yerine en yüksek sonucu kullanın; çünkü OOM killer tepe değerlerine göre tepki verir.

Servis için kernel'ın cgroup kapsamında tuttuğu sayacı okuyun:

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

memory.peak byte cinsinden bir sayıdır ve unit en son başlatıldığından beri görülen en yüksek değeri gösterir; dolayısıyla yeniden başlatma bu değeri sıfırlar. MemoryMax değeri, henüz ziyaret etmediğiniz en ağır sayfa için ek pay bırakılarak bu değerin üzerinde olmalıdır. systemd-cgtop -m her unit için anlık kullanımı gösterir ve sunucudaki hangi servisin bugün en fazla kaynak tükettiğini görmenin en hızlı yoludur.

Moli nerede başarısız olur ve Chrome'a ne zaman ihtiyaç duyulur?

Proje ayrıca karşılaştırılabilir 1,308 tarayıcı otomasyonu görevi üzerinde bir benchmark çalıştırır ve çeşitli engine'ler için skoru yayımlar.

[
  {
    "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
  }
]

5 engine arasında Moli 0.1.1 görevlerin 81.88 yüzdesini tamamlarken referans engine olan Chrome, görevlerin 99.85 yüzdesini tamamladı. Bu, projenin kendi test grubunda yaptığı bir puanlamadır. Bu nedenle bağımsız bir sonuçtan çok proje iddiası olarak değerlendirilmelidir.

Pratik sonuç basittir. Chrome'un tamamladığı yaklaşık her beş görevden biri Moli'de başarısız oldu. Agent'ınız yalnızca kontrol ettiğiniz sabit bir sayfa kümesini ziyaret ediyorsa bu oran fazla bilgi vermez. Sayfalarınız ya çalışır ya da çalışmaz ve sonucu aynı gün öğrenebilirsiniz. Agent'ınız açık web'de gezinüyorsa bu, tasarımda dikkate alınması gereken gerçek bir hata oranıdır.

Başarısızlıkların nedeni, projenin belirttiği kapsamdan öngörülebilir.

• Arayüzünü DOM yerine Canvas elementine çizen uygulamalar; çünkü Canvas doğruluğu açıkça kapsam dışıdır
• WebGL veya GPU compositing gerektiren her şey; çünkü GPU compositor bulunmaz
• DRM korumalı video ve yüksek kaynak gerektiren medya oynatma
• Chrome ile piksel düzeyinde birebir ekran görüntüsü eşleşmesi doğrulayan görsel testler; çünkü Chrome ile parity sağlamak hedef değildir

Projenin belirttiği diğer rakam, tek bir tam çalıştırmada 1.612 milyon web platform testinin geçmesi, standart kapsamıyla ilgilidir. Bu, agent'ınızın ziyaret edeceği siteler için bir garanti değildir. Bir sayfa yalnızca iyi desteklenen standartları kullansa bile bot kontrolünde başarısız olabilir. Hiçbir engine skoru bu durumu kapsamaz.

Bu nedenle tasarımda fallback bulundurun. Her URL'yi önce Moli'ye gönderin. Bir sayfa boş dönerse veya bir selector hiç görünmezse, o URL'yi Playwright ile gerçek Chrome'u çalıştırarak yeniden deneyin. Bu işlemi daha büyük bir makinede veya 773 MiB boyutundaki bir sürecin karşılanabildiği bir zamanlamayla yapın. Agent'ların çoğu zamanını sıradan sayfalarda geçirir. Bu nedenle küçük engine hacmi taşırken pahalı engine uç durumları ele alır.

FAQ

Moli, agent'ım için headless Chrome'un yerini alabilir mi?

Sayfaları okumak, metin çıkarmak ve standart tıklama işlemleri için çoğu durumda evet. Projenin 1,308 görevden oluşan kendi benchmark'ında başarı oranı q:lexbench_tasks:success_rate_pct@1% yüzde olarak ölçülmüştür. Chrome'un oranı ise q:lexbench_tasks:success_rate_pct yüzdedir. Bu nedenle yaklaşık her beş görevden biri Moli'nin desteklemediği bir işlem gerektirir. Canvas ile oluşturulan uygulamalar, WebGL ve DRM video bilinen eksiklerdir. Bu URL'leri her şeyi yeniden Chrome'a taşımak yerine gerçek Chrome'a yönlendirin.

Moli'nin bir VPS üzerinde ne kadar RAM'e ihtiyacı vardır?

Proje, 192 URL'lik bir tarama genelinde q:crawl_rss:median_rss_mib MiB medyan RSS ve örnek bir agent oturumunda q:agent_episode:peak_pss_mib MiB tepe PSS bildiriyor. Headless Chrome için medyan değer q:crawl_rss:median_rss_mib@1% MiB. Bunlar projenin kendi sayfalarındaki ölçümlerdir. Tek seferlik kullanımda bir moli fetch çağrısının çevresinde /usr/bin/time -v ile kendi değerlerinizi ölçün. Servis için /sys/fs/cgroup/system.slice/moli.service/memory.peak değerini okuyun. Ardından MemoryMax değerini gördüğünüz en yüksek değerin üzerine ayarlayın.

9222 numaralı portu internete açmak güvenli midir?

Hayır. CDP kimlik doğrulaması yapmaz. Bu nedenle bu porta erişebilen herkes tarayıcınızı kontrol edebilir ve tarayıcının erişebildiği her şeyi okuyabilir. --host 127.0.0.1 değerini koruyun. Endpoint'e başka bir makineden SSH tüneli veya özel bir VPN arayüzü üzerinden erişin. Başka bir adrese bind etmeniz gerekiyorsa bu adresi özel bir arayüze atayın ve erişimi firewall ile denetleyin.

Ekran görüntüm neden boş veya tıklamam neden hiçbir yere gitmiyor?

Layout varsayılan olarak kapalıdır. README'de varsayılan policy LayoutPolicy::Mock olarak belirtilir. Bu nedenle element geometry gerçek değildir ve sayfadaki bir kutuya bağlı hiçbir işlem kullanabileceği bir geometri bulamaz. Sunucuyu moli serve --layout ile başlatın veya --layout değerini moli fetch içine ekleyin. Böylece ekran görüntüsü ve koordinat tabanlı işlemler çalışmaya başlar. Eksik görseller farklı bir flag ile ilgilidir: --resource.

Moli'nin hangi sürümünü kurmalıyım?

Tek bir sürüme sabitleyin ve hangi sürümü kullandığınızı kaydedin. Ağustos 2026 itibarıyla güncel release 1.0.1'dir. Ancak projenin yayımladığı benchmark değerleri 0.1.1 üzerinde ölçülmüştür. Bu nedenle başkalarıyla karşılaştırma yaparken bu iki sürüm birbirinin yerine kullanılamaz. İlgili tag'e ait moli-x86_64-unknown-linux-gnu.tar.gz dosyasını indirin ve binary dosyasını kendiniz kurun. Tag'i indirdiğiniz sürüm yerine en yeni release'i çözen shell installer'a güvenmeyin. Ardından moli --version ile doğrulayın.