TeireDocs
ChangesScanDashboardTry Teire
GuideEcosystems & APIsNemotron on Token FactoryBuild
ChangesScanDashboard
Try Teire
ArchitectureHow Teire updates dependency filesVerificationToken Factory SandboxesSecurity and trustContributing to the catalog

Tools

CLIMCP serverAgent Skill
Build

Architecture

A Next.js app on Vercel, a worker and Postgres on Coolify, sandboxes on Cloudflare Containers, and Nemotron on Nebius Token Factory, joined by a Postgres outbox.

Events in
Events in. System: developers install the GitHub App and use the web app; GitHub webhooks reach the web app, which writes to a Postgres outbox; the worker claims them, reads registries, provider pages and Tavily, calls Nemotron on Token Factory, verifies in Cloudflare Containers, and writes branches, PRs, check runs and issues back to GitHub.
  1. GitHubwebhooks
  2. push · install
  3. Web appVercel
  4. outbox + NOTIFY
  5. Postgresoutbox · Coolify
  6. claimed
  7. WorkerCoolify
A run
A run. System: developers install the GitHub App and use the web app; GitHub webhooks reach the web app, which writes to a Postgres outbox; the worker claims them, reads registries, provider pages and Tavily, calls Nemotron on Token Factory, verifies in Cloudflare Containers, and writes branches, PRs, check runs and issues back to GitHub.
  1. Worker
  2. quotes
  3. Change pagesregistries · OSV · Tavily
  4. fix
  5. Nemotron 3 UltraToken Factory
  6. upgrade
  7. dependabot-coregVisor
  8. checks
  9. SandboxesToken Factory · Cloudflare
  10. PR
  11. Pull requestcheck run · issue
You
You. System: developers install the GitHub App and use the web app; GitHub webhooks reach the web app, which writes to a Postgres outbox; the worker claims them, reads registries, provider pages and Tavily, calls Nemotron on Token Factory, verifies in Cloudflare Containers, and writes branches, PRs, check runs and issues back to GitHub.
  1. Youinstall the App
  2. sign in
  3. Dashboardscan · catalog · docs
  4. the public catalog
  5. CLI and MCPcoding agents
Every part of Teire and every outside service it calls.
PartRuns onDoes
Web appNext.js 16 on VercelThe landing page, sign-in, the dashboard, public scans and reports, run pages, the change catalog, these docs, and the GitHub webhook endpoint
WorkerNode 24 on CoolifyWebhooks, scans, fix runs, commands, the Dashboard issue, and the reliability ticker
PostgresCoolifyFindings, runs, events, receipts, the catalog, sessions, the outbox, and the job queues
SandboxCloudflare ContainersInstalls and checks, one isolated container per side of a run
ModelsNebius Token FactoryNVIDIA Nemotron 3 Ultra, with Super as failover
SearchTavilyFinding the notices of a provider that has no reader

From GitHub to the worker

From GitHub to the worker. From GitHub to the worker: GitHub sends a signed delivery to the webhook route, which checks the signature, stores it once in the Postgres outbox by delivery ID and answers 202; the worker, woken by pg_notify or its 5-second poll, claims up to 10, queues scans and runs on pg-boss one job per repository in order, and stores any failure on the scan or run.
  1. GitHubsigned
  2. POST
  3. Webhookanswers 202
  4. by ID
  5. Outboxstored once
  6. NOTIFY
  7. Workerclaims 10
  8. pg-boss
  9. Queuesone per repo

POST /api/github/webhooks checks the X-Hub-Signature-256 signature. It stores the delivery once, keyed by GitHub's delivery ID, so a redelivery is a no-op. It wakes the worker with pg_notify, then answers 202.

The worker listens for that notification and also polls every 5 seconds. It claims up to 10 deliveries at a time (FOR UPDATE SKIP LOCKED). A claim older than 5 minutes is taken again, and a delivery that fails 5 times is set aside with its error.

Scans and fix runs go onto pg-boss queues in the same database. Each queue runs one job at a time per repository, in order, so two scans or two fix runs never race on one repository. Handlers never throw: a failure is stored on the scan or run, and the next job proceeds.

The web app's own requests travel the same outbox as synthetic events: public scans, dry runs and the dashboard's buttons. So the web app never calls the worker directly.

Reliability

A ticker runs every 60 seconds. It:

  • writes the worker's heartbeat,
  • fails runs whose heartbeat stopped for 10 minutes (runs beat every 15 seconds) and scans silent for 10 minutes (scans beat every minute),
  • publishes which models are healthy,
  • re-checks Token Factory credits every 15 minutes,
  • starts scheduled rescans (schedule: daily | weekly),
  • every 10 minutes, asks GitHub for failed webhook deliveries from the last 6 hours and redelivers the ones it never stored.

The trust page shows all of it live.

Public endpoints

EndpointReturns
GET /api/catalog/changesEvery public, confirmed change, filterable by provider, ecosystem, kind and subject
GET /api/catalog/changes/<id>One change record
GET /api/catalog/providersEvery provider Teire can read, with its pages and SDKs
GET /api/runs/<id>/sheet?after=<seq>A run as its page shows it (status, evidence, checks, receipts) with the events after seq: the feed behind the live run page. Public repositories' runs are open to anyone; private ones to people with access to the installation
GET /schema.jsonThe JSON Schema of teire.yml
GET /llms.txt, /llms-full.txtThese docs as plain text for language models

The CLI reads the catalog endpoints; they need no key.

Source

github.com/teire-dev/teire is a pnpm and Turborepo monorepo:

The engine holds everything that reads, diffs, locates, fixes and verifies. The worker, the CLI and the MCP server all call it the same way.

How Teire updates dependency files

The manifest and lockfile change comes from Dependabot's own updater, run in an isolated sandbox on Teire's server; Teire's loop of locating, fixing and verifying the code sits on top.

On this page

From GitHub to the workerReliabilityPublic endpointsSource