Open Scouts: self-hosted AI monitoring built on Supabase cron and Firecrawl
🔥 AI-powered web monitoring platform. Create automated scouts that search the web and send email alerts when they find what you're looking for.
At a glance
- What is it?
- Open Scouts turns a search prompt into a scheduled scout that scrapes the web with Firecrawl, summarises results with OpenAI, and emails you through Resend. It is a Next.js 15 and Supabase application, and the setup burden is real: four third-party accounts, three Postgres extensions and two Edge Functions before the first scout runs.
- Who is it for?
- Adopt Open Scouts if you already run Supabase and are willing to hold OpenAI, Firecrawl and Resend accounts, because the dispatcher design (pg_cron calling a scout-cron Edge Function through pg_net, with secrets in supabase_vault) is the part you would otherwise have to build yourself. Do not adopt it if you need a single-tenant monitor, if you cannot verify a Resend sending domain, or if you want to avoid per-run model and scraping costs.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 116 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Open Scouts addresses: recurring web searches without a scraper pipeline
Most monitoring setups start with a cron job and a scraper, then accumulate the parts nobody wants to own: scheduling, credential storage, deduplication of results, and an email path that does not land in spam. Open Scouts packages those parts as a single application. A scout is an automated task that runs on a schedule, searches the web, and notifies you when it finds a match. The README frames the use cases broadly: new restaurants near you, AI news, or any other update you want tracked.
The intended user is someone who can run a Next.js app and a Supabase project. That is a narrower audience than the marketing phrasing suggests. The prerequisites list a Supabase account, an OpenAI API key, a Firecrawl API key, a Resend API key, and optionally a Google Cloud Console account for OAuth. Each of those is a separate signup with its own quota and billing surface. If you wanted a hosted product, the project also publishes a homepage at openscouts.firecrawl.dev, so self-hosting is a choice rather than the only path.
The value proposition is not the prompt. It is the plumbing around the prompt: scheduled dispatch, credential storage in supabase_vault, and an execution record you can inspect after the fact. Teams that already operate Supabase get that plumbing at close to zero marginal infrastructure cost. Teams that do not inherit a second platform to run.
How a scout actually runs: pg_cron, pg_net, an Edge Function and pgvector
The README describes what it calls a scalable dispatcher architecture built from pg_cron, pg_net and vault. The mechanism reads as follows. pg_cron schedules jobs inside Postgres. Those jobs fire HTTP requests outward through pg_net rather than running the agent inside the database. The target is the scout-cron Edge Function, deployed with bunx supabase functions deploy scout-cron. Credentials needed by that function live in supabase_vault, and the setup script stores your Supabase URL and service role key there automatically.
The agent itself is an Edge Function that calls the Firecrawl SDK for search and scraping and the OpenAI API for the agent loop and embeddings. Results are written back to Postgres. The README names the tables created by setup: scouts, scout_executions, scout_execution_steps, and others. Execution summaries are embedded and stored for semantic search, which is what the vector extension and pgvector are for. That means you can search past runs by meaning rather than by exact text, a feature that only becomes useful once you have accumulated a history.
Email leaves through Resend when a scout finds something. The README also mentions a second function, send-test-email, which backs the Send Test Email button in Settings. Two Edge Functions, one dispatcher chain, and a schema that records each step of each run. The design separates scheduling (Postgres) from execution (Edge Function) from notification (Resend), which is why the setup has so many moving parts and also why a stuck scout can be diagnosed at each layer independently.
Setup commands and the environment keys you have to supply
Installation is conventional. Clone the repository, enter the directory, and run bun install, npm install or pnpm install. Node.js 18 or newer is required. Then copy the example environment file with cp .env.example .env and fill in real values. The README states that .env.example contains all required variables with instructions and links for obtaining each key, so the file itself is the authoritative list rather than the README body.
Before the database script will work, you link the project: bunx supabase login once, then bunx supabase link --project-ref <your-project-ref>, where the ref comes from the Supabase Dashboard URL. The main step is bun run setup:db. According to the README it creates the tables, adds user_id columns and Row Level Security, enables real-time subscriptions, sets up vector embeddings, configures the dispatcher, stores the Supabase URL and service role key in the vault, installs cron jobs for dispatching and cleanup, and syncs Edge Function secrets from .env. The secrets synced are OPENAI_API_KEY, FIRECRAWL_API_KEY and RESEND_API_KEY.
Extensions must be enabled manually in the Supabase Dashboard under Database, Extensions: pg_cron, pg_net, vector, and supabase_vault, which the README notes is usually on by default. The setup script checks for vector, pg_cron and pg_net and stops with on-screen instructions if any are missing, so a failed first run is expected rather than exceptional. Secrets can also be set one at a time, for example bunx supabase secrets set OPENAI_API_KEY=sk-proj-... or the same command with RESEND_API_KEY=re_....
One configuration decision stands out. The README states plainly that you do not need a Firecrawl API key in your environment variables. Each user enters their own key in the Settings page under the Firecrawl Integration section, and usage is billed to that user's Firecrawl account. A server-side key is described as optional and for self-hosting. That inverts the usual model: the operator supplies OpenAI and Resend, while scraping cost is pushed to each end user.
Where the setup breaks: Resend domain verification and the free tier ceiling
The most concrete limitation in the README concerns email. Without a verified domain, Resend only sends to the Resend account email. So a fresh install can test itself and nothing else. The Send Test Email button in Settings will confirm the configuration, and that confirmation is misleading if you have not verified a domain at resend.com/domains, because the test recipient is the one address that always works. The free tier is documented as 3,000 emails per month with a 100 per day limit. A scout that runs frequently and finds something each time will hit the daily ceiling before the monthly one.
There is a second failure mode implied by the architecture. Dispatch depends on pg_cron and pg_net inside your Supabase project, and execution depends on an Edge Function that reaches OpenAI and Firecrawl. If any link in that chain is misconfigured, the symptom is silence. The README does not describe an alerting path for failed runs, so the scout_executions and scout_execution_steps tables are where you would look. Nothing in the supplied material describes retry behaviour, rate limiting, or what happens when OpenAI or Firecrawl returns an error mid-run.
The licence is listed as unknown. That is not a detail to skip. Without a stated licence, the terms under which you may deploy, modify or redistribute the code are not established by the material available, and no amount of reading the README resolves it. Check the repository directly before building anything you intend to keep. Nothing here is legal advice; it is a reason to look.
Open Scouts against a plain cron script with the Firecrawl SDK
The obvious alternative is a scheduled script that calls the Firecrawl SDK, pipes the output to the OpenAI API, and sends mail through Resend or SMTP. That approach is smaller, has one deployment target, and does not require a Supabase project or any Postgres extensions. It also has no user model, no per-user API keys, no execution history you can query semantically, and no vault for credentials. You would keep secrets in environment variables on whatever host runs the cron job.
The difference in approach is where scheduling lives. Open Scouts puts the clock inside the database, which means the schedule, the credential store and the execution records share one system and one backup. The plain script puts the clock in the host's scheduler, which means the schedule is invisible to the data it produces. For a single monitor run by one person, the script wins on simplicity. For multiple users each with their own scouts and their own Firecrawl keys, the database-resident scheduler is the reason the project exists, because it gives every user a row-level-secured slice of the same pipeline.
A second comparison point is the notification channel. Open Scouts is email-only in the material provided. If your team lives in a chat tool, you would be adding a channel the project does not describe, which means writing or deploying another Edge Function. A plain script could post to a webhook in a few lines. That is a real gap, not a preference.
Maintenance cost and what upgrading involves
The stack is broad and each piece moves. Next.js 15, React 19, Tailwind CSS v4, the Firecrawl SDK, the OpenAI API, Resend, and Supabase with three extensions. Upgrading means tracking all of them, and the ones that matter most are the least visible: a change to the Firecrawl SDK's search interface or the OpenAI API's model names will surface inside an Edge Function where you cannot easily attach a debugger. The README does not describe a migration path or a schema versioning scheme for setup:db, so re-running it against an existing project is the only documented update mechanism.
Operationally, the recurring costs are per-run rather than per-seat. Every scout execution consumes OpenAI tokens and Firecrawl credits, and every notification consumes Resend quota. The README's decision to have each user bring a Firecrawl key means the operator does not absorb scraping cost, but it also means the operator cannot cap it. There is no described budget control, so a scout with a broad prompt and a short interval is the expensive configuration and nothing in the material stops it.
On licence, the material gives no identifier. Deployment terms, redistribution rights and any obligation to publish modifications all depend on a file the supplied information does not include. That is the first thing to check, ahead of any technical evaluation.
Editorial conclusion
Adopt Open Scouts if you already run Supabase and are willing to hold OpenAI, Firecrawl and Resend accounts, because the dispatcher design (pg_cron calling a scout-cron Edge Function through pg_net, with secrets in supabase_vault) is the part you would otherwise have to build yourself. Do not adopt it if you need a single-tenant monitor, if you cannot verify a Resend sending domain, or if you want to avoid per-run model and scraping costs. Before committing, check the repository licence, confirm the pg_cron, pg_net and vector extensions are available on your Supabase plan, and run bun run setup:db once to see whether the script's extension checks pass on your project.
Community notes