diff --git a/content/docs/04.workflow-components/05.inputs.md b/content/docs/04.workflow-components/05.inputs.md index cbc55b33b45..e1738d68a23 100644 --- a/content/docs/04.workflow-components/05.inputs.md +++ b/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=""` (where `` 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=""` (where `` 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. diff --git a/content/docs/06.enterprise/04.scalability/apps.md b/content/docs/06.enterprise/04.scalability/apps.md index f054d93c097..aab7123e266 100644 --- a/content/docs/06.enterprise/04.scalability/apps.md +++ b/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:///`. 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. diff --git a/content/docs/08.ui/00.dashboard.md b/content/docs/08.ui/00.dashboard.md index fa6b56b690a..82641accd88 100644 --- a/content/docs/08.ui/00.dashboard.md +++ b/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`. diff --git a/content/docs/08.ui/02.executions.md b/content/docs/08.ui/02.executions.md index d261ca251eb..20c7c45d1e5 100644 --- a/content/docs/08.ui/02.executions.md +++ b/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. diff --git a/content/docs/11.migration-guide/1.1.0/foreach-item.md b/content/docs/11.migration-guide/1.1.0/foreach-item.md new file mode 100644 index 00000000000..a27b33f0c80 --- /dev/null +++ b/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. diff --git a/content/docs/11.migration-guide/1.1.0/index.md b/content/docs/11.migration-guide/1.1.0/index.md new file mode 100644 index 00000000000..77ceb09d0fd --- /dev/null +++ b/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 +:: diff --git a/content/docs/11.migration-guide/1.1.0/kv-secrets-metadata-migration.md b/content/docs/11.migration-guide/1.1.0/kv-secrets-metadata-migration.md new file mode 100644 index 00000000000..075dea24570 --- /dev/null +++ b/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. +::: diff --git a/content/docs/11.migration-guide/1.1.0/prefill-inputs.md b/content/docs/11.migration-guide/1.1.0/prefill-inputs.md new file mode 100644 index 00000000000..7907789fe45 --- /dev/null +++ b/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`. diff --git a/content/docs/11.migration-guide/1.1.0/task-runs-ui.md b/content/docs/11.migration-guide/1.1.0/task-runs-ui.md new file mode 100644 index 00000000000..91d8277a5e8 --- /dev/null +++ b/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. diff --git a/content/docs/11.migration-guide/1.1.0/webhook-response.md b/content/docs/11.migration-guide/1.1.0/webhook-response.md new file mode 100644 index 00000000000..524e5536393 --- /dev/null +++ b/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. diff --git a/content/docs/ai-tools/ai-copilot.md b/content/docs/ai-tools/ai-copilot.md index abbf465dd77..07377d35d01 100644 --- a/content/docs/ai-tools/ai-copilot.md +++ b/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" ``` diff --git a/content/docs/configuration/index.md b/content/docs/configuration/index.md index 30d473523ad..0390d792288 100644 --- a/content/docs/configuration/index.md +++ b/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. diff --git a/content/docs/no-code/no-code-flow-building.md b/content/docs/no-code/01.no-code-flow-building.md similarity index 100% rename from content/docs/no-code/no-code-flow-building.md rename to content/docs/no-code/01.no-code-flow-building.md diff --git a/content/docs/no-code/02.no-code-dashboards.md b/content/docs/no-code/02.no-code-dashboards.md new file mode 100644 index 00000000000..90122e2ad82 --- /dev/null +++ b/content/docs/no-code/02.no-code-dashboards.md @@ -0,0 +1,97 @@ +--- +title: No-Code Dashboards +icon: /docs/icons/ui.svg +editions: ["OSS", "EE", "Cloud"] +--- + +Build Dashboards without writing YAML. + +## Overview + +The No-Code Dashboard editor lets you design Kestra Dashboards directly in the UI using structured forms. It’s ideal for teams that want to create insightful dashboards quickly, empower non-developers to contribute, and maintain a smooth handoff to code. +You can switch between No-Code and YAML views at any time — the editor automatically generates schema-validated YAML and stays synchronized with the live preview and documentation panels. + +--- + +## Why choose No-Code (or combine it with code) + +- **Speed & accessibility**: Start creating dashboards without writing YAML — perfect for analysts, operators, or anyone new to Kestra. +- **Visual clarity**: Live previews and real-time updates let you “see” your dashboard evolve as you edit. +- **Consistency & governance**: Form-based configuration aligns with widget schemas and validation rules, ensuring consistent data representation and design standards across teams. +- **No ceiling**: When you need advanced customization, switch to YAML to add filters, queries, or layout logic — all while keeping everything in sync within the same editor. + +## The Multi-Panel Dashboard Editor + +- **No-Code View:** Form-based editing of dashboard widgets, layout, and data sources. Changes automatically generate YAML in real time. +- **Dashboard Code View (YAML):** Full-featured editor with autocompletion, validation, and file sidebar. +- **Charts Tab:** Displays all currently saved charts in the dashboard, providing a complete overview of existing visualizations. +- **Preview Tab:** Shows in-progress charts as you design, allowing you to instantly review updates before saving. +- **Documentation & Blueprints Panels:** In-context documentation and ready-to-use dashboard examples to help you get started faster. + +## Interactive demo + +
+ +## Quick Start: Create Your First Dashboard in No-Code + +To start building dashboards, navigate to the **Dashboards** tab. Click the **Default Dashboard** button at the top of the page (the name may vary depending on your instance) and select **+ Create Dashboard**. + +![Create Dashboard](/docs/no-code/create-dashboard.png) + +Next, you’ll see the Dashboard YAML editor. Select the **No Code** tab to open the No-Code panel editor. It will appear alongside the YAML editor so you can view both as you work. + +![No-Code Dashboard Editor](/docs/no-code/no-code-dashboards.png) + +## Build a chart + +This example walks through creating a dashboard for the last year, starting with an **Executions Success Ratio KPI Chart**. +Begin by giving your dashboard an ID, title, description, and time window. If the YAML editor is open, you’ll see every change in the No-Code form instantly reflected in code. + +![Time Window](/docs/no-code/time-window.png) + +Once those fields are set, click **+ Add** in the **charts** block to create your first chart. +The first step is to choose a chart type. In this example, select **KPI Chart**. +Each chart type has its own set of options and data representations — see the [Chart Plugin documentation](/plugins/core/chart) for full details. +While editing, you can open the **Documentation** tab to view chart-specific guidance without leaving the editor. + +![Documentation Multi-Panel](/docs/no-code/documentation-view.png) + +After selecting **KPI Chart**, give the chart an ID and select the type of data. +In this example, choose **Executions**. To ensure all executions are captured, set the `field` property to `ID` and the `agg` property to `COUNT`. Optionally, set a display name or label for readability. + +![KPI Chart](/docs/no-code/kpi-chart.png) + +Next, add a filter for the execution data. Click **+ Add** under the data numerator section. +For an execution success ratio, choose `IN` for the `type`, with `values` set to `STRING`. +Add the value `SUCCESS` so the chart only considers successful executions. Under **Optional Properties**, set the `field` to `STATE`. + +![Add Numerator](/docs/no-code/add-numerator.png) + +Now that the correct data is connected to the chart, return to the `charts` No-Code tab and open **Optional Properties**. +Set the `displayName` and change `numberType` to `PERCENTAGE` so the chart shows a ratio rather than a flat count. +Adjust the `width` to your preference — a value of `3` is recommended for this type of chart. + +![Chart Options](/docs/no-code/chart-options.png) + +Once configured, open the **Preview** tab to view your chart. +If satisfied with the result, click **Save** and continue building additional charts. +For example, you can copy the YAML generated for the KPI Success Chart, paste it into the YAML editor, and replace `SUCCESS` with `FAILED` to create a chart for the execution failure ratio. + +![Chart Preview](/docs/no-code/chart-preview.png) + +For more example charts, see the [Dashboards documentation page](../08.ui/00.dashboard.md#create-a-new-custom-dashboard-as-code). + +## Best Practices + +### Organize dashboards by purpose +Group related charts into dashboards that serve a clear goal — for example, separate dashboards for **system health**, **execution performance**, and **user activity**. This keeps data focused and easier to interpret. + +### Use consistent naming conventions +Use clear, descriptive IDs for dashboards and charts. A good pattern is `team_metric_type`, such as `dataops_executions_latency` or `marketing_pipeline_health`. +Consistent naming helps when searching, versioning, or exporting dashboards as code. + +### Leverage YAML for advanced logic +When you need to reuse queries, apply filters dynamically, or control layout programmatically, switch to YAML mode. If a chart is similar to another with a small tweak of the filter or field, copy and paste the YAML to quickly change the field rather than rebuild with No-Code forms. The No-Code editor keeps everything synchronized, so you can safely go back and forth without losing your structure. + +### Preview frequently +Use the **Preview** tab to verify data bindings and chart outputs before saving. This ensures filters and aggregations are configured correctly and helps catch mismatched fields early. diff --git a/public/docs/enterprise/apps/app-namespace-file.png b/public/docs/enterprise/apps/app-namespace-file.png new file mode 100644 index 00000000000..d60004f6478 Binary files /dev/null and b/public/docs/enterprise/apps/app-namespace-file.png differ diff --git a/public/docs/enterprise/apps/app-with-icon.png b/public/docs/enterprise/apps/app-with-icon.png new file mode 100644 index 00000000000..2af299d7029 Binary files /dev/null and b/public/docs/enterprise/apps/app-with-icon.png differ diff --git a/public/docs/enterprise/apps/apps-catalog-customization.png b/public/docs/enterprise/apps/apps-catalog-customization.png new file mode 100644 index 00000000000..1c00ffc1b8d Binary files /dev/null and b/public/docs/enterprise/apps/apps-catalog-customization.png differ diff --git a/public/docs/enterprise/apps/customized-catalog.png b/public/docs/enterprise/apps/customized-catalog.png new file mode 100644 index 00000000000..856c9e196ff Binary files /dev/null and b/public/docs/enterprise/apps/customized-catalog.png differ diff --git a/public/docs/no-code/add-numerator.png b/public/docs/no-code/add-numerator.png new file mode 100644 index 00000000000..2742059d320 Binary files /dev/null and b/public/docs/no-code/add-numerator.png differ diff --git a/public/docs/no-code/chart-options.png b/public/docs/no-code/chart-options.png new file mode 100644 index 00000000000..ae987ee5068 Binary files /dev/null and b/public/docs/no-code/chart-options.png differ diff --git a/public/docs/no-code/chart-preview.png b/public/docs/no-code/chart-preview.png new file mode 100644 index 00000000000..f60b53b86e1 Binary files /dev/null and b/public/docs/no-code/chart-preview.png differ diff --git a/public/docs/no-code/create-dashboard.png b/public/docs/no-code/create-dashboard.png new file mode 100644 index 00000000000..53bedef2178 Binary files /dev/null and b/public/docs/no-code/create-dashboard.png differ diff --git a/public/docs/no-code/documentation-view.png b/public/docs/no-code/documentation-view.png new file mode 100644 index 00000000000..e2175e6c006 Binary files /dev/null and b/public/docs/no-code/documentation-view.png differ diff --git a/public/docs/no-code/kpi-chart.png b/public/docs/no-code/kpi-chart.png new file mode 100644 index 00000000000..acb3f365855 Binary files /dev/null and b/public/docs/no-code/kpi-chart.png differ diff --git a/public/docs/no-code/no-code-dashboards.png b/public/docs/no-code/no-code-dashboards.png new file mode 100644 index 00000000000..7cb04824298 Binary files /dev/null and b/public/docs/no-code/no-code-dashboards.png differ diff --git a/public/docs/no-code/time-window.png b/public/docs/no-code/time-window.png new file mode 100644 index 00000000000..f16ba83decd Binary files /dev/null and b/public/docs/no-code/time-window.png differ diff --git a/public/docs/user-interface-guide/fix-with-ai-gantt.png b/public/docs/user-interface-guide/fix-with-ai-gantt.png new file mode 100644 index 00000000000..c37163749ba Binary files /dev/null and b/public/docs/user-interface-guide/fix-with-ai-gantt.png differ diff --git a/public/docs/user-interface-guide/fix-with-ai-logs.png b/public/docs/user-interface-guide/fix-with-ai-logs.png new file mode 100644 index 00000000000..9f455e32ff9 Binary files /dev/null and b/public/docs/user-interface-guide/fix-with-ai-logs.png differ