Repo shows Trigger.dev built its own billing-limits/enforcement layer on top of a bought meter
The open-source webapp imports a BillingClient from a first-party "@trigger.dev/platform" package whose source is nowhere in the public monorepo, rather than wiring Stripe/OpenMeter SDKs directly, and ships a first-party billing-limits & alerts system (grace periods, queue pause, cancel-in-progress runs) documented at trigger.dev/docs/billing-limits -- refining the build-vs-buy read from pure buy to buy-the-meter, build-the-guardrails.
Trigger.dev’s public OSS repository (triggerdotdev/trigger.dev) shows apps/webapp/app/services/platform.v3.server.ts importing a BillingClient and billing/entitlement types (Limits, UsageResult, CurrentPlan, BillingAlertsResult, EntitlementResult) from "@trigger.dev/platform" — a package that is declared as an ordinary versioned dependency ("@trigger.dev/platform": "1.3.1") and is not defined anywhere in the public monorepo. It is published on npm under Trigger.dev’s own scope as compiled output only, described by its maintainers as “Used to communicate with the Trigger.dev platform. This is not a package you should use directly.” The client is instantiated only if (isCloud() && process.env.BILLING_API_URL && process.env.BILLING_API_KEY), confirming billing is wired through a first-party, non-open-source API rather than Stripe/OpenMeter SDKs called directly from the OSS code (commit 9944f44, 2026-09-08). No package in the repo declares a Stripe or OpenMeter dependency.
On top of that client, the repo carries a substantial first-party “billing limit” subsystem (apps/webapp/app/v3/services/billingLimit/*: reconciliation, environment convergence, bulk-cancel, grace-period resolve, with a handler documented as processing “billing limit grace hit from the billing platform webhook”) and a public docs page, Billing limits and alerts, describing a self-serve monthly compute spend cap with email alert thresholds. When a limit is hit, “billable environments enter a grace period”: queues pause across production/staging/preview, in-progress runs finish naturally unless the organization has opted in to “Cancel in-progress runs”, and organizations get 24 hours to resolve before queued runs are canceled and new triggers rejected for the rest of the billing cycle.
This does not overturn the previously-confirmed vendor layer — CEO Matt Aitken’s own account (openmeter.io case study) still stands as the source for OpenMeter (per-millisecond compute metering, entitlements) syncing to Stripe for payments. But it corrects the prior read that the OSS repo “carries the durable-execution runtime, not the cloud billing system”: the billing API itself stays outside the repo, yet a real chunk of the billing enforcement logic — spend caps, grace periods, queue pause/resume, cancellation — is built and owned in-house, in the open.
Included concurrent Realtime connections increased from 50 to 150 on Hobby and from 500+ to 1,000+ on Pro. Plan prices ($0 / $10 / $50), the per-second compute table and the $0.000025 per-run invocation fee were unchanged, and Pro's overage rate held at $10/mo per additional 1,000 connections — so the effective cost per included connection fell by about half on Pro and two-thirds on Hobby.