Not all seven sniper monitors are equal. Three run on plain HTTP requests and port to the cloud cheaply. Four spin up a full Chromium browser -- and that changes everything about cost, proxies, and ban risk.
A JSON GET or a TLS-fingerprinted fetch against a REST API. No browser, no session, no cookies to manage (or just one access_token refreshed occasionally). RAM cost: a few megabytes per concurrent request. Runs on serverless cron, a Cloudflare Worker, or the cheapest VPS you can find. Wallapop, Vinted catalog polling, and OfferUp all fall here.
Spins up a real Chromium process. Each concurrent instance wants 500MB to 1GB of RAM, requires a logged-in user session (stored cookies), and must arrive from a clean residential or mobile IP or Facebook will checkpoint or ban it immediately. Facebook Cars, Facebook Electronics, Mercari, and the Vinted cookie-bootstrap job all live here.
| Monitor | Transport | Cloud Portability | RAM Footprint | Proxy Requirement | What changes if web-hosted |
|---|---|---|---|---|---|
| Wallapop lib/wallapop-sniper.js | HTTP requests | Ports as-is | ~MBs | Datacenter OK |
Runs on a serverless cron or Cloudflare Workers Cron Trigger unchanged.
axios.get('https://api.wallapop.com/api/v3/search') -- pure REST JSON API,
no authentication, no session state. Drop it into a 512MB Worker and it works.
|
| Vinted catalog / item lib/vinted-sniper.js | HTTP requests | Mostly portable | ~MBs | Datacenter OK (with cookie) |
The polling loop is plain axios to Vinted's catalog and item endpoints -- cheap and
serverless-friendly. The catch: Vinted requires a valid
access_token_web cookie that eventually expires.
Refreshing it requires the Puppeteer bootstrap job below. A fully serverless deployment
still needs that periodic browser job or a manually supplied cookie rotation. Hybrid: HTTP
poll in cloud, cookie refresh run locally or on a small cron VM.
|
| OfferUp lib/offerup-client.js | HTTP requests | Ports with care | ~MBs | Datacenter OK (TLS match needed) |
Uses impit -- a Rust-backed TLS fingerprint-spoofing
fetch client -- specifically to mimic a real browser's TLS ClientHello. A naive cloud port
that swaps impit.fetch() for plain
fetch() or axios will expose a Node.js TLS
fingerprint and may be blocked. The cloud port must keep
impit in the runtime. OfferUp does not require
browser DOM or a user session, so it remains light.
|
| Vinted token bootstrap lib/vinted-token-browser.js | Puppeteer | Cloud-possible (intermittent) | ~500MB (brief) | Datacenter usually OK |
puppeteer-extra + stealth, used only intermittently to mint the
access_token_web cookie for Vinted -- not for
continuous polling. Because it is a short burst job (not always-on), it can run on a small
Cloud Run instance or EC2 on a schedule without holding RAM continuously. Vinted login pages
are less aggressive about datacenter IPs than Facebook, so residential proxies are
recommended but not always mandatory.
|
| Mercari lib/mercari-client.js | Puppeteer | Cloud-possible (costly) | 500MB-1GB | Residential preferred | puppeteer-extra + stealth with headless Chromium. No per-user logged-in session required (Mercari does not require login to browse listings), which removes the cookie custody problem. However, running it always-on in the cloud costs 1 VPS-equivalent of RAM per concurrent user and benefits from residential IPs to avoid bot detection. Feasible on a medium VPS (2-4GB), but operator absorbs compute cost per user. |
| Facebook Electronics lib/facebook-sniper.js | Puppeteer | Hard -- ban-prone | 500MB-1GB | Residential / mobile required | getCachedSession() pulls a logged-in Facebook session cookie. Cloud-hosting means the operator stores each user's FB cookies server-side -- a credentials-custody liability and a Facebook Terms of Service risk. Datacenter IPs get checkpointed or banned within minutes. Operator must purchase residential/mobile proxies (3-8 USD/GB) per user and absorb that cost or pass it on. Every checkpoint requires user interaction to resolve. |
| Facebook Cars lib/fb-session.js, lib/fb-scraper.js | Puppeteer | Hard -- ban-prone | 500MB-1GB | Residential / mobile required | puppeteer.launch with --proxy-server arg and page.authenticate. Scrolls the live Marketplace feed using a real logged-in session. Same liabilities as Facebook Electronics: cookie custody, residential proxy cost, and the highest ban sensitivity of any monitor in the stack. Facebook's bot detection is tuned against exactly this pattern on datacenter IPs. Self-hosting on the user's own machine with their own login and home IP is not just acceptable -- it is the lowest-ban configuration possible. |
Source paths verified from the repository at
fbm-sniper-community/.
RAM footprints are per concurrent Chromium process, not total process memory.
Proxy requirement reflects what Facebook's bot-detection enforces in practice, not what the
application technically accepts.
Facebook's fraud and bot detection is trained on exactly this pattern: a headless Chromium on an AWS, GCP, DigitalOcean, or Hetzner IP hitting Marketplace. The checkpoint flow requires a 2FA code, a phone verification, or a CAPTCHA -- and it lands on the user's account, not a throwaway. Residential proxies (real cable/fiber IPs from a proxy provider) bypass this, but they cost 3-8 USD per GB of traffic, and that bill lands on the operator for every user running the Facebook monitors 24/7.
If the operator hosts the Facebook snipers, they must store each user's logged-in Facebook session cookies on their own server. This is a credentials custody problem: a breach, a misconfigured env var, or a logging incident exposes user Facebook accounts. It also directly conflicts with Facebook's Terms of Service. Self-hosting eliminates this entirely -- the user's cookies never leave their own machine, and the user's own IP and browser fingerprint are used. That is not a workaround; it is the correct architecture.
A plain HTTP GET or a TLS-fingerprinted fetch uses a few megabytes of RAM and finishes in milliseconds. You can run dozens of these on the cheapest VPS (Hetzner CX22 at 4-5 EUR/mo) or trigger them as AWS Lambda invocations (essentially free at low volume). They have no session to manage, no browser to boot, and no per-user state server-side. The operator could offer cloud-hosted Wallapop, Vinted, and OfferUp polling as a paid "always-on" tier for a very low per-user marginal cost.
Each concurrent headless Chromium process wants 500MB-1GB of RAM. Hosting them for N users means N * 500MB-1GB of always-on compute. A shared medium VPS (2-4GB RAM) can handle only 2-4 concurrent Facebook watchers -- and that number is per VPS, not per user with a watchlist. At any meaningful scale, the operator needs a fleet of VMs, plus a residential proxy pool, plus a cookie-storage and rotation system. The compute bill alone exceeds the subscription revenue well before the proxy costs are added.
Vinted is already a hybrid: the polling loop is cheap HTTP requests, but it periodically needs a Puppeteer browser job to refresh the session cookie. This is precisely the pattern the recommended architecture extends to the whole product -- run HTTP pollers in the cloud always-on, use a small scheduled browser job (or the user's local machine) for cookie refresh, and keep the Facebook and Mercari Puppeteer workloads on the user's device where they belong. The Vinted hybrid shows this is not theoretical: it is already built into the codebase.
impit is a Rust-backed HTTP client
that spoofs TLS ClientHello fingerprints to mimic a real browser. OfferUp's API gates on
TLS fingerprint inspection -- a standard Node.js fetch()
or axios call presents a recognizable server-side TLS fingerprint and will be blocked or
returned degraded results.
When porting OfferUp to the cloud, the impit
package must remain in the runtime. This means a Docker container (it requires a native Rust
extension) rather than a Lambda layer or a Cloudflare Worker. The overhead is still small --
a Docker container with impit and Node 18 uses under 100MB at idle -- but it rules out fully
managed serverless runtimes that cannot run native binaries.
Practically: OfferUp ports to a Cloud Run or Fly.io container job cheaply. It does not port to a plain Cloudflare Worker, AWS Lambda Node runtime, or any environment that can only run pure-JS/WASM packages.
Now you know which monitors survive the move. The next step is what to recommend.