Choosing a Dify plugin type before you write any code
Match the integration to the plugin type that fits its role in Dify, and first check whether an OpenAPI tool or custom endpoint already does the job. Dify is an LLM application development platform for building AI workflows, RAG pipelines and agents through a visual interface. It is released under the Dify Open Source License, which limits how the source can be operated, so review it before you plan a shared environment (Dify on GitHub). Plugin work sits inside your self-hosted deployment. This page concerns how your Dify instance calls your internal systems, not blockchain or model training. A team that needs Dify to call an internal system or expose a new capability must choose among six plugin types: tool, model, agent strategy, extension, datasource and trigger. The role the integration plays decides the type, and the type decides what you must build, package and keep patched.
Each type answers a different question about the integration. A tool plugin gives workflows and agents an action to call, such as opening a ticket in an internal system, and it is the usual choice when a workflow or agent must read or change data. A model plugin makes a model selectable in Dify, so it cannot carry tools with it, and it fits only when the goal is a new model endpoint. A datasource plugin feeds documents from a wiki or file share into knowledge pipelines, while a trigger plugin starts a workflow when an event arrives from a ticketing, CRM or monitoring system. Agent strategy and extension plugins change how agents reason or how the platform hooks into applications. Confirm their interfaces in the plugin developer documentation for the Dify version you run before you commit to either.
Before writing any code, test whether a lighter path works. If the internal system publishes an OpenAPI or Swagger description, an OpenAPI tool can be imported in the Dify interface, with authentication set in the tool configuration. Calls to internal hosts must be allowed through the SSRF_PROXY allowlist. A workflow that starts with a User Input node can be published as a tool, but a chatflow cannot, so check the app type first. For moderation or external data lookups, a custom endpoint may already meet the contract, which uses a bearer key and a ping check. Record the owner of each credential, the internal hosts involved and the Dify version you target. Any plugin you build must match that version and be maintained alongside it.
What each Dify plugin type does
Dify plugins extend a self-hosted instance in different places: workflows, model lists, knowledge pipelines and event entry points. Pick the type by where the integration has to appear inside Dify, then confirm each type's current fields and limits in the plugin documentation before you build.
Tool plugin
A tool plugin exposes actions that workflows and agents can call, such as looking up a customer record or opening a ticket in an internal system. It is the usual choice when the integration is a set of request-and-response operations. Check how the tool authenticates to the internal system, whether credentials are set per workspace or per user, and whether an OpenAPI tool would cover the same calls without a plugin. Confirm the credential model in the current docs before you design around it.
Model plugin
A model plugin makes a model selectable in Dify's provider list, so apps can choose it the same way they choose a built-in provider. It suits an internal model gateway or a fine-tuned model that teams should reach from the model picker. Model plugins expose model types and a credential schema only, so the same package cannot also carry tools. Confirm which model types your target version supports before you plan the gateway.
Agent strategy plugin
An agent strategy plugin defines how an agent node reasons and chooses actions, for example the loop it follows when calling tools. Choose it when the reasoning pattern itself is the integration, not the external system. Most internal integrations need a tool plugin instead. Check how strategies interact with the sandbox and the plugin daemon's resource limits, since an agent loop can make many calls per run.
Extension plugin
An extension plugin adds endpoints or hooks that Dify calls at defined points, such as the custom endpoints used for moderation or external data. It fits teams that need Dify to call their own service for a decision during an app run. Confirm the request and response contract, the bearer key validation and the ping check in the current docs, and decide who owns the endpoint's availability, because a failing hook can stall the app.
Datasource plugin
A datasource plugin connects a source such as a wiki, file share or document management system to knowledge pipelines, so documents can be indexed into a knowledge base. Choose it when the content lives in a system with no official plugin and needs repeated synchronization. Plan the source's access model, how deleted or changed documents are handled, and which knowledge base settings the indexed content will inherit.
Trigger plugin
A trigger plugin lets an external event, such as a ticket update, CRM change or monitoring alert, start a Dify workflow. It depends on a public trigger endpoint, so network exposure and request validation become part of the design. Choose it only when the event must start the workflow automatically. Confirm the endpoint's authentication options and payload format in the current trigger documentation before you expose anything.
How plugins run in a self-hosted Dify
Since the plugin architecture, plugins do not run inside the api or worker containers. They run through the plugin daemon, which the Docker Compose stack starts alongside the api and worker services. That placement changes the decision. A tool, model, agent strategy, extension, datasource or trigger plugin all depend on the daemon being healthy and able to reach whatever the plugin calls, so the type you pick determines which paths the daemon must open. A model plugin that calls an internal inference server needs a network route from the daemon to that server, while a tool plugin that calls an internal REST API needs the same route to a different host. Confirm for your Dify version how the daemon is started, which network it joins and how it reaches the api service, because these details have changed across releases and the Compose file you deploy is the authority.
Plugins are third-party code, and they can use the credentials you configure for them. Whatever type you choose, the plugin receives the values defined in its credential or provider schema, and a plugin that calls an external service can send those values wherever its code directs. Model and tool plugins carry the most sensitive credentials in practice, such as provider API keys or service accounts. Before selecting a type, list which credentials the plugin will hold, which hosts it will contact and who owns its code. An internal plugin you write yourself shifts review and signing work onto your team, while a plugin from the Marketplace still needs an owner who reads its source and tracks its updates. The Dify SSRF and outbound request settings govern outbound traffic from the platform, but you should verify with your own tests that a plugin cannot reach hosts you have not approved.
Treat the plugin type as a review and signing decision, not only a feature decision. Ask who will approve each version, how packages will be signed and whether production will keep signature checks enabled. Test the chosen type on a staging instance with the same daemon settings as production, including timeouts, file limits and network routes, before a plugin reaches users. Record the daemon version alongside the Dify release, since daemon behavior may change with upgrades, and check the release notes for each minor version before you move a plugin to a new platform version.
Which plugin type fits which integration
Workflows that call an internal REST API usually need a tool, and Dify can often create that tool directly from the API's OpenAPI or Swagger schema. Start with the schema route when the API already has a valid description, the calls are straightforward, and authentication is a static key or header that the workspace can hold. A tool plugin becomes the better fit once the logic goes beyond mapping requests to responses.
- Schema import first: A valid OpenAPI or Swagger file lets you expose each operation as a selectable action without writing code.
- Authentication shape: Static keys and headers fit the schema route. Per-user OAuth, token exchange or request signing usually points to a tool plugin.
- Custom logic: Pagination across calls, response reshaping, retries and multi-step sequences belong in a tool plugin, where you write them as code.
- Network reach: Internal hosts must be allowed through the SSRF proxy configuration on either route, so agree on the allowlist with your platform team before testing.
Check whether the schema import covers every operation the workflow needs, and whether any call requires credentials that a workspace-level setting cannot store safely.
A model plugin makes a model endpoint selectable in Dify's model settings, alongside the providers already available. Choose it when your team runs an internal gateway or a fine-tuned model that has no built-in provider in Dify and its models must appear in the same selectors as other models. First confirm whether the endpoint can be reached through an existing provider configuration, since that avoids packaging and maintaining code.
- Exposed model types: A model plugin declares which model types it offers, such as text generation or embeddings, so settle the types you need before building.
- Credential schema: The plugin defines the fields each workspace fills in, such as a base URL and key, which keeps secrets out of the source code.
- No bundled tools: A model plugin cannot also ship tools. If the gateway needs a companion action, build that as a separate tool plugin or an OpenAPI tool.
- Gateway ownership: Routing, quotas and logging stay with the gateway's operators, so the plugin only needs to call the gateway correctly.
Confirm which model types your gateway serves and whether every workspace should see every model it exposes.
A datasource plugin feeds documents into a knowledge pipeline. Use one when the source is a document management system, wiki or file share with no official plugin, and you need Dify to pull documents from it on a schedule or on demand, without manual uploads. The plugin handles the connection to the source, while the knowledge base settings remain part of your retrieval design.
- Source connection: The plugin manages authentication to the source system and lists the files or pages it can index.
- Pipeline role: Datasource plugins run inside knowledge pipelines, so chunking and indexing decisions still need their own review.
- Permission mapping: Source permissions carry over only if the plugin passes that metadata into Dify and Dify applies it. Verify this, because access control inside Dify is configured separately.
- Alternative route: For a small, stable set of files, uploading them directly or exporting them in a supported format avoids code and an ongoing sync job.
Ask whether the source offers an API or export that identifies changed documents, because full re-indexing on every run affects both load and how quickly answers reflect updates.
A trigger plugin starts a workflow when something happens in another system, such as a new ticket, a CRM update or a monitoring alert. It fits when the external event should initiate the run and the event payload must be converted into workflow inputs by a defined handler. Because the trigger depends on a public trigger endpoint, the design must cover how that endpoint is exposed and how requests are validated.
- Event-driven start: A trigger plugin registers interest in events and starts a run for each one, which suits workflows that must react promptly.
- Endpoint exposure: The external system has to reach Dify's trigger endpoint, so network path, TLS and request validation become part of the design.
- Payload handling: Decide how raw event fields map to workflow inputs and how malformed or duplicate events are dropped.
- Alternative route: If the source system already runs automation, it can call the app's service API with an API key. That avoids a plugin but moves retry logic and signature checks into the source system.
Confirm whether the source signs its webhooks, what it does when delivery fails, and who holds and rotates the credentials.
An agent strategy plugin changes how an agent reasons and chooses its tool calls, including the planning loop it follows. Build one only when the reasoning pattern is the actual cause of a failure that the built-in options cannot correct. Most teams should first improve tool descriptions, instructions and workflow structure, because those changes cost less to make and to test.
- Scope of change: A strategy plugin alters the reasoning loop, so a fix there affects every tool and every app that uses the agent.
- Testing burden: Agent behavior varies across inputs, so prepare an evaluation set before and after any change to the strategy.
- Deterministic alternative: A workflow with explicit branches gives predictable routing where the steps are known in advance, and it needs no custom code.
- Moderation and external data: Hooks that screen inputs or fetch outside data use custom endpoints, so keep them out of the reasoning loop.
Record the specific failure you need to fix, and confirm that instructions, tool design or workflow structure cannot resolve it first.
Plugin type versus OpenAPI tool and custom endpoint
This table compares the six plugin types with OpenAPI tools and custom endpoints across what each is for, who writes it, and how it is distributed and run. Start with the lightest option that fits the integration, and note that model plugins cannot bundle tools and custom endpoints follow a fixed contract. Verify packaging and distribution details against the Dify plugin documentation before you commit to a build.
| Option | What it is for | Who writes it | Distribution and what it needs |
|---|---|---|---|
| Tool plugin | Exposes an internal system as an action that workflows and agents can call | Developer with API and credential knowledge | Packaged and installed per workspace; needs outbound access to the target host |
| Model plugin | Makes a model gateway or fine-tuned model selectable in Dify | Developer with model endpoint and credential details | Cannot bundle tools; needs the model endpoint and its credential schema |
| Agent strategy plugin | Defines how an agent reasons and chooses tool calls | Developer who understands agent behavior | Used by agent nodes; retest agents against their full tool set after changes |
| Extension plugin | Adds capabilities that do not fit the other plugin types | Developer familiar with the plugin SDK | Confirm current scope and packaging in the plugin docs before choosing it |
| Datasource plugin | Indexes documents from a system with no official connector | Developer with access to the source system | Feeds knowledge pipelines; needs read access and credentials for the source |
| Trigger plugin | Starts workflows from events in ticketing, CRM or monitoring systems | Developer who knows the source system's event model | Depends on the public trigger endpoint being reachable by the source system |
| OpenAPI tool | Turns an existing REST API into a tool without writing a plugin | Integration team with access to the API schema | No plugin package; needs a valid OpenAPI or Swagger schema, auth settings and allowed hosts |
| Custom endpoint | Connects your own moderation or external data API at fixed hook points | Team that runs the external service | Follows a fixed contract with bearer key validation and a ping check |
How the plugin type decision is made and verified
This sequence turns a vague request for an internal integration into a documented plugin type choice, tested against the real network path and data before any plugin code is written. Each step leaves a concrete artifact that the next step depends on.
Inventory the integration and its data
The integration owner and the platform team list every system the Dify app must reach, the operations needed (read, write, search, trigger, or model inference), the data each call carries, and the identity the call should run under. Record whether the target is a REST API with an OpenAPI or Swagger description, a database, a file share, an event source, or a model endpoint. The step is done when the inventory names each data class and each caller, and the security owner has signed off on which data may leave the source system. Ask the vendor or internal API owner for an up-to-date schema before you rely on one.
Map each need to a plugin role
Using the inventory, the platform engineer assigns each need to a Dify extension point: tool plugins for actions an agent or workflow calls, model plugins for inference endpoints, agent strategy plugins for custom reasoning loops, extension plugins for app-level hooks, datasource plugins for indexing content into knowledge pipelines, and trigger plugins for starting workflows from events. Note where a need does not fit any role cleanly, because that is usually the signal to reconsider the approach. The output is a mapping table with one row per need, the chosen plugin role, and the reason. Confirm the current plugin types against the Dify documentation for your version, since the set of extension points is defined there.
Test an OpenAPI tool or custom endpoint first
Before writing a plugin, check whether the need can be met by importing an OpenAPI or Swagger schema as a custom tool, or by registering a custom endpoint for moderation or external data. Import the schema into a non-production workspace, configure the authentication the API requires, and run each operation with representative inputs. The step is done when each operation returns the expected response and the team has noted any gaps, such as unsupported auth flows, response shapes that need transformation, or logic that cannot be expressed as a single HTTP call. If every operation passes, the plugin may be unnecessary for this integration.
Confirm the outbound path through the SSRF proxy allowlist
Every outbound call from Dify to an internal host passes through the SSRF proxy, which blocks internal and private IP ranges by default. The network or platform engineer lists each host, port and protocol the chosen option must reach, then checks whether the proxy configuration permits them and how it is changed in your deployment. Record the exact set of hostnames and the credentials each one requires, including where those secrets will be stored. The output is a reachability table: source component, destination host and port, auth method, and the owner of the secret. Test the path from the Dify container context, not from a workstation, because a successful test from elsewhere proves little.
Write a short decision record
The solution owner writes one page that states the integration goal, the chosen plugin type or OpenAPI or endpoint approach, the alternatives rejected and why, the data classes involved, the hosts and credentials required, and the known limits. Include the Dify version the decision was tested against, because extension points and sandboxing behavior change across releases. The record is complete when the security reviewer and the platform owner have each approved it in writing. This record becomes the reference when the plugin is later built, reviewed or retired.
Prototype in a non-production workspace
The team runs the chosen option in a separate workspace on a non-production instance that mirrors the production Dify version, network path and secret handling. Test normal operations, error responses, timeouts, large payloads, and revoked or rotated credentials. Confirm the app behaves the same whether it is reached through the Dify console or through an API key. The step is done when the test workspace produces a written result listing each scenario, the outcome, and any defects that must be fixed before production. If the prototype exposes a gap the schema test missed, return to the decision record and update it before continuing.
What data and credentials the chosen type must handle
Whichever plugin type you choose, the credentials it uses are a second decision, and they live in the target instance rather than in the plugin package. Tool, model, datasource and trigger plugins all need keys, tokens or endpoint secrets to reach your internal systems or external providers. Dify stores those credentials per workspace, so a plugin installed in one workspace does not carry its working credentials into another. Before you pick a type, list every secret the integration needs, which workspace will hold it, and who is allowed to rotate it. The SECRET_KEY setting is the foundation for this. According to the Dify environment variable reference, it signs session cookies and JWTs and encrypts OAuth credentials, so it protects anything Dify stores on your behalf.
Treat SECRET_KEY as a value that must not change after go-live. The same reference says that changing it after deployment logs out all users. Plan its generation, storage in your secrets manager, and its inclusion in your backup and restore procedure, because a restored database that was encrypted with a different key cannot decrypt stored credentials. Ask your deployment team to confirm where workspace encryption keys are held in your environment, since the reference lists local storage and Azure Key Vault as options. Confirm this against your own configuration rather than assuming a default.
App exports do not solve the credential problem. Dify's YAML DSL export covers app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but it does not include third-party API keys. Every tool or plugin credential therefore has to be re-entered or provisioned in the target instance, which should be recorded as a step in your promotion checklist. Also confirm that outbound calls from the plugin to internal hosts pass through the SSRF proxy settings your team has configured, because those settings decide which private addresses the plugin can reach.
What drives the effort of a plugin type decision
This table lists the factors that most change how much work an internal Dify integration takes, whichever plugin type or non-plugin option you choose. Read each row as a question to answer before scoping: the higher the count or the stricter the requirement, the more the choice of plugin type and the build effort move. Scope the simplest option that meets the need first.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Number of target systems | Each internal system adds its own endpoints, data shapes, owners and test accounts, and a plugin bundles one provider's tools, so several systems often mean several plugins or a different approach. | Start with one system and one use case. Group related endpoints from the same system into one tool set where the owner is the same. |
| Authentication model (API key, OAuth, none) | API keys are stored as workspace credentials, while OAuth requires redirect handling, token refresh and per-user consent, which adds build and review work. | Use an API key or no authentication for a first internal pilot where policy allows. Move to OAuth only when the action must run as the individual user. |
| Need for private distribution across workspaces | A plugin built for one workspace is simple, but sharing it across workspaces needs a packaging, versioning and signing routine that your team must run. | Confirm early how many workspaces need the integration. Keep a single approved package source and a named owner for each release. |
| Whether the source system has an OpenAPI schema | A usable schema lets you import tools with little custom code. Without one, each operation is written by hand, tested and documented. | Check for a published OpenAPI or Swagger document before choosing a plugin. If one exists, try a schema-based tool first. |
| Network reach to internal hosts | Calls to private addresses pass the outbound request controls, so the target host and path must be allowed, and that approval involves the platform operator and network team. | Confirm the exact hosts and ports up front and request one narrow allowlist entry. Test reachability from the Dify API and worker containers, not from a workstation. |
| Data sensitivity and logging of tool calls | Tools that return personal or regulated data need review of what is sent to models, what is logged and how errors are handled, which adds design and sign-off time. | Limit returned fields in the tool contract and agree the logging scope before build. Reuse existing review criteria for the same data class. |
| Ongoing ownership and upgrades | Plugins have their own versions, and Dify releases change the plugin interface, so each plugin needs regression checks after platform upgrades. | Name an owner for each plugin, pin versions and include plugin checks in your upgrade test plan. |
Questions teams ask before choosing a plugin type
Is an OpenAPI tool enough for our internal API?
Often, yes, if the API already has a usable OpenAPI or Swagger description and the integration only needs to call endpoints and return results. An OpenAPI tool avoids writing and packaging a plugin, so it is the cheaper path to test first. It stops being enough when you need custom authentication flows such as OAuth on behalf of users, data that must be transformed in code, non-HTTP protocols, or an event source that starts workflows. Check that the internal hosts can be reached through the SSRF proxy allowlist before you commit to this route, since outbound requests from Dify are filtered. Ask a partner to test the schema against your real endpoints in a non-production workspace before deciding.
What does a plugin build cost, and what drives the price?
No price is given here, and DeployOpen does not publish one. A plugin build is a labor cost. The main drivers are the plugin type, how many systems it touches, the authentication model, the number of parameters and error cases, the depth of testing, and how many packaging and distribution variants you need. Recurring costs come from maintaining the plugin each time Dify releases a new minor version, which the project ships roughly monthly, and from updating it when the internal API changes. Ask for a written scope that separates design, build, testing, packaging, distribution setup, handover and any retainer for ongoing maintenance.
How long does choosing a plugin type take?
The decision itself is usually short once the team has the integration requirements in writing, because the choice depends on what the integration must do, not on tooling. The longer part is confirming facts: whether the API has a current specification, who can approve test access, and whether the target workspaces are Community or Enterprise. Duration for the build is not fixed by any source we rely on, so ask for a timeline in the written scope. Plan time for a short proof of concept against one real endpoint, since it often settles the choice faster than a document review.
Can our team make this decision internally?
Yes, many teams can, provided someone understands both the internal system and the Dify extension points. The decision rests on five questions: what the integration must call, which identity it uses, whether it must start workflows from events, whether it supplies models or knowledge, and who will maintain it. If the answers are clear and one engineer has time to test an OpenAPI tool, an internal decision is reasonable. A partner adds value when the integration touches several plugin types, needs OAuth, or must pass a security review before go-live.
What do we need to provide for a plugin build?
The work needs four things from your side: current API documentation or an OpenAPI description, test accounts with the permissions the plugin will use, a non-production environment where the plugin can be installed, and a named business and technical owner who can approve decisions. Add a security contact who can review credential handling and network access. Without test accounts, the build stalls at the first authentication step. Without a named owner, scope changes take longer to settle. Confirm these items in the written scope so the schedule reflects your actual dependencies.
Does the Community edition limit plugin distribution?
The Community edition is free and limited to a single workspace, according to the Dify pricing page, so a plugin you build can be used there in that one workspace. Multi-workspace distribution, central plugin policy and installation control belong to the Enterprise edition, which is custom priced and includes SSO, multiple workspaces and professional support. Check the current feature list on the pricing page and confirm with Dify how plugin installation policy works in your edition before you plan distribution across teams. Licensing terms also matter: the Dify Open Source License restricts operating a multi-tenant environment without written authorization.
What should a partner hand over at the end of the build?
A partner should hand over working code in your repository, the plugin package and its build steps, a configuration reference listing every credential and parameter, a test record covering the cases agreed in scope, and a short runbook for installing, upgrading and rolling back the plugin. You should also receive a decision record that explains why this plugin type was chosen over an OpenAPI tool or custom endpoint, and a list of what must be rechecked when Dify changes. Ask for these items to be named in the written scope, with acceptance criteria for each.
How plugins connect to the rest of the platform
A plugin does not run alone. It passes through the plugin daemon, reaches internal hosts through the outbound proxy, and gets called by workflows, agents, knowledge pipelines and triggers. Each connection point below is a place to check before you choose a plugin type.
Plugin daemon and API service
Dify runs plugins in a separate plugin daemon, and the api service talks to it over an internal interface. Plugin type decides which parts of the app call the daemon, so a model plugin and a tool plugin fail in different places. Confirm how the daemon is configured in your deployment, including its timeouts and package size limits, before you assume a plugin will run under load.
SSRF proxy allowlist for internal hosts
Dify's SSRF_PROXY settings route outbound requests through a proxy that blocks internal and private IP ranges by default. A tool plugin or OpenAPI tool that calls an internal API will be blocked unless the target is explicitly permitted. Ask your platform team which internal hosts and ports need an allowlist entry, and test each one from the running Dify containers.
Knowledge pipelines for datasource plugins
A datasource plugin feeds documents into a knowledge pipeline, which then chunks and indexes them for retrieval. Choose this type only when the source system needs its own connector and a document pull on a schedule or on demand. Check where the indexed content will be stored, which vector store the knowledge base uses, and who can read the results after ingestion.
Workflows and agents that call tools
Tool plugins, and tools imported from OpenAPI schemas, are called by workflow nodes and by agents during a run. The caller decides the inputs, so a tool with broad parameters can be triggered in ways the builder did not test. Review each tool's input schema and which apps can use it, and confirm that a failing tool call produces an error the workflow can handle.
Trigger endpoint for event-driven starts
A trigger plugin starts a workflow when an external event arrives, which means Dify must expose an endpoint that the source system can reach. That endpoint becomes an inbound path into your workspace, so it needs the same review as any public API. Confirm the authentication method, the network path from the source system, and how repeated or failed events are handled.
SSO and plugin policy across workspaces
The Community edition is limited to a single workspace, while Enterprise adds SSO and multiple workspaces. Once several workspaces exist, a plugin approved in one may not be approved in another, and access to plugin installation follows the identity model. Ask which workspaces will install plugins, who approves them, and whether a single plugin version must be enforced everywhere.
What to ask a partner to scope for the plugin decision
A fixed-scope written plan for this decision should start with the integration inventory: every system the Dify apps need to reach, the operation each one must perform (read, write, search, trigger a workflow, index documents, or supply a model), and the owner who approves that access. Ask the partner to list the chosen plugin type for each row with a short reason, and to record the rejected alternatives beside it, such as an OpenAPI tool or custom endpoint where a plugin was considered unnecessary. The plan should also state which items are one-time build work and which will need upkeep when the target system changes its API or the Dify version moves forward.
Next, the plan should set out credential and network requirements per integration: where each secret is stored, how it reaches the plugin or tool at runtime, whether the call is made as the service or on behalf of a user, and which hosts must be reachable through the SSRF proxy allowlist. Ask the partner to confirm these settings against your own environment rather than assume defaults, and to name the Dify environment variables and deployment files that will change. The test plan should cover install, signature handling, failure behavior when the target is down, and a check that outbound traffic only reaches approved hosts. The handover list then records who can install, update and roll back each plugin, and where the written decision is kept.
Ask for the document to be explicit that DeployOpen does not publish prices. A quote follows from the written scope, so the detail above is what drives it: the number of integrations, how many plugin types each needs, the authentication model, and how much testing your environment requires. Ask the partner to separate the one-time build from any recurring support and version maintenance, and to state what you must provide, such as test accounts, API documentation and a staging instance. Scope that stays vague on these points will produce a quote that is hard to compare across bidders.
How DeployOpen scopes plugin type decisions
DeployOpen approaches plugin type selection as a written scoping exercise before any code is written. We map each internal integration to the plugin type or lighter mechanism that fits it, then agree deliverables, testing and handover in a fixed-scope document. Ongoing support is available as a retainer once the plugin is in production.
How we scope
- We list each internal system and the Dify surface it must reach, such as a tool, a model, a datasource or a trigger.
- We check whether an OpenAPI tool or custom endpoint covers the need before proposing a plugin build.
- The written scope names deliverables, test evidence, owners and the Dify version the work targets.
How we build
- We build the chosen plugin type in your environment, using your own repositories and build pipeline.
- We test outbound calls against the SSRF proxy allowlist and confirm internal hosts are reachable only as intended.
- We verify credential handling per workspace and confirm the plugin behaves correctly after a Dify upgrade.
How we hand over
- You receive the plugin source, packaged artifacts and a record of the plugin type decision and its reasons.
- Runbooks describe installation, version pinning, signature checks and the steps to roll back a faulty release.
- Your team walks through the test results and the upgrade notes before the engagement closes.
How we support
- Ongoing support, upgrades and regression testing for plugins are available as a retainer.
- We review each Dify minor release for changes that affect your plugins and the systems they call.
- Retainer scope is agreed in writing, so you know which plugin changes and checks are covered.
