Mbadala wa Firecrawl kwa VPS: Draco, Hound na Self-hosted

Nini mbadala wa Firecrawl unaojiendesha lazima ufanye

Mbadala wa Firecrawl unaojiendesha una kazi moja: chukua URL na urejeshe ukurasa kama markdown safi ambayo wakala anaweza kuisoma. API zinazohudumiwa hutoza ada kwa kila ukurasa, kwa hivyo gharama huongezeka kulingana na udadisi wa wakala wako, na VPS unayolipia tayari inaweza kufanya kazi hiyo hiyo. Miradi hii hutofautiana katika swali moja: je, headless browser (injini halisi ya kivinjari inayofanya kazi bila dirisha) lazima ianzishwe kwenye seva yako?

Jibu hilo huamua kiasi cha kumbukumbu kinachotumiwa, gharama ya kila ukurasa, na ni kurasa zipi zitakazorejeshwa zikiwa tupu. Mwongozo huu unalinganisha Draco, Hound na toleo la Firecrawl linalojiendesha, unasakinisha toleo jepesi zaidi kwa kutumia version iliyofungwa, na kuliunganisha na wakala kupitia MCP (model context protocol).

Miradi minne, na ufafanuzi wa kila mmoja

Draco ni binary moja, iliyoandikwa kwa Rust, yenye leseni ya MIT au Apache-2.0. Toleo la v0.20.5 lilichapishwa tarehe 16 Julai 2026. draco scrape <url> huchapisha markdown kwenye stdout. draco serve huendesha daemon inayojibu kwenye 127.0.0.1:3002, port inayotumiwa na Firecrawl. Haitoi container image yoyote na haianzishi kivinjari.

Firecrawl self-hosted ndiyo injini inayowezesha bidhaa inayohudumiwa (hosted product), chini ya leseni ya AGPL-3.0. Faili lake la docker-compose.yaml hufafanua huduma saba: playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb na foundationdb-init. Unapata foleni halisi ya kuchimba data (crawl queue), kwa gharama ya kuendesha mfumo mdogo uliosambazwa (distributed system).

Hound inapatikana katika hazina ya master-fetch na kusambazwa kwenye PyPI kama hound-mcp, ikiwa na leseni ya MIT, toleo la 13.0.1 kufikia tarehe 3 Agosti 2026. Inahitaji Python 3.11 au mpya zaidi. Hii ni seva ya MCP kwanza na zana ya kuchota data (fetcher) pili: hujaribu HTTP ya kawaida, na kuanzisha kivinjari cha Patchright pale tu ambapo uchotaji wa kawaida unapozuiwa.

Trawl ipo hapa kwa sababu watu hukutana nayo wanapozitafuta nyingine, na inafanya kazi tofauti. Inatatua changamoto za JavaScript na CAPTCHA kwa kutumia Firefox iliyorekebishwa kwa fingerprint, kama mbadala wa FlareSolverr katika stack ya media ya *arr. Si kiondoa markdown (markdown extractor). Sehemu ya maadili hapa chini inaeleza kwa nini tofauti hiyo huamua kama inafaa kuwemo kwenye stack yako ya wakala (agent stack) au la.

Kwa nini bwawa la vivinjari ni mahali ambapo VPS ndogo hufeli

Kila kichupo cha kivinjari kilicho wazi ni mchakato wa kipekee wa uwasilishaji (renderer process) unaoshikilia DOM (document object model) yake na heap yake ya JavaScript. Kwa hivyo, matumizi ya kumbukumbu huongezeka kulingana na kurasa zilizofunguliwa kwa wakati mmoja, si kulingana na kurasa zilizopakuliwa kwa siku. Miradi miwili kati ya hii huandika gharama hiyo kwenye faili zao za compose.

[
  {
    "label": "Firecrawl api",
    "memory_limit_gb": 8
  },
  {
    "label": "Firecrawl playwright",
    "memory_limit_gb": 4
  },
  {
    "label": "Hound (browser included)",
    "memory_limit_gb": 3
  }
]

Faili ya compose ya Firecrawl huweka kikomo cha kontena lake la api katika 8 GB na kontena lake la Playwright katika 4 GB, pamoja na vikomo vinavyolingana vya swap. Faili ya compose ya Hound huweka 3 GB kwa kontena moja linalobeba Chromium iliyounganishwa. Hivi ni vikomo vilivyochaguliwa na miradi husika, ni takwimu zilizochapishwa badala ya vipimo vya mfumo uliotulia, na Redis, RabbitMQ, PostgreSQL na FoundationDB bado huhitaji sehemu yao juu ya namba za Firecrawl.

Kikomo kilicho juu ya RAM uliyonayo hakina faida yoyote. Seva inapoishiwa na kumbukumbu, kernel out-of-memory killer huua mchakato, hivyo kontena hupotea kutoka docker compose ps bila hitilafu yoyote kuandikwa kwenye logi ya programu. Soma dmesg -T | tail baada ya kuanzisha upya (restart) yoyote ambayo huwezi kuielezea. Tenga 8 GB kwa ajili ya stack nzima ya Firecrawl na uzingatie 4 GB kama kiwango cha chini cha seva ya majaribio. Kuweka namba hizo kwa kila huduma kimeelezwa katika vikomo vya kumbukumbu katika Docker Compose.

Maelezo moja zaidi ya kivinjari huwagharimu watu jioni nzima. Docker hupa kontena 64 MB ya kumbukumbu iliyoshirikiwa (shared memory) katika /dev/shm, na Chromium huweka bafa za uwasilishaji hapo, hivyo huanguka (crash) kwenye kurasa nzito. Stack zote mbili za vivinjari huongeza kiwango hicho: faili ya compose ya Hound ina shm_size: "1gb". Nakili mstari huo kwenye image yoyote unayojenga inayotumia Playwright.

Ubora wa uchimbaji data kwenye kurasa zenye JavaScript nyingi

Kwenye HTML tuli, blogu inayotolewa na seva, ukurasa wa nyaraka, au makala ya habari, yote haya hurejesha markdown inayofanana karibu kabisa na ile inayopatikana kwa kasi zaidi ndiyo inayoshinda. Tofauti huonekana kwenye kurasa zinazotolewa na mteja (client-rendered), ambapo HTML inayowasilishwa ni ganda tupu na maandishi hufika kupitia JavaScript baada ya ukurasa kupakiwa.

Draco hupanda ngazi kwa hatua. Hatua ya 0 na hatua ya 1 huchanganua HTML bila JavaScript yoyote. Hatua ya 2 huendesha JavaScript ya ukurasa ndani ya V8 isolate ya ndani ya mchakato, ambayo ni injini ya JavaScript bila kivinjari kuizunguka, na README inabainisha kuwa msimbo wa ukurasa haupati uwezo wa kuunganisha na seva (host capability bindings) hapo. Hii inashughulikia programu nyingi za ukurasa mmoja (single-page applications) kwa sehemu ndogo ya kumbukumbu ya kivinjari. Draco inapokutana na kikwazo kisichoweza kupitika, draco scrape hutoka na msimbo 3, needs_browser. Iangalie kwenye hati (scripts), kwa sababu faili tupu yenye msimbo wa kutoka wa sifuri ni hitilafu inayoharibu muktadha wa wakala kimyakimya:

draco scrape https://example.com > page.md
echo "exit=$?"

Huduma ya playwright-service ya Firecrawl huendesha Chromium halisi, kwa hivyo hutoa kile ambacho kivinjari hutoa. Toleo linalojiendesha (self-hosted) bado si bidhaa inayohudumiwa na wingu: nyaraka zinabainisha kuwa mifano inayojiendesha haina ufikiaji wa Fire Engine, kwa hivyo uwezo wa kuzuia kuzuiliwa (anti-blocking) na mzunguko wa IP wa huduma ya wingu haupo, na endpoints za /agent na /browser hazitumiki. Hound hukaa katikati kwa makusudi. Huchota data kupitia HTTP na hupanda ngazi kwa kila ombi, na kivinjari chake cha akiba hufungwa baada ya muda wa kutofanya kazi (idle timeout), kwa hivyo seva tulivu hubaki karibu na matumizi ya kawaida.

Sakinisha Draco kwa kutumia toleo maalum (pinned version)

README inaelezea kisakinishi cha mstari mmoja. Soma kinachofanya kabla ya kukipeleka kwenye shell: kinasakinisha kwenye $HOME/.draco/bin/draco, kinachukua toleo la latest kila wakati, na hakikagui sahihi (signature) au hash yoyote. Kwenye seva, funga toleo (pin) na uhakiki upakuaji.

cd /tmp
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/draco-linux-x86-64.tar.gz
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS

Hiyo inachapisha draco-linux-x86-64.tar.gz: OK. Mstari wa FAILED unamaanisha kuwa baiti ulizonazo si zile ambazo mradi ulichapisha, kwa hivyo zifute na uanze upya.

mkdir -p draco-v0.20.5
tar -xzf draco-linux-x86-64.tar.gz -C draco-v0.20.5
sudo install -m 755 "$(find draco-v0.20.5 -type f -name draco | head -n1)" /usr/local/bin/draco
draco scrape https://example.com

Amri ya mwisho inachapisha ukurasa wa mfano kama markdown kwa muda mfupi sana chini ya sekunde moja. find si mapambo: mpangilio wa kumbukumbu (archive layout) si sehemu ya mkataba wa umma wa mradi, na kisakinishi rasmi kinatafuta binary kwa njia hiyo hiyo.

Endesha daemon chini ya akaunti yake badala ya mtumiaji wako wa kuingia. Andika /etc/systemd/system/draco.service:

[Unit]
Description=Draco fetch daemon
After=network-online.target
Wants=network-online.target

[Service]
User=draco
ExecStart=/usr/local/bin/draco serve --host 127.0.0.1 --port 3002 --max-concurrency 4
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo useradd --system --no-create-home --shell /usr/sbin/nologin draco
sudo systemctl daemon-reload
sudo systemctl enable --now draco
curl -s http://127.0.0.1:3002/health

/health inajibu mara tu daemon inaposikiliza. Connection refused inamaanisha haisikilizi, kwa hivyo soma journalctl -u draco -n 50. Sababu ya kawaida ni mchakato mwingine ambao tayari unashikilia 3002, kwa kuwa huo pia ndio port chaguo-msingi ya Firecrawl, na --port inahamisha mojawapo. Faili za unit kwa kina zaidi: systemd service units and timers.

Sasa leta data kwa njia ambayo wakala wako atafanya:

curl -X POST http://127.0.0.1:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

Zuia daemon ya fetch isipatikane kwenye Internet ya umma

API ya fetch isiyo na uthibitishaji ni proxy iliyo wazi. Mtu yeyote anayeweza kufikia port hiyo anaweza kuifanya seva yako iombe URL yoyote kwa kutumia anwani yako ya IP, na ripoti za matumizi mabaya zitatumwa kwa mtoa huduma wako, si kwao. Bendera za serve zilizoorodheshwa kwenye nyaraka za Draco hazijumuishi API key, kwa hivyo ulinzi lazima utokane na mtandao. Dumisha 127.0.0.1 ya kawaida ya bind wakati wakala anapofanya kazi kwenye mashine hiyo hiyo. Wakati wakala yupo mahali pengine, weka ncha zote mbili kwenye tunnel ya kibinafsi, WireGuard VPN unayojiendeshea mwenyewe ndiyo suluhisho la kawaida, na fanya bind kwenye anwani ya tunnel badala ya 0.0.0.0. Kisha hakikisha kutoka kwa mashine nyingine kuwa IP ya umma haijibu chochote. misingi ya ufw firewall na akaunti za watumiaji zenye upendeleo mdogo zinashughulikia sehemu hizo mbili.

Je, msimbo wa wakala wako utabadilika? Upatanifu wa API katika utendaji

Draco inajibu njia za Firecrawl v1: /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape na /v1/search, na README yake inaeleza kuwa sehemu zisizojulikana hukubaliwa na kupuuzwa. Wakala ambaye tayari anachapisha kwenye /v1/scrape anahitaji URL mpya ya msingi na si kitu kingine. Fuatilia kilichohamia upande mwingine: ukurasa wa self-hosting wa Firecrawl sasa hufanya majaribio kwa /v2/crawl, na SDK za sasa hutumia v2, kwa hivyo mteja wa v2 anayeelekezwa kwa Draco huomba njia ambayo Draco haichapishi. Jaribu kila wito kwa curl kabla ya kuhariri msimbo wa wakala, na usome mwili wa JSON badala ya msimbo wa hali (status code), kwa sababu majina ya sehemu ndipo utekelezaji huu unapotofautiana.

Robots.txt, rate limits, na mstari wa kutovuka

Draco husoma robots.txt kwa chaguomsingi, na --ignore-robots huzima hilo. Firecrawl inaelekeza chaguomsingi ileile. Acha zote mbili kama zilivyo. Kisha weka kasi yako mwenyewe: --delay huweka milisekunde kati ya maombi na --max-concurrency hupunguza kazi zinazofanyika kwa wakati mmoja, huku 8 ikiwa ndiyo chaguomsingi ya daemon. Mbili hadi nne ni rafiki zaidi kwa link ya VPS inayoshirikiwa na mara chache huwa polepole kwa ujumla, kwa sababu tovuti inayoanza kukuwekea rate limiting hugharimu dakika nyingi zaidi kuliko muda unaookolewa na concurrency. Hifadhi kwenye cache unachokipakua, ili uendeshaji wa pili wa agent usiigharimu chanzo chochote. Hiyo pia ndiyo gharama nafuu zaidi katika kudhibiti gharama za AI agent.

Challenge walls ni mada tofauti, na Trawl imeundwa kwa ajili hiyo hasa: Cloudflare Turnstile, reCAPTCHA, hCaptcha na GeeTest. Challenge wall ni tovuti inayokataa trafiki ya kiotomatiki kwa lugha ya wazi. Kujaribu kuikwepa kunakuweka dhidi ya sheria za matumizi za tovuti hiyo, na katika maeneo mengine dhidi ya sheria za nchi, kwa hivyo mwongozo huu unashughulikia miundombinu ya kupakua data na kuishia hapo. Mbinu zilezile zinazopita ukuta ndizo wamiliki wa tovuti huzifuatilia na kuzizuia, jambo linalofanya pipeline yoyote iliyojengwa juu yake kuwa dhaifu na isiyo na adabu. Chanzo kinapokuwa muhimu kiasi hicho, tafuta RSS feed yake, API yake ya umma, au bulk export. Kila moja ni nafuu kuendesha na hakuna inayovunjika wiki ileile ambayo ukuta unabadilika.

Iunganishe na wakala kupitia MCP

MCP (model context protocol) ndiyo kiolesura ambacho wakala hutumia kuita zana. Draco hubeba seva ya MCP ndani ya binary ileile, kupitia stdio:

{ "mcpServers": { "draco": { "command": "draco", "args": ["mcp"] } } }

Zana hizo kisha huonekana kwa wakala kama draco_scrape, draco_search na seti ya draco_interact_*. Stdio hufanya kazi tu wakati mchakato wa wakala na binary viko kwenye mashine moja, kwa sababu usafirishaji hutumia ingizo la kawaida (standard input) la mchakato huo. Kwa wakala aliye kwenye host nyingine, Hound hutumikia MCP kupitia HTTP badala yake: hound --http --host 127.0.0.1 --port 8765 huchapisha endpoint kwenye http://127.0.0.1:8765/mcp, ambayo unaifikia kupitia handaki (tunnel). Chaguzi za usafirishaji na nini cha kufichua viko kwenye kuendesha seva za MCP kwenye VPS.

Kutafuta jozi kwa kutumia search. Wakala anayeweza kufanya fetch pekee husubiri umpe URL. Ongeza instance ya utafutaji ya SearXNG inayojiendesha na ataweza kuzipata mwenyewe, kwa muundo uleule wa ujuzi wa utafutaji wa kivinjari uliojengwa juu ya SearXNG. Mara tu daemon inapokuwa juu, inakuwa huduma moja iliyoshirikiwa kwa yeyote kati ya mawakala wa AI wanaojiendesha unaoendesha.

FAQ

Je, nahitaji headless browser ili kuchota kurasa kwa ajili ya AI agent?

Kwa kurasa nyingi, hapana. Nyaraka, blogu na makala za habari zinazotolewa na seva hurejea zikiwa kamili kupitia HTTP fetch ya kawaida ikifuatiwa na hatua ya HTML-to-markdown. Hii ndiyo njia inayotumiwa na Draco katika viwango vyake vya chini, ikichukua takriban 300 ms kwa kila ukurasa bila kutumia browser, kulingana na takwimu za mradi huo. Browser hutumia kumbukumbu nyingi kwenye programu zinazotolewa na mteja (client-rendered), ambapo HTML inayofika ni ganda tupu. V8 isolate ya Draco inashughulikia sehemu kubwa ya kazi hiyo bila mchakato wa browser, na inatoka (exit) na code 3, needs_browser, pale inaposhindwa.

Firecrawl inayojiendesha yenyewe inahitaji RAM kiasi gani kwenye VPS?

Faili yake ya compose huweka kikomo cha 8 GB kwenye container ya api na 4 GB kwenye container ya Playwright, na stack hiyo hiyo pia huanzisha Redis, RabbitMQ, PostgreSQL na FoundationDB. Panga kuwa na 8 GB. Kwenye seva ya 2 GB, kernel out-of-memory killer huondoa containers wakati wa mzigo mkubwa, na ishara ya kwanza ni container kuanza upya katika docker compose ps bila ujumbe wowote muhimu kwenye log ya programu, kwa hiyo thibitisha hili kwa dmesg -T | tail.

Je, Draco ni mbadala wa moja kwa moja wa Firecrawl API?

Kwa endpoints za v1, inakaribia sana. Inatoa /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape na /v1/search, na inapuuza sehemu za ombi (request fields) ambazo haizijui, kwa hiyo mteja aliyeandikwa kwa ajili ya Firecrawl v1 kwa kawaida anahitaji tu base URL mpya. Hii si bidhaa inayohudumiwa (hosted product): hakuna managed proxy pool nyuma yake, na njia mpya za v2 za Firecrawl si sehemu ya mfumo huu. Thibitisha kila wito (call) unaofanywa na agent wako kwa kutumia curl kwanza.

Je, kujiendeshea scraper mwenyewe kunamaanisha naweza kupuuza robots.txt?

Hapana. Mahali ambapo code inaendeshwa hakubadilishi chochote kuhusu kile ambacho tovuti imechapisha au kile ambacho masharti yake yanaruhusu. Draco na Firecrawl zote huheshimu robots.txt kwa chaguo-msingi, na flag ya override ipo kwa ajili ya tovuti unazomiliki au ulizopewa ruhusa ya kuzichota (crawl). Rate limits hutekelezwa upande wa pili bila kujali, kwa hiyo --delay ya heshima yenye concurrency ya chini huifanya IP address yako iendelee kufanya kazi. Stack inayofanya kazi kwa kuvunja tu challenge wall ni stack inayoweza kuharibika bila onyo.