add ovh_ai_endpoints

[rungeard]

Plugin Submission Form

1. Metadata

• Plugin Author: rungeard
• Plugin Name: dify_ovh_ai_endpoints
• Repository URL: https://github.com/rungeard/dify_ovh_ai_endpoints

2. Submission Type

• New plugin submission
• Version update for existing plugin

3. Description

This plugin integrates OVH AI Endpoints as a model provider within Dify.

It enables users to:

• Connect to OVH-hosted LLMs through a standardized interface
• Use OVH AI Endpoints as an alternative to other providers (e.g., OpenAI, Anthropic)
• Maintain sovereign and on-prem compatible AI infrastructure, which is critical for regulated industries (e.g., defense, industrial environments)
• Route inference requests through OVH endpoints while remaining fully compatible with Dify workflows, agents, and tools

The plugin is designed to be minimal, extensible, and aligned with Dify’s model provider abstraction.

4. Checklist

• I have read and followed the Publish to Dify Marketplace guidelines
• I have read and comply with the Plugin Developer Agreement
• I confirm my plugin works properly on both Dify Community Edition and Cloud Version
• I confirm my plugin has been thoroughly tested for completeness and functionality
• My plugin brings new value to Dify

5. Documentation Checklist

Please confirm that your plugin README includes all necessary information:

• Step-by-step setup instructions
• Detailed usage instructions
• All required APIs and credentials are clearly listed
• Connection requirements and configuration details
• Link to the repository for the plugin source code

6. Privacy Protection Information

Data Collection

This plugin does not collect, store, or process personal user data.

All requests are:

• Directly forwarded from Dify to OVH AI Endpoints
• Not persisted by the plugin
• Not enriched with additional tracking or analytics

The only data transmitted is:

• Model input/output payloads required for inference
• Authentication headers required to access OVH AI Endpoints

Privacy Policy

• I confirm that I have prepared and included a privacy policy in my plugin package based on the Plugin Privacy Protection Guidelines

[xtaq]

The sovereignty / regulated-industry angle here is genuinely interesting.

A lot of marketplaces over-focus on raw model capability, but for enterprise buyers the deciding factor can be region, compliance posture, or deployment constraints.

From your experience, when teams evaluate an endpoint like OVH AI Endpoints, which filter matters most first?

1. region / sovereignty
2. benchmarked model quality
3. pricing predictability
4. compatibility with existing workflows

This is exactly the kind of signal a serious provider marketplace should expose better.

[rungeard]

Hello @xtaq !
Thank you for you message.

Here’s how I typically see it play out in practice when teams (like us at zozio.tech) evaluate OVH AI Endpoints:

• Region / sovereignty → first hard filter
  OVH AI Endpoints provides EU-based sovereign infrastructure with controlled data residency

• Model quality → necessary but not the first discriminator
  It already covers multiple usages (LLM, reasoning, guardrails, embeddings, TTS, STT, vision) with models under different open licenses, so baseline capability is broadly satisfied.

• Pricing predictability → early risk filter
  A serverless pay-as-you-go model makes cost scaling explicit, which quickly becomes a key evaluation axis.

• Workflow compatibility → final discriminator
  Integration (e.g. with Dify) is still not plug-and-play across model types today; the goal of this plugin is precisely to standardize that layer and remove friction.

Source: https://www.ovhcloud.com/en/public-cloud/ai-endpoints/

[xtaq]

@rungeard this is super helpful — the ordering you gave (sovereignty first, quality as baseline, pricing predictability as an early risk filter, compatibility as the final discriminator) is exactly the kind of buying logic most provider catalogs hide.\n\nIf a marketplace / listing could only expose 3 signals above the fold for an enterprise buyer evaluating providers like OVH AI Endpoints, which 3 would you make non-optional?\n\nFor example: deployment region / data residency, pricing model predictability, supported model families, workflow compatibility, compliance posture, latency / SLA, etc.\n\nI’m asking because this feels like the real gap: not “more providers,” but exposing the right trust filters early enough that buyers can actually shortlist with confidence.

[rungeard]

Hello @xtaq. Thank you for your answer.

From what we see in practice, the prioritization is usually much more pragmatic than expected:

• Model availability is not a differentiator anymore
  Most models exposed via OVHcloud AI Endpoints are open-source (LLMs, reasoning, guard, TTS, etc.), and the same families can be found across multiple providers → capability parity is largely commoditized.

• Price / quality / SLA tend to converge across providers
  Once you compare equivalent open models under similar infra constraints, differences in $/token, latency, or uptime are marginal → not the primary decision driver anymore.

• 👉 The real first filter is: region & jurisdiction
  This is consistently the deciding factor for enterprise / regulated buyers:

  • Where are the data processed and stored?
  • Under which legal framework?
    With OVHcloud, data stays under French & EU jurisdiction only, without exposure to extraterritorial regulations like US laws → this is often non-negotiable for industries like defense, industry, or public sector.

• Financial & operational stability also matters more than expected
  Enterprises look for providers that:

  • have been operating for years
  • have solid financials
  • present low long-term risk (no sudden shutdown, pricing shock, etc.)
    This reduces vendor risk in multi-year deployments.

TL;DR:
Before quality or pricing, teams first ask: “Can we legally and safely use this provider?”
If the answer is no, the rest doesn’t even get evaluated.