Does Gemini plugin support Veo2 or Veo3 video models?

[WilliamChen-luckbob]

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

it seems the official plugin of Gemini not support the video models? that's quite a problem...

2. Additional context or comments

No response

3. Can you help us with this feature?

• I am interested in contributing to this feature.

[dosubot]

The Gemini plugin does not currently support Veo2 or Veo3 video models. While the plugin offers some video capabilities for certain Gemini models (like Gemini 2.5 Flash), there are no references to Veo2 or Veo3 in the code, documentation, or issues. The plugin's multimodal support is limited to the Gemini models exposed by Google's GenAI API, and Veo2/Veo3 integration is not present or planned at this time reference reference. If you want to contribute support for Veo2 or Veo3, you would need to extend the model config files and provider logic to recognize and handle these models.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[WilliamChen-luckbob]

@dosu
I can help integrate support for Veo2 and Veo3, but I need you to provide me with some detailed development guidelines—such as the location of the configuration files for the Gemini model plugin, configuration requirements, which package(s) the code logic should be placed in, what code logic is required, and the requirements for final unit testing, among others. And also how to deploy the latest plugin and inplement it in my project.

[dosubot]

Here’s a step-by-step guide for integrating Veo2 and Veo3 support into the Gemini plugin:

1. Model Configuration Files:

   • Create a new YAML file for each model (e.g., veo2.yaml, veo3.yaml) in models/gemini/models/llm/.
   • Use existing files like gemini-2.5-flash.yaml as templates. Define the model name, label, model_type, features (include video), model_properties, parameter_rules, and pricing.
   • Add the new model names to models/gemini/models/llm/_position.yaml so they appear in the model list.
   • Example features section:

     features:
       - tool-call
       - multi-tool-call
       - agent-thought
       - vision
       - stream-tool-call
       - document
       - video
       - audio

   • Set parameter rules for temperature, top_p, max_output_tokens, etc., as needed for Veo2/Veo3.

2. Provider Logic:

   • The main logic is in models/gemini/models/llm/llm.py (GoogleLargeLanguageModel).
   • This file already handles multimodal content, including video uploads and MIME types. Unless Veo2/Veo3 have unique API requirements, you likely won’t need to change this logic—just ensure your YAML config matches the expected parameters and features.
   • If Veo2/Veo3 require special handling, extend the relevant methods (e.g., _set_chat_parameters, _set_response_modalities) to support any new parameters or modalities.

3. Provider Configuration:

   • The provider config is in models/gemini/provider/google.yaml.
   • This references the model sources and credential schema. No changes are needed here unless you add new credential requirements.

4. Manifest and Dependencies:

   • Update models/gemini/manifest.yaml to bump the plugin version after your changes.
   • If Veo2/Veo3 require a newer Google GenAI SDK, update models/gemini/requirements.txt and pyproject.toml accordingly.

5. Unit and Integration Testing:

   • Tests are in models/gemini/models/tests/.
   • Follow the structure in TEST_INSTRUCTIONS.md for running and extending tests.
   • Add or update tests to cover Veo2/Veo3, especially for video input/output.
   • Use pytest for both unit (no API key) and integration (API key required) tests.
   • Example:

     uv run pytest models/tests/

6. Deployment and Usage:

   • After making changes, update the manifest version and ensure dependencies are installed.
   • Install the plugin in your Dify instance, configure the API key in Model Provider settings, and verify that Veo2/Veo3 appear in the model list.
   • For best performance with video, set the Files URL if using url mode for MULTIMODAL_SEND_FORMAT in the provider settings.

If Veo2/Veo3 have unique API endpoints or parameters not covered by the current Gemini logic, you’ll need to adjust the provider code accordingly. Otherwise, the process above matches how new Gemini models are typically added.
References:

• Gemini model YAML example
• Provider logic
• Provider config
• Testing instructions

Let me know if you need a sample YAML or have questions about any step!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[WilliamChen-luckbob]

@dosu
Now, I have a question: I need to modify an existing plugin, not create a new plugin project. However, when I refer to the official documentation for creating a new model plugin, I notice that the plugin client doesn't seem to have an operation for this (modifying an existing one or run it). So, how should I conduct actual testing and running? After modifying the code, how do I install this plugin in my Dify environment?

[dosubot]

To test and run a modified existing plugin in Dify, you should first make your code and config changes locally. Run unit and integration tests (for example, with pytest) in the plugin repo to verify your changes before deployment.

To install your modified plugin in your Dify environment, you need to package it (as a dify_pkg binary or similar format), then upload it using the plugin management system. Dify uses a dedicated plugin daemon service to manage plugins. After packaging, upload your plugin via the PluginInstaller (Python class) or through the Dify UI/API, and trigger an install or upgrade operation. There is no hot-reload—after each code change, you must repackage and reinstall the plugin for changes to take effect. The plugin daemon handles storage, installation, and versioning, so you don’t need to restart the whole Dify stack—just update the plugin package and reinstall or upgrade it (reference).

For best practices: always test in a development or staging environment before deploying to production, and check for missing dependencies or installation errors using the plugin management tools.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[WilliamChen-luckbob]

@dosu
Another question: The API parameters of Veo3 and Veo3.1 differ from those of regular Gemini LLMs. Do I need to create a dedicated LLM node to utilize the features of Veo3.1?

[dosubot]

You don't need to create a dedicated LLM node or class for Veo3.1, even if its API parameters differ from regular Gemini LLMs. The Gemini plugin is designed to handle new models by extending the YAML config and adding conditional logic in the shared provider class (GoogleLargeLanguageModel). Unique parameters (like those for Gemini 3 series) are typically supported by updating the model YAML and enhancing methods such as _set_chat_parameters or _set_response_modalities within the same class. Only if the model's API is fundamentally incompatible with the shared logic would a new node/class be needed, but that's not the current pattern for Gemini plugin development citation.

So, to support Veo3.1, update the YAML config for the model and extend the shared logic as needed for its parameters and features.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[WilliamChen-luckbob]

@dosu
How can I dynamically introduce parameters such as video length and negative prompts into the LLM without modifying the node? For example, if these two pieces of data are stored in the context variables, how should I pass them to the LLM?

[dosubot]

You can dynamically introduce parameters like video length and negative prompts into the LLM without modifying the node by leveraging how Dify workflows and the Gemini plugin handle parameters:

• In Dify, context variables (from the VariablePool) can be mapped to model parameters at runtime. The LLM node collects variables referenced in your workflow (via variable selectors, prompt config, or jinja2 variables) and merges them into the model_parameters dictionary before invoking the LLM. This means any value present in the context can be passed as a parameter to the LLM if you reference it in your workflow configuration or prompt template citation.

• To support new parameters like video_length or negative_prompt, add them to the parameter_rules section of your Gemini model YAML config. Then, in your workflow, ensure these variables are available in the context and referenced in your node's completion_params or prompt config. The Gemini plugin will pick them up from model_parameters and use them if you handle them in the provider logic citation.

• For advanced scenarios, you can register a callback (see core/model_runtime/callbacks/base_callback.py) to intercept and mutate model_parameters before the LLM call. This lets you inject or transform parameters from context variables dynamically, without touching the node or core logic citation.

In summary: expose your desired parameters in the model YAML, ensure your workflow extracts the relevant context variables, and map them to model_parameters (either directly or via a callback). The Gemini plugin will forward these to the LLM as long as they're present in model_parameters and handled in the config setters citation.

If you want a concrete example or YAML snippet for Veo3.x, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[WilliamChen-luckbob]

@dosu
During the process of setting up remote debugging for my self-hosted Dify instance, executing the application through the main function yields no error logs, and the debugging plugins are not visible in the Dify plugin management dashboard.
I did configure the api secret copied from dify plugin page, and the host and port are correct.

[dosubot]

If your debugging plugin isn't showing up in the Dify dashboard and there are no error logs, here are the most common causes and fixes:

• Make sure INSTALL_METHOD is set to remote in your plugin's environment. If it's set to local, the plugin only emits heartbeat events and won't register with Dify or appear in the dashboard reference.
• Double-check your .env and Docker configs: avoid using localhost or 127.0.0.1 for service endpoints in Docker. Use your host's internal IP or host.docker.internal so containers can communicate reference.
• Confirm that the Dify core and plugin daemon are running, reachable, and on the same network. Version mismatches between Dify and the plugin daemon can cause silent failures—make sure both are up to date reference.
• Check your plugin's manifest.yaml and provider implementation for required fields and methods (especially _validate_credentials). Formatting errors or missing methods can cause blank pages or missing plugins in the dashboard reference.
• If you recently upgraded or migrated your environment, run the migration commands to extract, install, and migrate plugin data:

  uv run flask extract-plugins --workers=20
  uv run flask install-plugins --workers=2
  uv run flask migrate-data-for-plugin
  

  This ensures plugins and models are properly registered reference.
• If you still see no error logs, check both the Dify app and plugin daemon container logs for backend errors. Sometimes silent failures are due to network misconfiguration or missing migration steps.
• As a last resort, try packaging your plugin as a .difypkg file and uploading it via the "Install via Local File" option in the Dify UI to rule out remote registration issues reference.

If none of these steps work, please share your exact .env, the command sequence you use to start the plugin, and any relevant logs for deeper diagnosis.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[WilliamChen-luckbob]

@dosu
I start the service via Docker Compose, and the existing plugins in the marketplace can be installed without any issues. I have configured the relevant plugin debugging settings in the .env file of Dify as follows:
PLUGIN_DEBUGGING_HOST=0.0.0.0
PLUGIN_DEBUGGING_PORT=5003
EXPOSE_PLUGIN_DEBUGGING_HOST=0.0.0.0
EXPOSE_PLUGIN_DEBUGGING_PORT=5003
Subsequently, I modified the docker-compose-template.yaml file to proxy the 5003 port through Nginx (the 80 port was already set up with a reverse proxy, so I used another port to configure a reverse proxy for 5003).
After that, I regenerate the yaml file by ./generate_docker_compose and docker compose up again to restart the whole docker.
but the problem remains.
How can I verify that my plugin debugging service has started correctly?