Docs
SDKs
Why we built them
Setting up OpenTelemetry properly is not trivial. You need to configure exporters, wire up auto-instrumentation for your framework, make sure logs and traces are correlated, handle sourcemaps, propagate context across service boundaries. At larger companies, a platform team handles this. At a startup, it falls on whoever has time, which usually means it doesn't happen at all.
That's the gap Foam's SDKs close. A single init call gives a five-person startup the same depth of telemetry that a company with a dedicated observability team gets. No OTel expertise required. No week-long setup project. The SDK handles the wiring so your engineers can stay focused on the product.
What they are
Every Foam SDK is a thin wrapper around OpenTelemetry. Under the hood, it's setting up standard OTel exporters pointed at Foam's endpoint. A typical Node.js initialization looks like:
// instrumentation.ts — loaded before your app code
import { foam } from '@foam-ai/node'
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node'
foam.init({
apiKey: process.env.FOAM_API_KEY,
serviceName: 'checkout-api',
environment: process.env.NODE_ENV,
instrumentations: [
getNodeAutoInstrumentations({
'@opentelemetry/instrumentation-fs': { enabled: false },
}),
],
})That's the whole integration. No background daemon, no proprietary runtime, no monkey-patching beyond standard OTel auto-instrumentation. Source is on github.com/foam-ai.
Don't see your stack below? We ship new packages within 72 hours. Let us know →
First-party SDKs
@foam-ai/nodeNode.js servers
Single foam.init() at app entry. Wires up OTLP traces, logs, and metrics; patches console.* to OTel logs; captures uncaught exceptions and unhandled rejections. Pass getNodeAutoInstrumentations() to opt into HTTP, Express, and database-driver instrumentations.
npm install @foam-ai/node@alpha
import { foam } from '@foam-ai/node'
foam.init({
apiKey: process.env.FOAM_API_KEY,
})@foam-ai/browserBrowser apps
Drop-in foam.init() that captures page loads, route transitions, Web Vitals (LCP, FID, CLS, INP), XHR / Fetch, and resource loading. Propagates trace context to your backend so client and server traces stitch together.
npm install @foam-ai/browser
import { foam } from '@foam-ai/browser'
foam.init({
apiKey: process.env.FOAM_API_KEY,
})@foam-ai/vercel-otelNext.js on Vercel
Returns a registerOTel-compatible config object pre-wired for Foam: trace exporter, log processor, and optional metric reader. Spread into @vercel/otel's registerOTel call in your instrumentation.ts hook.
npm install @vercel/otel @foam-ai/vercel-otel
// instrumentation.ts
import { registerOTel } from '@vercel/otel'
import { foamConfig } from '@foam-ai/vercel-otel'
registerOTel(foamConfig())foam-rubyRuby on Rails
Initializer-based setup; exports via OTLP. Auto-instruments Rails controllers & routing, Active Record, Action Pack / View / Mailer, Active Job, and Rack middleware.
gem 'foam-ruby'
# config/initializers/foam.rb Foam.init(api_key: ENV['FOAM_API_KEY'])
@foam-ai/nextbuild-timeNext.js sourcemap upload
Build-time plugin that generates, uploads, and cleans up production sourcemaps during `next build`. Pair with @foam-ai/vercel-otel or @foam-ai/node to get readable stack traces in production traces. Sourcemaps are uploaded to Foam during build and deleted from your build output — they never ship to the browser.
npm install --save-dev @foam-ai/next
Any other language
Foam works with any language that has an OpenTelemetry SDK: Python, Go, Rust, Java, .NET, Elixir, PHP, and more. Point the OTLP exporter at Foam's endpoint:
OTEL_EXPORTER_OTLP_ENDPOINT=https://otel.api.foam.ai OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer <YOUR_API_KEY>
No Foam-specific package needed. Standard OTel is all it takes.
If you'd like a dedicated Foam SDK for your stack, let us know. We ship new packages within 72 hours.