Skip to main content

By the end of this tutorial you’ll have a Next.js 15 app where two end users each authenticate via OIDC, run AI inference calls against the Livepeer Network, and accumulate usage on per-user ledgers visible in a dashboard. The infrastructure layer is , a community-built backend that combines OpenID Connect identity, multi-tenant billing plans, and remote payment-ticket signing. You write the app; pymthouse handles the three things that turn a single-user demo into a multi-tenant product. This is the Persona 2 activation moment for SaaS. The VOD and live-streaming tutorials proved your app can call Livepeer; this one proves your customers can call Livepeer through your app and you can bill them for it.
pymthouse is a community project by John (@eliteprox) in active beta, not an official Livepeer Foundation product. Verify compatibility with the current go-livepeer release before production deployment. The hosted service is free during beta.

Required Tools

  • Node.js 20 or later
  • A pymthouse account at (hosted, free during beta) or a self-hosted instance
  • A Livepeer Gateway accessible through pymthouse’s signer
  • A code editor
Self-hosting pymthouse adds a Postgres database, the Next.js app, and a go-livepeer signer sidecar. Full deployment instructions live in the pymthouse repository at . The tutorial below uses the hosted path for the shortest time-to-running.

Pymthouse Responsibilities

Three infrastructure problems sit between a single-user Livepeer demo and a multi-tenant product. Pymthouse solves all three. The runtime flow for a user-initiated inference call:
Your app exchanges its confidential client credentials for a user-scoped token, sends the inference request through pymthouse, and pymthouse handles ticket signing and usage recording transparently.

Pymthouse Setup

1

Register your app

Create an account at . In the dashboard, register a new application; pymthouse issues a clientId and clientSecret for confidential-client authentication.
2

Configure a billing plan

In the app settings, pick a billing plan type. Three plan types ship in beta:The tutorial below uses usage-based. Each AI call deducts the wei cost from the user’s ledger; the dashboard shows running totals.
3

Capture the OIDC discovery URL

Pymthouse exposes a standard OIDC discovery document at /.well-known/openid-configuration. The dashboard shows the discovery URL for your app. Use the discovery URL in production integrations to avoid path drift between pymthouse versions.

Project Bootstrap

1

Create the project

2

Configure environment

Save as .env.local:
Both credentials stay server-side. The browser never sees the client secret.

User Provisioning

End users live in pymthouse’s user registry, scoped to your application’s clientId. The Builder API at /api/v1/apps/{clientId}/users provisions and manages them. Save as src/lib/pymthouse.ts:
The admin token (client_credentials grant) is your app authenticating to pymthouse. The user token (RFC 8693 token exchange) is one of your end users authenticating through your app’s namespace. Cache the admin token in memory; mint user tokens per request.

Inference Endpoint

The route handler takes a user identifier from your app’s session, mints a short-lived user token through pymthouse, and forwards the inference request. Pymthouse handles ticket signing and usage recording before returning the result. Save as src/app/api/inference/route.ts:
Two things differ from a direct Livepeer call. First, the request goes to pymthouse’s inference endpoint, not directly to the Livepeer Gateway; pymthouse forwards after signing. Second, the bearer token is the user-scoped pymthouse token, not a static Gateway API key. The token tells pymthouse who to bill.

Usage Dashboard

The Usage API at /api/v1/apps/{clientId}/usage returns per-user usage data, tenant-scoped to your app. Pymthouse denominates monetary values in wei to match Livepeer’s on-chain payment unit; parse with a BigInt-capable library to avoid floating-point precision loss. Save as src/app/api/usage/route.ts:
Render the dashboard as a server component:
The total_eth value is derived from the wei-denominated source; precision degrades past 8 decimals because of JavaScript number conversion. For exact billing display, keep the value in wei and format with a BigInt-aware decimal library.

Production Considerations

Five things change between this local setup and a production deployment. OIDC discovery in production. Hardcoded paths break across pymthouse versions. Production code fetches /.well-known/openid-configuration once on app start and uses the URLs from the discovery document for all subsequent calls. Token caching across instances. The admin token cache in lib/pymthouse.ts is per-process. In a multi-instance deployment, share the cache via Redis or accept the small overhead of one token fetch per instance per token lifetime. User token short-livedness. User tokens default to short expiries (typically under an hour). Don’t store them; mint per request. Caching tokens longer than their TTL produces silent 401 failures. Wei precision. Every monetary number from pymthouse is wei (1e-18 ETH). Floating-point conversion loses precision past 15-16 digits. Keep all internal accounting in wei; convert to display units only at the UI layer. Self-hosting trade-off. Hosted pymthouse during beta is free but constrains you to their infrastructure. Self-hosting takes ownership of three additional services (Next.js app, Postgres, signer sidecar) but removes the dependency. The repository at includes deployment recipes for Vercel + Railway, Vercel + Render, and Vercel + Fly.io. Full hardening guidance in .

Common Errors

The clientId and clientSecret don’t match a registered application. Confirm them in the pymthouse dashboard. If the client was recently rotated, restart your app to flush the cached admin token.
The user provisioning step failed silently, or the user belongs to a different clientId namespace. Confirm external_id is consistent across calls; pymthouse uses it as the idempotency key.
The billing plan rejected the call. For usage-based plans, check the per-user ledger has sufficient balance or that the plan limits haven’t tripped. Pymthouse’s dashboard shows per-user balance and plan status.
Wei-to-ETH conversion lost precision through floating-point arithmetic. Format with a BigInt-aware decimal library at the display layer; never store the lossy value as the source of truth.
Production code that hardcoded /api/v1/oidc/token breaks when paths move. Switch to discovery-based URL resolution: fetch /.well-known/openid-configuration once on app start and use the URLs from there.
You have a working multi-tenant app with per-user billing backed by pymthouse’s OIDC identity and usage ledger. The same pattern extends beyond AI inference to any Livepeer pipeline type.

AI agent prompt

Next Steps

Pymthouse Docs

Full integration documentation, deployment recipes, troubleshooting.

Pymthouse Repo

Source, self-hosting deployment files, contribution guide.

AI Jobs Quickstart

The direct-to-Gateway path, for comparison.

Production Hardening

Auth, observability, rate limits, secret management.
Last modified on May 31, 2026