Skip to main content
Plugins are Genkit’s primary extension mechanism. They add new capabilities like model providers, telemetry backends, vector stores, and custom actions.

What are Plugins?

A plugin extends Genkit by registering new actions (models, tools, retrievers, etc.) and providing configuration for external services. Plugins can:
  • Provide AI models: Gemini, Claude, GPT, Llama, etc.
  • Add telemetry: Cloud Trace, Datadog, Sentry, etc.
  • Enable vector search: Pinecone, Chroma, Vertex AI Vector Search
  • Add safety checks: Content filtering, PII detection
  • Integrate frameworks: Express, Flask, FastAPI
  • Register custom tools: Any function you want models to call

Using Plugins

Plugin Architecture

All plugins implement the same interface:

Plugin Lifecycle

Plugins follow a four-phase lifecycle:

1. Registration

Plugins are registered when you create a Genkit instance:

2. Lazy Initialization

Plugins are initialized only when first used:
On first use:
  1. Registry calls plugin.init()
  2. Plugin returns pre-registered actions
  3. Actions are cached in registry
  4. Subsequent calls use cached actions (no re-init)

3. Action Resolution

When you reference an action by name:
Resolution flow:
  1. Check cache - already resolved?
  2. If namespaced (googleai/...), find that plugin
  3. Call plugin.resolve(ActionKind.MODEL, 'googleai/gemini-2.0-flash')
  4. Cache and return the action

4. Action Discovery

The Developer UI queries plugins without initializing them:

Official Plugins

Model Providers

Telemetry & Observability

Vector Stores

Safety & Evaluation

Framework Integration

Community Plugins

Community-maintained plugins (best-effort support):
  • Amazon Bedrock: Claude, Llama, Titan + AWS X-Ray telemetry
  • Azure AI: Azure Monitor telemetry
  • Cloudflare Workers AI: Edge AI models + OTLP telemetry
  • Cohere: Command models + reranking
  • HuggingFace: Inference API models
  • Microsoft Foundry: Azure AI Foundry (11,000+ models)

Plugin Configuration

Most plugins accept configuration options:

Environment Variables

Most plugins support environment variable configuration:

Creating Custom Plugins

Basic Plugin

Create a custom plugin to add your own models or tools:

Plugin with Multiple Action Types

Plugin Namespaces

Each plugin has a namespace that prefixes its actions:
Examples:
  • googleai/gemini-2.0-flash - plugin: googleai, model: gemini-2.0-flash
  • anthropic/claude-3-5-sonnet - plugin: anthropic, model: claude-3-5-sonnet
  • myplugin/my-model - plugin: myplugin, model: my-model
Namespaces prevent conflicts between plugins that might have similarly named actions.

Plugin Discovery

The Developer UI uses list_actions() to discover available actions:
Important:
  • list_actions() must be fast - no expensive operations
  • Does NOT trigger init() - plugins remain uninitialized
  • Only returns metadata, not full action objects

Dynamic Action Providers

For actions that are discovered at runtime (like MCP servers):

Combining Multiple Plugins

Use multiple plugins together:

Plugin Best Practices

1. Lazy Initialization

Defer expensive operations to init(), not __init__():

2. Fast Action Listing

list_actions() must be fast - no API calls:

3. Graceful Degradation

Handle missing API keys gracefully:

4. Clear Error Messages

Provide helpful errors when things go wrong:

Example: Complete Custom Plugin

A complete weather plugin:

Next Steps