Server sources

Server sources accept HTTP requests containing walkerOS events and forward them to the collector. Choose based on your deployment environment.

Available sources

Source	Platform	Use Case
Express	Node.js	Standalone server or existing Express app
Fetch	Edge/Serverless	Cloudflare Workers, Vercel Edge, Deno, Bun
AWS Lambda	AWS	API Gateway, Lambda Function URLs
GCP Cloud Functions	Google Cloud	Cloud Functions HTTP triggers
AWS SQS	AWS	Queue consumer, decoupled ingestion
Google Pub/Sub	Google Cloud	Pull subscriber or push webhook

Choosing a source

Express - Best for traditional Node.js deployments, Docker containers, or when you need full control over the HTTP server.

Fetch - Best for edge computing and serverless platforms that support the Web Standard Fetch API.

AWS Lambda - Best for AWS-native deployments with API Gateway or Lambda Function URLs.

GCP Cloud Functions - Best for Google Cloud deployments using Cloud Functions.

Common features

Server sources come in two shapes, and the shared features differ by shape.

HTTP sources (Express, Fetch, AWS Lambda, GCP Cloud Functions) receive inbound requests and all provide:

• JSON event ingestion (POST), with one shared event envelope
• Pixel tracking (GET with 1x1 GIF response)
• CORS support (configurable)
• Health checks (liveness/readiness endpoints)
• One shared request scope, so a config.ingest mapping resolves the same on each of them

Queue consumers (AWS SQS, Google Pub/Sub pull) read from a queue instead of serving requests. They have no HTTP surface, so none of the request-shaped features above apply, and config.ingest does not either: there is no request to adapt. Retries and dead-lettering stay with the queue.