Integration catalog

Choose the standalone adapters, local runtimes, exporters, hosts, and deployment engines your application needs.

An integration connects a RELKIT capability to a provider, such as S3 for files or Redis for cached values. Services, functions, routes, and events depend on checked capability contracts; integrations connect those contracts to Redis, S3, telemetry exporters, local Docker services, and deployment platforms.

Pre-setup

Start with a working minimal app and Docker. Install the owner of each selected adapter, then bind it in relkit.config.ts through defineApp. Use docker(adapter()) when it has a local recipe; the wrapper supplies development connection values. Follow the module’s setup before adding its first resource:

Buckets and MinIO

Cache and Redis

Realtime and Redis

Native task providers

PostgreSQL and auth

Agent state

Named connection bindings such as binding.secret(...) select provider values; defineEnv declares application values available to functions. Keep the distinction when configuring environment contracts. Run bun run check before bun run dev; a package installation alone creates no profile or running resource. The Docker coverage table identifies providers without a recipe.

Choose packages by role

Package	Role	Continue with
`@relkit/redis`	Redis cache adapter and pinned local recipe	Caching
`@relkit/s3`	S3-compatible bucket adapter and pinned MinIO recipe	Storage
`@relkit/sentry`	Error telemetry exporter	Observability
`@relkit/otlp`	OTLP trace exporter	Observability
`@relkit/docker`	Local-recipe selector and Docker materializer	Local Docker
`@relkit/local`	Filesystem event/job, realtime and agent-state profiles; local lifecycle support	Local providers
`@relkit/aws`	AWS host, infrastructure ownership, and access materialization	AWS deployment
`@relkit/pulumi`	Pulumi deployment engine	Deployment
`@relkit/cloudflare`	R2/KV runtime adapters; no application host	Connected providers
`@relkit/inngest`	Native durable-task adapter and account-free Docker recipe	Jobs
`@relkit/trigger`	Trigger.dev task adapter and worker publication	Jobs
`@relkit/effect-mq`	PostgreSQL-backed retryable task adapter	Jobs
`@relkit/drizzle`	Optional database integration and selected native ORM	Database installation
`@relkit/better-auth`	Optional auth bridge; native SDK and React leaf selected separately	Auth installation
`@relkit/langchain`	Optional native agent engine and selected SDK cohort	Agent installation
`@relkit/inspector`	Separately installed UI and history tool	Inspector setup

Install standalone packages when you want the smallest dependency surface:

For Docker Redis, the selected recipe is:

From this guide’s application/package root, install only its selected requirements:

bun add @relkit/docker@0.7.12 @relkit/redis@0.8.1

Keep these owner-specific versions and the lockfile together. Runtime SDKs belong in dependencies; build/type tooling belongs in devDependencies. Installing an adapter does not supply its optional SDK peers or enable the feature’s configuration.

For connected Cloudflare KV/R2 instead, install its owner and supply that adapter’s named connection values. This does not select AWS/Pulumi or a Docker recipe:

From this guide’s application/package root, install only its selected requirements:

bun add @relkit/cloudflare@0.7.12

The optional @relkit/integrations catalog contains package metadata and installs no adapters. Import executable capabilities directly from the selected standalone packages. The following source illustrates separate choices; install only the owners you actually import, using their linked setup:

/** Demonstrates a Redis cache selected through its standalone Docker integration. */
import { defineApp, defineEnv } from "@relkit/app/config";
import { docker } from "@relkit/docker";
import { redis } from "@relkit/redis";

export default defineApp({
  env: defineEnv({}),
  cache: docker(redis()),
});

Native agents use @relkit/langchain together with its documented LangChain SDK requirements. Install the model provider package selected by your application directly.

Understand ownership

Connected adapters wire a resource that already exists. docker(adapter) selects the adapter’s local recipe for development only. Infrastructure wrappers such as aws(adapter) let the deployment stack own a resource. The deployment engine and host are separate roles, so selecting AWS hosting does not claim every connected Redis, S3-compatible, Cloudflare, or model resource.

Run bun run check to validate package registration, source wrappers, profile selection, and deployment-role compatibility before starting a runtime or previewing infrastructure.

Declare authoring entrypoints

If you are implementing an adapter, begin with Provider authoring for a maintained example and validation steps. Use Local providers when explicitly owning local runtime state.

Integration package authors list their application authoring entrypoints in package.json under relkit.integration.exports.authoring. Use a string for one exact export, such as ".", or an explicit list when multiple authoring leaves are public:

{ "authoring": [".", "./sqlite", "./pg", "./mysql"] }

Every listed leaf must also exist in the package’s exports map. The compiler accepts only those exact imports; listing a parent does not permit its children. Wildcards and path traversal are rejected. Drizzle declares its three dialect model entrypoints, and Better Auth declares its root and ./drizzle bridge. Runtime internals, React adapters, and testing helpers do not become application authoring entrypoints through this declaration.

Reference and source