Foam will be at DASH in NYC, June 9–10. Book a chat with us ›
Docs
Set up

Just connect your repo

Let us take it from there. Connect your GitHub repo during signup and Foam looks at your framework, runtime, and package manager, then opens a PR with the setup for your stack.

What's in the PR

One dependency and one init call. Nothing else in your codebase changes. Here's what it looks like for common stacks:

Node.js (Express, NestJS, or plain)

// package.json
+ "@foam-ai/node": "^0.1.0"
 
// index.ts (or your entry point)
+ import { foam } from '@foam-ai/node'
+ foam.init({ apiKey: process.env.FOAM_API_KEY })

That single init call gives Foam everything it needs to monitor your service. It captures your console.* output as structured logs (so Foam can search them during investigations), records uncaught exceptions and unhandled rejections (so nothing fails silently), and optionally instruments your HTTP calls, Express routes, and database queries (so Foam can trace requests across services and spot where things slow down or break).

Next.js on Vercel

// package.json
+ "@vercel/otel": "^1.0.0"
+ "@foam-ai/vercel-otel": "^0.4.5"
 
// instrumentation.ts
+ import { registerOTel } from '@vercel/otel'
+ import { foamConfig } from '@foam-ai/vercel-otel'
+ registerOTel(foamConfig())

Vercel has a built-in OpenTelemetry hook for Next.js apps. Foam plugs into it directly. No custom server, no extra infrastructure. This gives Foam visibility into your serverless functions, API routes, and server-side rendering so it can trace failures across your Next.js app the same way it does for any other service.

Browser apps

// package.json
+ "@foam-ai/browser": "^0.1.0"
 
// app entry
+ import { foam } from '@foam-ai/browser'
+ foam.init({ apiKey: process.env.FOAM_API_KEY })

Many production issues surface in the browser before they show up in your backend: a slow API call, a failed fetch, a layout shift. The browser SDK captures page loads, route transitions, Web Vitals (LCP, FID, CLS, INP), and every network request. It also links browser traces to your backend traces, so when a user hits an error, Foam can follow the request from the browser all the way through your server stack.

Ruby on Rails

# Gemfile
+ gem 'foam-ruby'
 
# config/initializers/foam.rb
+ Foam.init(api_key: ENV['FOAM_API_KEY'])

Instruments your Rails controllers, routing, Active Record queries, Action Pack/View/Mailer, Active Job workers, and Rack middleware. This means Foam sees every request your Rails app handles, every database query it runs, and every background job it processes, all connected so a failure in a job can be traced back to the request that triggered it.

What happens after you merge

Your app starts sending traces, logs, and metrics to Foam on the next deploy. From that point, Foam is listening. When it detects something worth investigating, it runs root cause analysis across your services, including services that aren't in the original error, and pings the right person in Slack with the full report.

Once your account is created, head to foam.ai/status to confirm your telemetry is flowing. The status page shows live traces, logs, and metrics arriving from each of your services.