Registry
Server modules
The rules for custom asset storage, email, and AI provider modules that a registry loads.
Asset storage, email, and AI connections can each name a custom server module: a file in your project that the registry build copies into the bundle and loads on the server.
| Module for | Config | Define helper |
|---|---|---|
| Asset storage | runtime.registry.assetStorage.module | defineStorageProvider |
runtime.registry.email.module | defineEmailProvider | |
| AI connection | runtime.ai.connections[].module | defineAiProvider |
Rules
- The path is relative to the working directory.
- The file is
.jsor.mjs. - The default export is the provider object, or a factory that returns it.
- The module imports its define helper from
handoff-app/providers. The registry build stops when a module importshandoff-appitself. - The project installs the packages the module imports. The registry build copies them into the bundle.
- The build bakes the list of modules. Adding or changing a module needs a rebuild.
Factory context
A factory gets options, with each fromEnv() value resolved at request time. An AI provider
factory also gets apiKey: the deployment key or the reader's own key.
import { createAnthropic } from '@ai-sdk/anthropic'
import { defineAiProvider } from 'handoff-app/providers'
export default defineAiProvider(({ apiKey }) => createAnthropic({ apiKey }))See Asset storage, Email, and AI assistant for full examples.