Skip to main content

Plugin System

The Ever Works Platform uses a capability-driven plugin architecture where all external integrations — AI providers, search engines, deployment targets, screenshot services, and more — are implemented as self-contained plugins.

Instead of hardcoding providers, the platform asks "give me a plugin that can do X" and the system resolves which plugin to use based on admin, user, and work-level configuration.

How It Works​

  1. Plugins declare capabilities — Each plugin implements one or more capability interfaces (e.g., ai-provider, search, deployment).
  2. Facades route requests — When the platform needs to perform an AI completion or a web search, a facade service resolves the active plugin for the current scope.
  3. Settings cascade — Plugin configuration follows a three-tier hierarchy: work settings override user settings, which override admin defaults.
  4. Discovery is automatic — Plugins in packages/plugins/ are discovered at startup. No manual registration is needed.

Built-in Plugins​

The platform ships with 102 plugins. That number is the directory count of the plugin workspace: ls packages/plugins returns 103 entries, one of which is the workspace README.md, so the plugin total is 102. Each directory holds one plugin package whose package.json carries an everworks.plugin manifest declaring its id, category, and capabilities array.

The table below lists every category that ships with a concrete plugin today, grouped the way the dashboard groups them at /plugins.

CategoryPluginsCapability
AI ProvidersOpenAI, Anthropic, Google Gemini, Grok (xAI), Groq, Mistral, Ollama, LM Studio, vLLMai-provider
AI GatewaysOpenRouter, Vercel AI Gatewayai-provider
SearchBrave, Tavily, SerpAPI, Exa, Perplexity, Bright Data, Firecrawl, Valyu, Linkupsearch
Git ProviderGitHubgit-provider, oauth
DeploymentVercel, Kubernetesdeployment
ScreenshotScreenshotOne, URLBox, Scrapflyscreenshot
Content ExtractorLocal HTML, Notion, Jina, PDF Extractor, OfficeCLI Extractor, Scrapflycontent-extractor
Data SourceApifydata-source
PipelineStandard Pipeline, Agent Pipeline, Claude Code, Claude Managed Agent, Codex, Gemini Generator, OpenCode, Hermes Agent, Go-to-Market Pipeline, Make.com, SIM AI, Zapier, Composio, Activepiecespipeline
StorageLocal Filesystem, AWS S3, MinIO, GitHub Storagestorage, put-object, get-object, presigned-put
DatabasePostgreSQL DBdatabase, datastore
Vector Storepgvector, Qdrantvector-store
Email ProvidersPostmark, Resend, Mailgun, SendGrid, Mailchimp Transactionalemail-outbound, email-inbound
Notification ChannelsSlack, Discord, Telegram, WhatsApp, Novunotification-channel
ConnectorsSlack, Discord, Linear, Notion, Jira, Zoom, Google Workspace, HubSpot, Pipedrive, Bluesky, Mastodonconnector, event-source
MetricsStripe, PostHog, Google Analytics, Custom HTTPmetrics-provider
Job RuntimesTrigger.dev, Temporal, BullMQ, pg-boss, Inngest, Fleet Nodejob-runtime-enqueue, job-runtime-cancel, job-runtime-status, job-runtime-schedule
Secret StoresHashiCorp Vault, Kubernetes, Infisical, Doppler, AWS Secrets Manager, GCP Secret Manager, Azure Key Vaultsecret-store-resolve
DNSCloudflare DNSdns-ensure-record, dns-remove-record, dns-record-exists, dns-root-domain
Prompt ManagementLangfuseprompt-provider
UtilityComparison Generator, Agent Memory, Agent Memory Hooks, Browser Automation, Ever Works Skills, Ever Works Task Tracker, Local Workspace, Sandbox Workspace, Local PTY Terminal Hostagent-memory, pipeline-modifier, browser-automation, skills-provider, task-tracker, workspace, terminal-stream

See Built-in Plugins for details on each plugin and its configuration.

How each category is populated​

Every plugin declares exactly one category in its manifest, so the counts below are unambiguous and add up to the 102 total.

CategoryCountPlugin directories under packages/plugins/
pipeline14activepieces, agent-pipeline, claude-code, claude-managed-agent, codex, composio, gemini, gtm-pipeline, hermes-agent, make, opencode, sim-ai, standard-pipeline, zapier
ai-provider11anthropic, google, grok, groq, lm-studio, mistral, ollama, openai, openrouter, vercel-ai-gateway, vllm
connector11bluesky-connector, discord-connector, google-workspace-connector, hubspot-connector, jira-connector, linear-connector, mastodon-connector, notion-connector, pipedrive-connector, slack-connector, zoom-connector
utility10agentmemory, browser-automation, comparison-generator, everworks-skills, everworks-task-tracker, langfuse, local-workspace, memory-pipeline-modifier, pty-local, sandbox-workspace
search9brave, brightdata, exa, firecrawl, linkup, perplexity, serpapi, tavily, valyu
secret-store-resolver7secret-store-aws-sm, secret-store-azure-kv, secret-store-doppler, secret-store-gcp-sm, secret-store-infisical, secret-store-k8s, secret-store-vault
content-extractor6jina, local-content-extractor, notion-extractor, officecli-extractor, pdf-extractor, scrapfly
job-runtime6job-runtime-bullmq, job-runtime-inngest, job-runtime-node, job-runtime-pgboss, job-runtime-temporal, job-runtime-trigger
email-provider5mailchimp-transactional, mailgun, postmark, resend, sendgrid
notification-channel5discord-channel, novu-channel, slack-channel, telegram-channel, whatsapp-channel
storage4aws-s3, github-storage, local-fs, minio
metrics4custom-http-metrics, google-analytics-metrics, posthog-metrics, stripe-metrics
deployment2k8s, vercel
screenshot2screenshotone, urlbox
vector-store2pgvector, qdrant
git-provider1github
data-source1apify
database1postgres-db
dns1cloudflare-dns

Two placements are worth calling out, because the manifest category and the everyday label differ:

  • Scrapfly is categorised content-extractor but declares both screenshot and content-extractor capabilities, so it also appears under Screenshot.
  • Langfuse is categorised utility and declares prompt-provider, which is why it shows under Prompt Management rather than as its own category.

Several categories exist in PLUGIN_CATEGORIES with no concrete plugin shipping under them yet — form, integration, theme, and the contract-only memory / rag pair. Their interfaces are stable and public so a community plugin can fill them without a platform change; nothing in the product depends on them today.

Plugin SDK​

The Plugin SDK (@ever-works/plugin) is a standalone TypeScript package with no NestJS dependencies. It provides:

  • IPlugin interface — The contract every plugin implements
  • Base classes — BasePlugin, BaseAiProvider, BaseGitProvider, BasePipelineStep
  • 33 capability interfaces — Typed contracts for each plugin category, one *.interface.ts file each under packages/plugin/src/contracts/capabilities/
  • Settings types — JSON Schema with extensions for secrets, environment variables, and scoping
  • Plugin context — Logger, cache, HTTP client, events, and settings access

See Architecture for the full technical breakdown.

Key Concepts​

Capabilities​

A capability is a specific function a plugin can perform. One plugin can provide multiple capabilities — for example, the Tavily plugin provides both search and content-extractor.

Capability ids come from two places, both validated by the platform. The facade-routed set is enumerated in the PLUGIN_CAPABILITIES constant (packages/plugin/src/contracts/facade-capabilities.ts) and checked by isValidPluginCapability(). Newer contracts — vector-store, memory, rag, the DNS ops, the job-runtime verbs — declare their capability strings in their own interface file and are detected with a per-contract type guard (isVectorStorePlugin(), isMemoryPlugin(), isRagPlugin(), …) over the manifest's capabilities array.

Available capabilities, one row per interface file:

CapabilityInterfaceDescription
ai-providerIAiProviderPluginChat completions, embeddings, structured output
searchISearchPluginWeb search queries
content-extractorIContentExtractorPluginURL content extraction, optionally with JavaScript rendering and selector scoping
screenshotIScreenshotPluginWebsite screenshot capture
data-sourceIDataSourcePluginExternal data querying, with relevance filtering against the Work prompt
git-providerIGitProviderPluginRepository management, cloning, pushing, plus the shared PR-insights rollup
deploymentIDeploymentPluginSite deployment and status
oauthIOAuthPluginOAuth authentication flows
device-authIDeviceAuthProviderDevice-code login for CLI-backed plugins (declared by Codex)
pipelineIPipelinePluginGeneration pipeline (Standard, Agent, Claude Code, Claude Managed Agent, Codex, Gemini, OpenCode, Hermes, Go-to-Market, Make.com, SIM AI, Zapier, Composio, Activepieces)
pipeline-modifierIPipelineModifierPluginInjects or wraps steps in a host pipeline, with a build-time skip check
code-editICodeEditPluginEdits a checked-out workspace in place; returns changed paths, a summary, and raw agent output
form-schema-providerIFormSchemaProviderDynamic form schema generation for plugin UIs
prompt-providerIPromptProviderPluginExternal prompt management (e.g. Langfuse)
storage, put-object, get-object, presigned-putIStoragePluginObject storage for uploads; presigned-put is opt-in for backends that can mint a direct-to-cloud upload URL
database, datastoreIDatastorePluginRelational database backend for deployed Works; the per-Work database name is derived as ew_<workId>
vector-storeIVectorStorePluginChunk-embedding storage and similarity query behind the Knowledge Base
email-outbound, email-inboundIEmailOutboundPlugin, IEmailInboundPluginTransactional and agent-driven email send, inbound parsing, and delivery events
notification-channelINotificationChannelPluginOutbound fan-out to chat surfaces, plus a channel-specific id such as notification-channel-slack
connectorIConnectorPluginBidirectional comms — outbound send plus inbound routing to an Agent or Team — with a provider id such as connector-linear
event-sourceIEventSourcePluginPull-model event ingestion into the normalized IngestedEventEnvelope spine, with an optional historical backfill()
metrics-providerIMetricsProviderPluginRead-only business and operational metrics collection for Goals; any write is a contract violation
agent-memoryIAgentMemoryPluginPer-session persistent memory for coding and generation agents — sessions, observations, search, context build
memoryIMemoryPluginOrganization-wide memory framework, scoped by tenant / organization / work / mission. Contract-only — no plugin ships with it yet
ragIRagPluginA composed retrieval pipeline over an extractor, an embedder, and a vector store. Contract-only — no plugin ships with it yet
skills-providerISkillsProviderPluginSkill catalogs — Markdown bodies plus parsed frontmatter
task-trackerITaskTrackerPluginExternal task trackers behind the platform's own Task UI
workspaceIWorkspacePluginIsolated Git working contexts for agent-executed Tasks — a fresh branch off origin/<baseRef>, shipped as a PR
terminal-streamITerminalStreamPluginHosts a live, typable agent terminal session and pumps frames to the platform relay
browser-automationIBrowserAutomationPluginHeadless navigate / extract / screenshot / act behind a default-deny navigation allow-list re-checked on every redirect hop
job-runtime-enqueue, job-runtime-cancel, job-runtime-status, job-runtime-schedule, job-runtime-worker-host, job-runtime-bind-tenantIJobRuntimeProviderBackground-job execution backends; the first four are required, the last two optional
secret-store-resolveISecretStoreProviderResolves a <scheme>:<payload> credential pointer into the plaintext credential bag a job runtime binds with
dns-ensure-record, dns-remove-record, dns-record-exists, dns-root-domainIDnsProviderIdempotent DNS record management for managed subdomains and custom domains

Configuration Modes​

Each plugin declares how it should be configured:

  • admin-only — Only admins can configure (system infrastructure plugins)
  • user-required — Users must provide their own credentials (e.g., API keys)
  • hybrid — Admin provides defaults, users can override

Scoped Resolution​

Each work can use a different plugin per capability. For example:

  • Work A uses OpenAI for AI and Brave for search
  • Work B uses Anthropic for AI and Tavily for search

This is managed through the Settings System and the work-level plugin management UI.

Instance-level selectors​

Three categories are not resolved per Work at all — they are picked once per deployment by an environment variable, because swapping them mid-flight would strand data or in-flight jobs:

SelectorChoosesDefault
STORAGE_BACKENDThe upload storage pluginlocal-fs
EVER_WORKS_JOB_RUNTIMEThe active job runtimetrigger
PLUGIN_DISTRIBUTION_MODEBundled vs. dynamic plugin loadingbundled

Every other registered plugin in those categories stays loaded but inert, so changing a selector is a restart rather than a migration.

How to enable and configure a plugin​

  1. Open /plugins in the dashboard. The catalog groups every plugin by category and gives you a search box, a category filter, and an enabled only toggle.
  2. Click a plugin to open /plugins/:pluginId — its README, its declared capabilities, and its settings schema.
  3. Enable it, then fill in the settings. Fields marked x-secret (API keys, tokens) are stored encrypted and are never returned by the API; they come back masked or omitted.
  4. To edit an already-enabled plugin later, go to /settings/plugins and pick its category. The per-category page lives at /settings/plugins/:category — for example /settings/plugins/ai-provider, /settings/plugins/search, /settings/plugins/connector.
  5. To override a plugin choice for one Work only, open /works/:id/plugins and set the plugin for that capability. Work settings win over your user settings, which win over the admin defaults.

How to manage plugins from the CLI​

The CLI mirrors the dashboard, including the dynamic-distribution lifecycle:

# Interactive plugin manager, optionally filtered by category
ever-works plugins
ever-works plugins --category ai-provider

# Dynamic distribution (requires PLUGIN_DISTRIBUTION_MODE=dynamic)
ever-works plugins catalog              # list distributable plugins from the registry
ever-works plugins install <pluginId>   # install one at runtime
ever-works plugins install-status <pluginId>
ever-works plugins uninstall <pluginId>

The same data is available over REST: GET /api/plugins (optionally ?category=), GET /api/plugins/:pluginId for the settings schema, and GET /api/plugins/settings-menu for the category-grouped navigation. See API Reference for the full endpoint list.

Bundled vs. distributable​

Every plugin manifest carries a distribution field. Core plugins are always baked into the platform image; distributable plugins are published to npm as @ever-works/<id>-plugin and installed on first enable when PLUGIN_DISTRIBUTION_MODE=dynamic. The split today is 27 core and 75 distributable — see Built-in Plugins for the exact list and the classification rule.

Documentation​

PageDescription
ArchitecturePlugin SDK, interfaces, lifecycle, bootstrap, facades
SettingsThree-tier settings, JSON Schema extensions, resolution
Creating a PluginStep-by-step guide for building a new plugin
Built-in PluginsBuilt-in plugins with configuration details
API ReferenceREST endpoints for plugin management