Release 1.1.0 branch

content/docs/04.workflow-components/05.inputs.md

@@ -107,6 +107,7 @@ inputs:
     type: FILE
     displayName: "Upload a file"
     defaults: nsfile:///hello.txt
+    allowedFileExtensions: [".md", ".txt"]
 
   - id: json
     type: JSON
@@ -165,7 +166,7 @@ Here is the list of supported data types:
 - `DATE`: Must be a valid full [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) date without the timezone from a text string such as `2042-12-03`.
 - `TIME`: Must be a valid full [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) time without the timezone from a text string such as `10:15:30`.
 - `DURATION`: Must be a valid full [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) duration from a text string such as `PT5M6S`.
-- `FILE`: Either a file uploaded at execution time as `Content-Type: multipart/form-data` with `Content-Disposition: form-data; name="files"; filename="<input-id>"` (where `<input-id>` is the input name), or a default file referenced via the universal file protocol using `nsfile:///path/to/file` (namespace file) or `file:///path/to/file` (local file from an allowed path).
+- `FILE`: Either a file uploaded at execution time as `Content-Type: multipart/form-data` with `Content-Disposition: form-data; name="files"; filename="<input-id>"` (where `<input-id>` is the input name), or a default file referenced via the universal file protocol using `nsfile:///path/to/file` (namespace file) or `file:///path/to/file` (local file from an allowed path). `FILE` type inputs also have the `allowedFileExtensions` property to control which types of files can be uploaded.
 - `JSON`: Must be a valid JSON string and will be converted to a typed form.
 - `YAML`: Must be a valid YAML string.
 - `URI`: Must be a valid URI and will be kept as a string.
@@ -182,6 +183,7 @@ Below is the list of available properties for all inputs regardless of their typ
 - `type`: The data type of the input parameter, as described in the previous section.
 - `required`: Whether the input is required. If `true` and neither a default nor a runtime value is provided, the execution will not be created.
 - `defaults`: The default value that is used if no custom input value is provided at runtime; this value must be provided as a string and will be set to the desired data type specified using the `type` property.
+- `prefill`: Starts with an initial value that can be cleared or set to `null` when the input is not required. Like an editable default, it allows workflows to support optional inputs that start with a suggestion but can still be reset to `null` at runtime.
 - `dependsOn`: Makes the input dependent on other inputs that must be provided first.
 - `displayName`: Label shown in the UI instead of the `id`.
 - `description`: Markdown description for the input.

content/docs/06.enterprise/04.scalability/apps.md

@@ -130,6 +130,23 @@ access:
     - Admins
 ```
 
+### Customize the Apps Catalog
+
+You can customize your Apps Catalog to align with organization branding by navigating to the **Administration** tab and then **Tenants->Apps Catalog**.
+
+![Apps Catalog Customization](/docs/enterprise/apps/apps-catalog-customization.png)
+
+Here, you can give your catalog a display title, set a primary banner display color, and upload an image for banner (typically an organization logo).
+
+:::alert{type="info"}
+Currently, the uploaded banner display image must be an `.svg` file.
+:::
+
+Once saved, navigate to the Apps Catalog, and see your branding:
+
+![Apps Catalog Branding](/docs/enterprise/apps/customized-catalog.png)
+
+From the Apps Catalog, you can also access the customization settings directly at any time by clicking on the **gear icon**.
 
 ---
 
@@ -139,6 +156,34 @@ You can add custom tags to organize and filter apps in the App Catalog. For exam
 
 ---
 
+## App Thumbnails
+
+Design Apps with thumbnails to clearly display their intended use case or function to catalog users. To add a thumbnail to your app, upload an image file as a [namespace file](../../05.concepts/02.namespace-files.md) to the same namespace as the App's connected flow. For example, add an `.svg` (it can also be `.jpg`, `.png`, or other image file extension) to the `company.team` namespace. The example below adds `kestra-icon.svg`.
+
+![Image Namespace File](/docs/enterprise/apps/app-namespace-file.png)
+
+In your app code, add the `thumbnail` string property and point it towards the correct namespace file using `nsfiles:///<your-file>`. For example:
+
+```yaml
+id: request_data_form
+type: io.kestra.plugin.ee.apps.Execution
+displayName: Form to request and download data
+namespace: company.team
+flowId: get_data
+thumbnail: "nsfiles:///kestra-icon.svg" # Point this property to the correct namespace file.
+access: 
+  type: PRIVATE
+tags:
+  - Reporting
+  - Analytics
+```
+
+Once added, navigate to the Apps Catalog, and a new thumbnail will display on the connected app to help designate its use case:
+
+![App with thumbnail](/docs/enterprise/apps/app-with-icon.png)
+
+---
+
 ## App URL
 
 Each app has a unique URL that you can share with others. When someone opens the URL, they will see the app and can submit requests. You can share the URL with team members, customers, or partners to let them interact with your Kestra workflows.

content/docs/08.ui/00.dashboard.md

@@ -28,6 +28,10 @@ Dashboards provide a load of useful data right at your finger tips, including:
 
 Dashboards let you define custom queries and charts to visualize data on your executions, logs, and metrics. Rather than relying only on the default dashboard on Kestra’s home screen, you can create a custom dashboard with charts that answer specific questions and track key metrics. Each chart's configuration can be modified individually using the pencil icon in the dashboard view.
 
+:::alert{type="info"}
+Check out the [No-Code Dashboards guide](../no-code/no-code-dashboards.md) to know more about building Dashboards without touching YAML.
+:::
+
 ### Chart types
 
 Dashboards support data visualization charts like pie and bar graphs, temporal data visualizations such as time series charts, tabular representations, KPI trend charts, as well as textual displays using Markdown. Each chart type is composed of `chartOptions` and `data`.

content/docs/08.ui/02.executions.md

@@ -27,12 +27,20 @@ The **Gantt** tab visualizes each task's duration. From this interface, you can
 
 ![Kestra User Interface Execution Gantt](/docs/user-interface-guide/27-Executions-Gantt.png)
 
+The **Gantt** view displays all successful and failed tasks in the execution. For failed tasks, you can open the task and click the three dots to **"Fix with AI"**. This option reopens the flow editor with the [AI Copilot](../ai-tools/ai-copilot.md) prompted to help resolve any issues with the task.
+
+![Fix with AI](/docs/user-interface-guide/fix-with-ai-gantt.png)
+
 ## Logs
 
 The **Logs** tab gives access to a task's logs. You can filter by log level, copy logs into your clipboard, or download logs as a file.
 
 ![Kestra User Interface Execution Log](/docs/user-interface-guide/28-Executions-Logs.png)
 
+For failed tasks, click the three dots to **"Fix with AI"**. This option reopens the flow editor with the [AI Copilot](../ai-tools/ai-copilot.md) prompted to help resolve any issues with the task.
+
+![Fix with AI](/docs/user-interface-guide/fix-with-ai-logs.png)
+
 ## Topology
 
 Similar to the Editor view, you can see your execution's topology. **Topology** provides a graphical view to access specific task logs, replay certain tasks, or change task status.

content/docs/11.migration-guide/1.1.0/foreach-item.md

@@ -0,0 +1,11 @@
+---
+title: ForEachItem now starts iteration at 0 instead of 1
+icon: /docs/icons/migration-guide.svg
+release: 1.1.0
+editions: ["OSS", "EE"]
+---
+
+## Breaking Change
+
+`ForEachItem` now starts iteration at 0 instead of 1 to align with the iteration starting value of `ForEach`.
+If you use {{taskrun.iteration}} in your flow with a `ForEachItem` the starting value is now 0 instead of 1.

content/docs/11.migration-guide/1.1.0/index.md

@@ -0,0 +1,10 @@
+---
+title: 1.1.0
+icon: /docs/icons/migration-guide.svg
+release: 1.1.0
+---
+
+Deprecated features and migration guides for 1.1.0 and onwards.
+
+::ChildCard
+::

content/docs/11.migration-guide/1.1.0/kv-secrets-metadata-migration.md

@@ -0,0 +1,50 @@
+---
+title: Key-value Store and Secrets Metadata Migration
+icon: /docs/icons/migration-guide.svg
+release: 1.1.0
+editions: ["OSS", "EE"]
+---
+
+## Overview
+
+In version **1.1.0**, we improved the backend logic that powers **Key-Value Pairs** and **Secrets** search in the Kestra UI.  
+Previously, the UI fetched *all* stored pairs, which could become resource-intensive and inefficient in environments with a large number of entries.  
+
+To enhance performance and scalability, this release introduces **metadata indexing** that allows the backend to query these resources more efficiently.
+
+---
+
+## Impact
+
+Because of this change, you must run a metadata migration when upgrading to version **1.1.0** (or later).  
+This ensures existing Key-Value and Secrets data are correctly indexed for the new query structure.
+
+When upgrading, include the migration command `- /app/kestra migrate metadata` in your startup configuration.
+For example, if you’re using **Docker Compose**, start your container with the newest version image and add the migration script in `commands` as follows:
+
+```yaml
+kestra:
+    image: registry.kestra.io/docker/kestra:latest
+    command:
+        - /app/kestra migrate metadata kv
+        - /app/kestra migrate metadata secrets
+```
+
+Once the migration is complete, the container will stop automatically. You can then move back to the usual command to run the server:
+
+```yaml
+kestra:
+    image: registry.kestra.io/docker/kestra:latest
+    command:
+        - server standalone --worker-thread=128
+```
+
+Similarly, for Kubernetes installations, run a pod with the migration script (`- /app/kestra migrate metadata kv && /app/kestra migrate metadata secrets`), so the KV Store and Secrets databases are updated. Then, restart your normal pod for Kestra server components without the script.
+
+:::alert{type="warning"}
+If you upgrade to **1.1.0** without running the migration script, the **Key-Value Store** and **Secrets** pages in the UI will appear empty.  
+This is only a **UI issue** — your flows and tasks will continue to run normally and access their values as expected.  
+
+To fix the UI display, simply run the migration command above.  
+It’s safe to execute this migration **retroactively** after the upgrade if needed.
+:::

content/docs/11.migration-guide/1.1.0/prefill-inputs.md

@@ -0,0 +1,33 @@
+---
+title: New `prefill` Property for Inputs
+icon: /docs/icons/migration-guide.svg
+release: 1.1.0
+editions: ["OSS", "EE"]
+---
+
+## Overview
+
+A new `prefill` property has been added to input definitions to let users start with an initial value that can be cleared or set to `null` when the input is not required.
+
+**What changed:**
+Inputs can now define a `prefill` value, which works like an editable default. Unlike `defaults`, a `prefill` value does not persist if the user removes it. This allows workflows to support optional inputs that start with a suggestion but can still be reset to `null` at runtime.
+
+**Impact:**
+While not a breaking change, this update clarifies how `required`, `defaults`, and `prefill` behave together:
+
+* `prefill` and `defaults` cannot be used on the same input.
+* Use `prefill` when `required: false` and the user should be able to clear the value.
+* Use `defaults` when `required: true` or when the value must always have a non-null default.
+* If `defaults` is used with `required: false`, the value will still reset to the default when cleared, which may not be desired; use `prefill` rather than `defaults` for those scenarios.
+
+**Example:**
+
+```yaml
+inputs:
+  - id: nullable_string_with_prefilled_default
+    type: STRING
+    prefill: "This is a prefilled value you can remove (set to null if needed)"
+    required: false
+```
+
+**Migration:** No migration is required. For optional inputs that previously used `defaults` but need to allow clearing or null values, switch to using `prefill`.

content/docs/11.migration-guide/1.1.0/task-runs-ui.md

@@ -0,0 +1,20 @@
+---
+title: Task Runs UI Page Removed
+icon: /docs/icons/migration-guide.svg
+release: 1.1.0
+editions: ["EE"]
+---
+
+## Overview
+
+The **Task Runs** page has been removed from the Enterprise Edition UI.
+
+**Reason for removal:**
+* The page presented confusing granularity (task-level runs displayed on execution-level detail pages)
+* Filters were incomplete, and performance degraded when handling large datasets
+* The feature was only available on the Kafka & Elasticsearch backend, causing confusion among other customers
+* Customer interviews confirmed the page was not being actively used.
+
+**Impact:**
+* No replacement is required, as all relevant execution and task run details remain accessible through the Execution detail view.
+* If you previously accessed Task Runs, use the **Executions** page and drill down into individual task runs through Gantt and Logs views for task-level information.

content/docs/11.migration-guide/1.1.0/webhook-response.md

@@ -0,0 +1,23 @@
+---
+title: Webhook Execution API Return Type Changed
+icon: /docs/icons/migration-guide.svg
+release: 1.1.0
+editions: ["OSS", "EE"]
+---
+
+## Overview
+
+The return type of the Webhook Execution API endpoint has been updated from a **typed response** to a **generic response** to support broader use cases and improve extensibility.
+
+**What changed:** The API method previously returned a strongly typed `WebhookResponse` object. It now returns a generic HTTP response body (`HttpResponse<?>`).
+
+**Impact:** Any custom integrations, SDK consumers, or extensions that previously relied on the `WebhookResponse` type in the response body will need to adjust their handling logic:
+* Direct access to `WebhookResponse` methods or fields will no longer compile.
+* You must handle the response body dynamically and verify its type at runtime if necessary.
+
+**Migration:**
+* Treat the HTTP response body as a generic object.
+* Add runtime type checks before casting if your code depends on specific response fields.
+* Update any logic that assumes a fixed `WebhookResponse` structure.
+
+This change ensures greater flexibility in future webhook response handling but requires updates to any consuming code that previously depended on a fixed response type.

content/docs/ai-tools/ai-copilot.md

@@ -30,7 +30,7 @@ kestra:
       api-key: YOUR_GEMINI_API_KEY
 ```
 
-Replace `api-key` with your Google Gemini API key, and Copilot will appear in the top right corner of the flow editor. Optionally, you can add the following properties to your configuration:
+Replace `api-key` with your Google Gemini API key, and Copilot will appear in the top right corner of the flow editor. Optionally, you can add the following properties to your configuration (not all properties may be included with every provider):
 
 - `temperature`: Controls randomness in responses — lower values make outputs more focused and deterministic, while higher values increase creativity and variability.
 - `topP` (nucleus sampling): Ranges from 0.0–1.0; lower values (0.1–0.3) produce safer, more focused responses for technical tasks, while higher values (0.7–0.9) encourage more creative and varied outputs.
@@ -39,6 +39,8 @@ Replace `api-key` with your Google Gemini API key, and Copilot will appear in th
 - `logRequests`: Creates logs in Kestra for LLM requests.
 - `logResponses`: Creates logs in Kestra for LLM responses.
 - `baseURL`: Specifies the endpoint address where the LLM API is hosted.
+- `clientPem`: CA PEM file to add a custom CA without `trustAll`. Usually not needed since hosts already trust the CA.
+- `caPem`: (Required for mTLS) PEM bundle with client cert + private key (e.g., `cat client.crt.pem client.key.pem > client-bundle.pem`). Used for mutual TLS.
 
 ![AI Copilot](/docs/ai-tools/ai-copilot.png)
 
@@ -123,7 +125,7 @@ To get started with Copilot, here are some example prompts to test, iterate on,
 
 ## Enterprise Edition Copilot configurations
 
-Enterprise Edition users can configure any LLM provider, including Amazon Bedrock, Anthropic, Azure OpenAI, DeepSeek, Google Gemini, Google Vertex AI, Mistral, OpenAI, and all open-source models supported by Ollama. Each configuration has slight differences, so make sure to adjust for your provider.
+Enterprise Edition users can configure any LLM provider, including Amazon Bedrock, Anthropic, Azure OpenAI, DeepSeek, Google Gemini, Google Vertex AI, Mistral, OpenAI, OpenRouter, and all open-source models supported by Ollama. Each configuration has slight differences, so make sure to adjust for your provider.
 
 ### Amazon Bedrock
 
@@ -247,5 +249,5 @@ kestra:
     openrouter:
       api-key: OPENROUTER_API_KEY
       base-url: "https://openrouter.ai/api/v1"
-      model-name: x-ai/grok-beta
+      model-name: "anthropic/claude-sonnet-4"
 ```

content/docs/configuration/index.md

@@ -2101,3 +2101,15 @@ Optional parameters:
 - `base-url`
 
 **Enterprise Edition** supports multiple providers (Bedrock, Anthropic, Azure OpenAI, DeepSeek, Gemini, Vertex AI, Mistral, OpenAI, and Ollama). See [AI Copilot](../ai-tools/ai-copilot.md#enterprise-edition-copilot-configurations).
+
+## Air-gapped Kestra Instance (EE)
+
+To keep your Kestra Instance offline, you can use the following in your Kestra configuration to alter blueprint management and remove UI components that rely on external APIs. The UI adapts fully: blueprints fetch from the Kestra API, YouTube embeds hide without internet, fonts fall back to local versions, and internet-dependent sidebar features hide automatically. Kestra runs smoothly in completely isolated environments.
+
+```yaml
+kestra:
+  ee:
+    airgapped: true
+```
+
+For Enterprise users, check out the [Custom Links configuration](#add-custom-links-to-kestra-ui-ee) to add your own documentation and resources to the Kestra UI sidebar if needed.