diff --git a/.cursor/skills/documentation-routes/SKILL.md b/.cursor/skills/documentation-routes/SKILL.md new file mode 100644 index 00000000..c668f510 --- /dev/null +++ b/.cursor/skills/documentation-routes/SKILL.md @@ -0,0 +1,16 @@ +--- +name: documentation-routes +description: Regenerates documentation route metadata. Use whenever creating, editing, moving, renaming, or deleting documentation content, or when changing the documentation navigation and redirects. +--- + +# Documentation Routes + +After adding or updating any documentation content, run this command from the documentation repository root: + +```bash +make routes +``` + +Run it for content-only edits as well as page additions, deletions, moves, navigation changes, and redirect changes. + +Review `generated/routes.json` after the command finishes and include its relevant changes with the documentation update. If route generation fails, fix the failure and rerun `make routes` before completing the task. diff --git a/generated/routes.json b/generated/routes.json index f0d685ed..bddb8a83 100644 --- a/generated/routes.json +++ b/generated/routes.json @@ -87,6 +87,10 @@ "relPath": "/getting-started/advanced-config/sandboxing.md", "lastmod": "2026-08-06T14:42:58.000Z" }, + "/getting-started/advanced-config/edge-configuration": { + "relPath": "/getting-started/advanced-config/edge-configuration.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, "/getting-started/advanced-config/network-configuration": { "relPath": "/getting-started/advanced-config/network-configuration.md", "lastmod": "2025-03-12T14:59:41.000Z" @@ -105,11 +109,11 @@ }, "/api-reference/kubernetes/management-api-reference": { "relPath": "/api-reference/kubernetes/management-api-reference.md", - "lastmod": "2026-08-13T15:31:21.000Z" + "lastmod": "2026-08-29T16:32:07.000Z" }, "/api-reference/kubernetes/agent-api-reference": { "relPath": "/api-reference/kubernetes/agent-api-reference.md", - "lastmod": "2026-08-11T20:00:52.000Z" + "lastmod": "2026-08-29T16:32:07.000Z" }, "/api-reference/graphql": { "relPath": "/api-reference/graphql.md", @@ -141,7 +145,7 @@ }, "/plural-features/continuous-deployment/management-controller/deployment-settings": { "relPath": "/plural-features/continuous-deployment/management-controller/deployment-settings.md", - "lastmod": "2026-08-06T14:42:58.000Z" + "lastmod": "2026-08-29T22:15:14.000Z" }, "/plural-features/continuous-deployment/deployment-operator": { "relPath": "/plural-features/continuous-deployment/deployment-operator/index.md", @@ -173,11 +177,11 @@ }, "/plural-features/continuous-deployment/service-templating": { "relPath": "/plural-features/continuous-deployment/service-templating/index.md", - "lastmod": "2026-08-29T16:19:38.379Z" + "lastmod": "2026-08-29T22:15:22.702Z" }, "/plural-features/continuous-deployment/service-templating/supporting-liquid-filters": { "relPath": "/plural-features/continuous-deployment/service-templating/supporting-liquid-filters.md", - "lastmod": "2026-08-29T16:19:38.402Z" + "lastmod": "2026-08-29T22:15:22.724Z" }, "/plural-features/continuous-deployment/lua": { "relPath": "/plural-features/continuous-deployment/lua.md", @@ -271,21 +275,69 @@ "relPath": "/plural-features/service-catalog/contribution-program.md", "lastmod": "2025-03-12T14:59:41.000Z" }, + "/plural-features/workbenches": { + "relPath": "/plural-features/workbenches/index.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/workbenches/configuration": { + "relPath": "/plural-features/workbenches/configuration.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/workbenches/coding-agent": { + "relPath": "/plural-features/workbenches/coding-agent.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/workbenches/tools": { + "relPath": "/plural-features/workbenches/tools.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/workbenches/tools/datadog": { + "relPath": "/plural-features/workbenches/tools/datadog.md", + "lastmod": "2026-08-06T15:20:26.000Z" + }, + "/plural-features/workbenches/running-jobs": { + "relPath": "/plural-features/workbenches/running-jobs.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/workbenches/automation": { + "relPath": "/plural-features/workbenches/automation.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/workbenches/follow-up-automation": { + "relPath": "/plural-features/workbenches/follow-up-automation.md", + "lastmod": "2026-08-06T15:20:26.000Z" + }, + "/plural-features/workbenches/use-cases": { + "relPath": "/plural-features/workbenches/use-cases.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/policy-management": { + "relPath": "/plural-features/policy-management/index.md", + "lastmod": "2026-08-29T16:31:45.000Z" + }, + "/plural-features/policy-management/stack-policies": { + "relPath": "/plural-features/policy-management/stack-policies.md", + "lastmod": "2026-08-29T16:31:45.000Z" + }, + "/plural-features/policy-management/workbench-policies": { + "relPath": "/plural-features/policy-management/workbench-policies.md", + "lastmod": "2026-08-29T16:31:45.000Z" + }, + "/plural-features/policy-management/simulating-policies": { + "relPath": "/plural-features/policy-management/simulating-policies.md", + "lastmod": "2026-08-29T16:31:45.000Z" + }, + "/plural-features/policy-management/common-use-cases": { + "relPath": "/plural-features/policy-management/common-use-cases.md", + "lastmod": "2026-08-29T16:31:45.000Z" + }, "/plural-features/kubernetes-dashboard": { "relPath": "/plural-features/kubernetes-dashboard/index.md", "lastmod": "2025-03-12T14:59:41.000Z" }, "/plural-features/plural-ai": { "relPath": "/plural-features/plural-ai/index.md", - "lastmod": "2025-03-12T14:59:41.000Z" - }, - "/plural-features/plural-ai/setup": { - "relPath": "/plural-features/plural-ai/setup.md", - "lastmod": "2025-03-12T14:59:41.000Z" - }, - "/plural-features/plural-ai/architecture": { - "relPath": "/plural-features/plural-ai/architecture.md", - "lastmod": "2025-03-12T14:59:41.000Z" + "lastmod": "2026-08-29T22:15:14.000Z" }, "/plural-features/plural-ai/ai-agent": { "relPath": "/plural-features/plural-ai/ai-agent/index.md", @@ -293,7 +345,7 @@ }, "/plural-features/plural-ai/ai-agent/configure-agent": { "relPath": "/plural-features/plural-ai/ai-agent/configure-agent.md", - "lastmod": "2026-08-29T16:16:14.000Z" + "lastmod": "2026-08-29T16:31:45.000Z" }, "/plural-features/plural-ai/ai-agent/remote-browser": { "relPath": "/plural-features/plural-ai/ai-agent/remote-browser.md", @@ -303,17 +355,9 @@ "relPath": "/plural-features/plural-ai/sentinels.md", "lastmod": "2025-11-08T16:45:39.000Z" }, - "/plural-features/plural-ai/arch-diagram": { - "relPath": "/plural-features/plural-ai/arch-diagram.md", - "lastmod": "2026-01-05T19:58:20.000Z" - }, - "/plural-features/plural-ai/cost": { - "relPath": "/plural-features/plural-ai/cost.md", - "lastmod": "2025-03-12T14:59:41.000Z" - }, "/plural-features/plural-ai/multi-model-configuration": { "relPath": "/plural-features/plural-ai/multi-model-configuration.md", - "lastmod": "2025-10-15T00:52:41.000Z" + "lastmod": "2026-08-29T22:15:14.000Z" }, "/plural-features/flows": { "relPath": "/plural-features/flows/index.md", @@ -343,62 +387,6 @@ "relPath": "/plural-features/flows/scm-webhooks-and-pr-linking.md", "lastmod": "2025-05-27T02:01:02.000Z" }, - "/plural-features/workbenches": { - "relPath": "/plural-features/workbenches/index.md", - "lastmod": "2026-08-06T15:20:26.000Z" - }, - "/plural-features/workbenches/configuration": { - "relPath": "/plural-features/workbenches/configuration.md", - "lastmod": "2026-08-06T15:20:26.000Z" - }, - "/plural-features/workbenches/coding-agent": { - "relPath": "/plural-features/workbenches/coding-agent.md", - "lastmod": "2026-05-27T21:33:58.000Z" - }, - "/plural-features/workbenches/tools": { - "relPath": "/plural-features/workbenches/tools.md", - "lastmod": "2026-08-06T15:20:26.000Z" - }, - "/plural-features/workbenches/tools/datadog": { - "relPath": "/plural-features/workbenches/tools/datadog.md", - "lastmod": "2026-08-06T15:20:26.000Z" - }, - "/plural-features/workbenches/running-jobs": { - "relPath": "/plural-features/workbenches/running-jobs.md", - "lastmod": "2026-08-06T15:20:26.000Z" - }, - "/plural-features/workbenches/automation": { - "relPath": "/plural-features/workbenches/automation.md", - "lastmod": "2026-08-06T15:20:26.000Z" - }, - "/plural-features/workbenches/follow-up-automation": { - "relPath": "/plural-features/workbenches/follow-up-automation.md", - "lastmod": "2026-08-06T15:20:26.000Z" - }, - "/plural-features/workbenches/use-cases": { - "relPath": "/plural-features/workbenches/use-cases.md", - "lastmod": "2026-05-27T21:33:58.000Z" - }, - "/plural-features/policy-management": { - "relPath": "/plural-features/policy-management/index.md", - "lastmod": "2026-08-29T16:16:14.000Z" - }, - "/plural-features/policy-management/stack-policies": { - "relPath": "/plural-features/policy-management/stack-policies.md", - "lastmod": "2026-08-29T16:16:14.000Z" - }, - "/plural-features/policy-management/workbench-policies": { - "relPath": "/plural-features/policy-management/workbench-policies.md", - "lastmod": "2026-08-29T16:16:14.000Z" - }, - "/plural-features/policy-management/simulating-policies": { - "relPath": "/plural-features/policy-management/simulating-policies.md", - "lastmod": "2026-08-29T16:16:14.000Z" - }, - "/plural-features/policy-management/common-use-cases": { - "relPath": "/plural-features/policy-management/common-use-cases.md", - "lastmod": "2026-08-29T16:16:14.000Z" - }, "/plural-features/observability": { "relPath": "/plural-features/observability/index.md", "lastmod": "2025-05-10T04:27:39.000Z" @@ -593,7 +581,7 @@ }, "/plural-features/continuous-deployment/deployment-operator/deployment-settings": { "relPath": "/plural-features/continuous-deployment/management-controller/deployment-settings.md", - "lastmod": "2026-08-06T14:42:58.000Z" + "lastmod": "2026-08-29T22:15:14.000Z" }, "/deployments/operator/git-service": { "relPath": "/plural-features/continuous-deployment/git-service.md", @@ -664,20 +652,36 @@ "lastmod": "2025-03-12T14:59:41.000Z" }, "/ai/setup": { - "relPath": "/plural-features/plural-ai/setup.md", - "lastmod": "2025-03-12T14:59:41.000Z" + "relPath": "/plural-features/plural-ai/multi-model-configuration.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/plural-ai/setup": { + "relPath": "/plural-features/plural-ai/multi-model-configuration.md", + "lastmod": "2026-08-29T22:15:14.000Z" }, "/ai/architecture": { - "relPath": "/plural-features/plural-ai/architecture.md", - "lastmod": "2025-03-12T14:59:41.000Z" + "relPath": "/plural-features/plural-ai/index.md", + "lastmod": "2026-08-29T22:15:14.000Z" }, "/ai/cost": { - "relPath": "/plural-features/plural-ai/cost.md", - "lastmod": "2025-03-12T14:59:41.000Z" + "relPath": "/plural-features/plural-ai/index.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/plural-ai/architecture": { + "relPath": "/plural-features/plural-ai/index.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/plural-ai/arch-diagram": { + "relPath": "/plural-features/plural-ai/index.md", + "lastmod": "2026-08-29T22:15:14.000Z" + }, + "/plural-features/plural-ai/cost": { + "relPath": "/plural-features/plural-ai/index.md", + "lastmod": "2026-08-29T22:15:14.000Z" }, "/ai/overview": { "relPath": "/plural-features/plural-ai/index.md", - "lastmod": "2025-03-12T14:59:41.000Z" + "lastmod": "2026-08-29T22:15:14.000Z" }, "/deployments/pr/crds": { "relPath": "/plural-features/pr-automation/crds.md", @@ -717,10 +721,10 @@ }, "/management-api-reference": { "relPath": "/api-reference/kubernetes/management-api-reference.md", - "lastmod": "2026-08-13T15:31:21.000Z" + "lastmod": "2026-08-29T16:32:07.000Z" }, "/agent-api-reference": { "relPath": "/api-reference/kubernetes/agent-api-reference.md", - "lastmod": "2026-08-11T20:00:52.000Z" + "lastmod": "2026-08-29T16:32:07.000Z" } } \ No newline at end of file diff --git a/pages/getting-started/advanced-config/edge-configuration.md b/pages/getting-started/advanced-config/edge-configuration.md new file mode 100644 index 00000000..b812daaf --- /dev/null +++ b/pages/getting-started/advanced-config/edge-configuration.md @@ -0,0 +1,68 @@ +--- +title: Edge configuration +description: Configure Plural for large edge Kubernetes fleets +--- + +## Why Plural works at the edge + +Plural uses a pull-based architecture designed for clusters with restricted or intermittent connectivity. Each workload cluster runs a lightweight deployment agent that initiates connections to the management plane. The management plane does not need inbound network access to the cluster, and deployment credentials remain on the edge device. See the [architecture overview](/overview/architecture) for the complete design. + +![Plural's management-plane and workload-cluster architecture](/assets/deployments/architecture.png) + +The architecture is built for scale: + +* Agent communication is egress-only, so edge devices do not need public endpoints, inbound firewall rules, or a shared private network with the management plane. +* Plural's [Git-aware caching and distribution layer](/resources/architecture/gitops-architecture) fetches source repositories centrally, creates content-addressed deployment artifacts, and serves them through multiple cache levels. Agents normally fetch a small digest and download an artifact only when its content changes. This avoids multiplying source-control and management-plane traffic by the number of clusters. +* Plural has been deployed in production environments with more than 5,000 edge clusters. + +For very large fleets, tune the agent to reduce background traffic and persist its caches locally. + +## Reduce agent polling + +Apply an `AgentConfiguration` named `default` on every edge cluster. The following configuration keeps only service and cluster heartbeat polling enabled, sets both to 20 minutes, disables the persistent websocket, and turns off other periodic agent tasks: + +```yaml +apiVersion: deployments.plural.sh/v1alpha1 +kind: AgentConfiguration +metadata: + name: default +spec: + servicePollInterval: "20m" + clusterPingInterval: "20m" + managedNamespacePollInterval: "0s" + compatibilityUploadInterval: "20m" + stackPollInterval: "0s" + sentinelPollInterval: "0s" + pipelineGateInterval: "0s" + vulnerabilityReportUploadInterval: "0s" + disableWebsocket: true +``` + +Setting an interval to `"0s"` disables that task. This profile minimizes requests from each device, but it also disables Stack runs, Sentinel runs, pipeline gate evaluation, vulnerability report uploads, and managed namespace polling on those clusters. We also downtune other polls from their existing defaults, usually 2-3m to support higher scale, this can be toggled up and down based on total fleet, we've found there's usually little need to tune until you get around 1k clusters. + +If an edge cluster needs any of those features, enable its corresponding interval rather than copying this profile unchanged. See [AgentConfiguration](/plural-features/continuous-deployment/deployment-operator/agent-configuration) for the complete field reference and verification steps. + +## Enable durable agent caches + +Configure the deployment operator chart for the whole fleet through the `DeploymentSettings` resource on the management cluster: + +```yaml +apiVersion: deployments.plural.sh/v1alpha1 +kind: DeploymentSettings +metadata: + name: global + namespace: plrl-deploy-operator +spec: + agentHelmValues: + cache: + hostPath: + enabled: true +``` + +This mounts a node-local directory into the deployment operator and enables its durable cache. Cached manifests and agent state survive same-node pod restarts and upgrades, reducing cold-start downloads and recomputation on edge devices. + +{% callout severity="warning" %} +The cache uses node-local `hostPath` storage. It does not follow the pod to another node, so an agent scheduled elsewhere starts with an empty cache. Keep the agent replica count at `1` when `cache.hostPath.enabled` is enabled. +{% /callout %} + +`DeploymentSettings.spec.agentHelmValues` supplies defaults to agents managed by Plural. Existing agents receive the values during their next agent chart update. See [DeploymentSettings](/plural-features/continuous-deployment/management-controller/deployment-settings#agenthelmvalues) for more details. diff --git a/pages/plural-features/continuous-deployment/management-controller/deployment-settings.md b/pages/plural-features/continuous-deployment/management-controller/deployment-settings.md index 655a5469..7f7544d1 100644 --- a/pages/plural-features/continuous-deployment/management-controller/deployment-settings.md +++ b/pages/plural-features/continuous-deployment/management-controller/deployment-settings.md @@ -196,7 +196,7 @@ spec: key: openai ``` -For a complete AI configuration guide, see [Setup Plural AI](/plural-features/plural-ai/setup). For observability + AI together, see [Observability Configuration](/plural-features/observability). +For a complete AI configuration guide, see [Set Up and Configure Plural AI](/plural-features/plural-ai/multi-model-configuration). For observability + AI together, see [Observability Configuration](/plural-features/observability). ### `reconciliation` diff --git a/pages/plural-features/plural-ai/arch-diagram.md b/pages/plural-features/plural-ai/arch-diagram.md deleted file mode 100644 index 6861c2ea..00000000 --- a/pages/plural-features/plural-ai/arch-diagram.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Deep Infrastructure Research -description: Agentic Search of Your Infrastructure to Generate Arch Diagrams and More ---- - -The best way to understand complex software infrastructure is to find a way to diagram it out to get to a visual representation of the data at hand. Plural AI has all the tools to automate this process in many cases, even across cloud and kubernetes boundaries. In particular, Plural has a few key datasources that enable an agentic diagramming engine: - -1. A constantly refreshing semantic index of your infrastructure generated by our GitOps engine -2. The ability to reference source code and terraform state when necessary in an agentic process -3. The ability to live query Kubernetes or your cloud when necessary to fill in needed gaps - -{% callout severity="info" %} -We are also actively working on ebpf network inspection which will improve this source data even more -{% /callout %} - -That enables our AI to draft basic arch diagrams with a simple prompt. - -## Create a Research Session - -Diagram creation is simple and UI-based. Navigate to `AI -> Infra Research`. You'll have a prompt button to spawn a new research, and from there you'll see a few threads spawn in as the AI is working in the background. The process takes about 1-2 minutes, and is completely headless, so feel free to grab a coffee while its churning. Once done, you'll have a full result looking something like (using the prompt `Show me the architecture of the grafana deployment`): - -![](/assets/ai/research-diagram.png) - -![](/assets/ai/research-analysis.png) - -This will have: - -1. A complete architecture diagram of the infrastructure tied to your prompt -2. A text summary of the infrastructure and any other learnings found -3. A list of notes of what the AI still doesn't seem to understand from its investigation -4. A list of associated Plural Services and Stacks used as source data for the investigation - -The graph itself is created in [Mermaid](https://mermaid.js.org/) format, and can be quite complex. This can easily lead to hallucinations. To correct these you have two tools: - -1. AI fix - we provide a fix with ai button that will take any javascript errors from mermaid parsing and attempt to correct them. -2. Try it again - in other cases, it's oftentimes easier to just rerun the generation. You can use the `Try Again` button to do this. - -## Publish Your Research - -Once you feel like the diagram and research is suitable for broader acceptance, you can chose to publish it. From there, anyone can view your research results and we'll index it for use in other investigations in the future. diff --git a/pages/plural-features/plural-ai/architecture.md b/pages/plural-features/plural-ai/architecture.md deleted file mode 100644 index f894eda4..00000000 --- a/pages/plural-features/plural-ai/architecture.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Plural AI Architecture -description: How Plural AI works ---- - -## Overview - -At its core, Plural AI has three main components: - -* A causal graph of the high-level objects that define your infrastructure. An example is this Plural Service owns this Kubernetes Deployment, which owns a ReplicaSet which owns a set of Pods. -* A permission engine to ensure any set of objects within the graph are interactable by the given user of Plural's AI. This hardens the governance process around access to the completions for our AI. The presence of Plural's agent in your Kubernetes fleet also makes the ability to query end-clusters much more secure from a networking perspective. -* Our PR Automation framework - this allows us to hook into SCM providers and automate code fixes in a reviewable, safe way. - -In the parlance of the AI industry, you can think of it as a highly advanced RAG (retrieval augmented generation), with an agent-like behavior, since it's always on and triggered by any emergent issue in your infrastructure. - -## In Detail - -Here's a detailed walkthrough of how the AI engine works in the case of a Plural Service with a failing Kubernetes deployment. - -1. The engine is told the service is failing from our internal event bus -2. The failing components of that service are collected, with the failing deployment selected first -3. The metadata of the service are added to the prompt (what cluster its on, how its sourcing its configuration, etc) -4. The events, replica sets, spec of the k8s deployment are queried and added to a prompt -5. The failing pods for the deployment are selected from the replica sets, and a random subset are queried individually -6. Each failing pods events and spec are added to the growing prompt - -This will then craft an insight for the Deployment node, which can be combined with insights from any other components to collect to a service-level insight. - -If this investigation were done again, we'd be able to cache any non-stale insights and prevent rerunning the inference a second time where it would be unnecessary. diff --git a/pages/plural-features/plural-ai/cost.md b/pages/plural-features/plural-ai/cost.md deleted file mode 100644 index 14efaf78..00000000 --- a/pages/plural-features/plural-ai/cost.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Plural AI cost analysis -description: How much will Plural AI cost me? ---- - -Plural AI is built to be extremely cost efficient. We've found it will often heavily outcompete the spend you would use on advanced APM tools, and likely even DIY prometheus setups. That said, AI inference is not cheap in general, and we do a number of things to work around that: - -* Our causal knowledge graph heavily caches at each layer of the tree. This allows us to ensure repeated attempts to generate the same insight are deduplicated, reducing inference API calls dramatically -* You can split the model used by usecase. Insight generation can leverage cheap, fast models, whereas the tool calls that ultimately generate PRs use smarter, advanced models, but are executed less frequently so the cost isn't felt as hard. -* We use AI sparingly. Inference is only done when we know something is wrong. - -That said, what does that actually mean? - -## Basic Cost Analysis - -We at Plural dogfood our own AI functionality in our own infrastructure. This includes a sandbox test fleet of over 10 clusters, and a production fleet of around 5 clusters for both our main services and Plural Cloud. Plural's AI Engine runs on the management clusters for each of these domains since launch, and while we might do a decent-ish job of caretaking those environments, or current daily OpenAI bill is $~2.64 per day, or roughly $81 per month. - -This is staggeringly cost effective, when you consider a Datadog bill for our equivalent infrastructure is at minimum $10k, even a prometheus setup is well over 100/mo for the necessary compute including datastore, grafana, grafana's database, load balancers, and agents. Granted, some of these services will ultimately be necessary to have Plural AI reach its full potential, but we could see a world where: - -```sh -OpenTelemetry + Plural AI >> Datadog/New Relic -``` - -as a general debugging platform, while being a miniscule fraction of the current cost. \ No newline at end of file diff --git a/pages/plural-features/plural-ai/index.md b/pages/plural-features/plural-ai/index.md index 648d28fa..3235a784 100644 --- a/pages/plural-features/plural-ai/index.md +++ b/pages/plural-features/plural-ai/index.md @@ -2,23 +2,14 @@ title: Plural AI description: Plural's AI engine removes the gruntwork from infrastructure --- -{% callout severity="info" %} -If you just want to skip the text and see it in action, skip to the demo video below. -{% /callout %} -Managing infrastructure is full of mind-numbing tasks, from troubleshooting the same misconfiguration for the hundredth time, to whack-a-moling Datadog alerts, to playing internal IT support to application developers who cannot be bothered to learn the basics of foundational technology like Kubernetes. Plural AI allows you to outsource all those time-sucks to LLMs so you can focus on building value-added platforms for your enterprise. +Managing infrastructure is full of mind-numbing tasks, from troubleshooting the same misconfiguration for the hundredth time, to whack-a-moling Datadog alerts, to playing internal IT support to application developers who cannot be bothered to learn the basics of foundational technology like Kubernetes. Plural AI allows you to outsource all those time-sucks to LLMs so you can focus on building robust platforms for your enterprise. In particular, Plural AI has a few differentiators to its approach: -* A bring-your-own-LLM model - allows you to use the LLM already approved by your enterprise and not worry about us as a MITM -* An always-on troubleshooting engine - taking signals from failed kubernetes services, failed terraform runs, and other misfires in your infrastructure to run a consistent investigative process and summarize the results. Eliminate manual digging and just fix the issue instead. -* Automated Fixes - Take any insight from our troubleshooting engine and generate a fix PR automatically, generated from our ability to introspect the GitOps code defining that piece of infrastructure. -* AI Explanation - Complex or Domain-specific pages can be explained w/ one click with AI, eliminating internal support burdens for engineers. -* AI Chat - any workflow above can be further refined or expanded in a full ChatGPT-like experience. Paste additional context into chats automatically, or generate PRs once you and the AI has found the fix. +* A bring-your-own-LLM - allows you to use the LLM already approved by your enterprise and not worry about us as a MITM +* Self-Hostability - allows you to maintain full data sovereignty. We aren't an AI lab, and don't need to train on your data. +* An always-on troubleshooting engine - taking signals from failed kubernetes services, failed terraform runs, and other misfires in your infrastructure to run a consistent investigative process and summarize the results. Eliminate manual digging and just fix the issue instead. Think of this as a Cursor Tab for infra. +* Remote Coding Agents on K8s - allows you to run infinitely parallelizable coding agents via API on your existing k8s infrastructure, with us handling the scheduling and developer experience e2e. - -# Demo Video - -To see this all in action, feel free to browse our live demo video on Youtube of our GenAI integration: - -{% embed url="https://youtu.be/ef9AuG78W_A" aspectRatio="16 / 9" /%} +And finally, our main AI feature is [Workbenches](/plural-features/workbenches): fully hosted agents with built-in policy enforcement for automating end-to-end work as a platform engineer. Read the [Workbenches documentation](/plural-features/workbenches) to see what they can do. diff --git a/pages/plural-features/plural-ai/multi-model-configuration.md b/pages/plural-features/plural-ai/multi-model-configuration.md index 35ab7c35..2f010199 100644 --- a/pages/plural-features/plural-ai/multi-model-configuration.md +++ b/pages/plural-features/plural-ai/multi-model-configuration.md @@ -1,10 +1,61 @@ --- -title: Configure Against Multiple Providers -description: How to mix and match models to optimize cost and performance +title: Set Up and Configure Plural AI +description: Configure Plural AI and mix models to optimize cost and performance --- The current state of GenerativeAI is a sprawl of vendors offering products with different specialties and price points, and its common to have an optimal AI setup involve usage of models across multiple different vendors or multiple models within the same vendor. Plural provides a number of knobs that are designed to make that degree of customization seamless, and compatible w/in a GitOps workflow. +## Set Up Plural AI + +Plural AI can be configured through **Settings → AI settings** in the Plural Console or with the `DeploymentSettings` CRD. If you installed Plural with `plural up`, the resource is already defined at `bootstrap/settings.yaml`. + +For a basic OpenAI configuration, create a credential secret and reference it from `DeploymentSettings`: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: ai-config + namespace: plrl-deploy-operator +stringData: + openai: +--- +apiVersion: deployments.plural.sh/v1alpha1 +kind: DeploymentSettings +metadata: + name: global + namespace: plrl-deploy-operator +spec: + ai: + enabled: true + provider: OPENAI + openAI: + tokenSecretRef: + name: ai-config + key: openai +``` + +Provider credentials are always read from secrets in the `plrl-deploy-operator` namespace. Use additional keys in the same secret when configuring other providers: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: ai-config + namespace: plrl-deploy-operator +stringData: + openai: + anthropic: + azure: + vertex: +``` + +{% callout severity="warning" %} +Never commit provider credentials to Git in plain text. Encrypt the secret with your organization's preferred secret-management workflow before storing it in a GitOps repository. +{% /callout %} + +The full `DeploymentSettings` schema is available in the [Management API reference](/api-reference/kubernetes/management-api-reference#deploymentsettingsspec). + ## Provider Selection within Plural AI There are three main usecases where we can differentiate models: @@ -15,7 +66,32 @@ There are three main usecases where we can differentiate models: Often toggling these individual can give you the best cost/feature tradeoff for your usecase. -## Example Configuration +## Configure Models in the Console + +You can configure the same multi-provider setup from the Plural Console: + +1. Go to **Settings → AI settings**. +2. Open the **AI providers** tab. +3. Click **Connect provider**, select a provider, and enter its credentials and model configuration. +4. Repeat for each LLM or embedding provider you want Plural to use. Use the edit button beside an existing provider to change its configuration. + +![Configured AI providers in Plural Console](/assets/ai/ai-providers.png) + +After connecting your providers, open the **Model routing** tab. Select the provider Plural should use for each role: + +* **Chat model** for low-compute chat and completion use cases. +* **Embedding model** for indexing Kubernetes and IaC state for semantic search. +* **Tool model** for complex agentic inference and tool calling. + +![Model routing configuration in Plural Console](/assets/ai/model-routing.png) + +Models are configured on each provider in the **AI providers** tab. Model routing pins a provider to each role and displays the model that role will use. If a role-specific model is not configured, the router falls back to that provider's default model. + +{% callout severity="info" %} +Use the **Disable AI in Plural** toggle on the AI providers page to turn off AI features globally. For reproducible and auditable configuration, prefer the GitOps workflow below. +{% /callout %} + +## Configure Multiple Providers with DeploymentSettings To tune your AI configuration, the recommended approach is to do it within a GitOps workflow using our `DeploymentSettings` Kubernetes CRD. If you set up Plural with `plural up`, this will already be defined for you at `bootstrap/settings.yaml`. Here's a basically complete example of how to configure its AI model settings: @@ -64,23 +140,6 @@ spec: key: vertex ``` -{% callout severity="info" %} -All the secretRef's below reference a kubernetes secret defined like: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - namespace: plrl-deploy-operator - name: ai-config -stringData: - openai: ... - anthropic: ... - azure: ... - vertex: ... -``` -{% /callout %} - ## Model Selection Logic The model selected is generally a waterfall like so. @@ -134,4 +193,4 @@ Configuring a default model is usually optional, we chose sane defaults for all ## Learn More -You can see the full docs for this resource at our [Agent API docs](https://docs.plural.sh/overview/management-api-reference#deploymentsettingsspec) +See the complete [`DeploymentSettings` schema](/api-reference/kubernetes/management-api-reference#deploymentsettingsspec) in the Management API reference. diff --git a/pages/plural-features/plural-ai/setup.md b/pages/plural-features/plural-ai/setup.md deleted file mode 100644 index 6ded14a5..00000000 --- a/pages/plural-features/plural-ai/setup.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: Setup Plural AI -description: How to configure Plural AI ---- - -Plural AI can easily be configured via the `DeploymentSettings` CRD or at `/settings/global/ai-provider` in your Plural Console instance. An example `DeploymentSettings` config is below: - -```yaml -apiVersion: deployments.plural.sh/v1alpha1 -kind: DeploymentSettings -metadata: - name: global - namespace: plrl-deploy-operator -spec: - managementRepo: pluralsh/plrl-boot-aws - - ai: - enabled: true - provider: OPENAI - anthropic: # example anthropic config - model: claude-3-5-sonnet-latest - tokenSecretRef: - name: ai-config - key: anthropic - - openAI: # example openai config - tokenSecretRef: - name: ai-config - key: openai - - vertex: # example VertexAI config - project: pluralsh-test-384515 - location: us-east1 - model: gemini-1.5-pro-002 - serviceAccountJsonSecretRef: - name: ai-config - key: vertex -``` - -You can see the full schema at our {% doclink to="overview_api_reference" %}API Reference{% /doclink %}. - -In all these cases, you need to create an additional secret in the `plrl-deploy-operator` namespace to reference api keys and auth secrets. It would look something like this: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: ai-config - namespace: plrl-deploy-operator -stringData: - vertex: - openai: - anthropic: -``` - -{% callout severity="warn" %} -Be sure not to commit this secret resource into your Git repository in plain-text, as that will result in a git secret exposure. - -Plural provides a number of mechanisms to manage secrets, or you can use the established patterns within your engineering organization. -{% /callout %} \ No newline at end of file diff --git a/pages/plural-features/workbenches/automation.md b/pages/plural-features/workbenches/automation.md index c0cf3e4b..eb05f24a 100644 --- a/pages/plural-features/workbenches/automation.md +++ b/pages/plural-features/workbenches/automation.md @@ -13,7 +13,6 @@ Workbenches can run jobs automatically through several mechanisms: Cron schedules and webhook triggers are managed from the overflow menu (**•••**) on a workbench. Follow-up prompts are configured in your source control or CI automation. ---- ## Cron schedules @@ -43,7 +42,6 @@ Cron expressions use UTC. The UI shows a preview of upcoming fire times in your The **Cron schedules** page lists all schedules for the workbench. Click the pencil icon to edit a schedule or the trash icon to delete it. ---- ## Webhook triggers @@ -104,7 +102,6 @@ Each webhook source has its own setup guide available during trigger creation. C 3. Configure the URL and secret in your alerting tool or issue tracker 4. Send a test payload to verify connectivity ---- ## Post-merge follow-up jobs @@ -112,7 +109,6 @@ When a workbench opens a pull request, a GitHub Actions workflow can send a foll See [Automating workbench follow-up](/plural-features/workbenches/follow-up-automation) for provider-specific setup. The current guide includes authentication, inputs, and a complete GitHub Actions workflow. ---- ## Flow-triggered jobs diff --git a/pages/plural-features/workbenches/coding-agent.md b/pages/plural-features/workbenches/coding-agent.md index 818f2d77..f4730c6c 100644 --- a/pages/plural-features/workbenches/coding-agent.md +++ b/pages/plural-features/workbenches/coding-agent.md @@ -9,7 +9,6 @@ The coding agent extends a workbench with the ability to read source code, propo Coding capabilities are optional. Workbenches that are purely operational (querying metrics, triaging alerts, summarizing Kubernetes state) do not need a coding agent configured. ---- ## Prerequisites @@ -23,7 +22,6 @@ See **[Configure an AgentRuntime](/plural-features/plural-ai/ai-agent)** for ful Once an `AgentRuntime` is deployed and set as `default: true` (or you have at least one runtime available), it will appear in the workbench coding agent step. ---- ## Enabling the coding agent @@ -62,7 +60,6 @@ This is useful for: With babysitting off, the agent opens a pull request and exits, leaving your normal review process to handle the rest. ---- ## How coding shows up in job results @@ -73,7 +70,6 @@ When a job completes with Write mode and the agent has opened pull requests, the ![](/assets/workbenches/workbench-conclusion-dashboard-prs.png) ---- ## Combining coding with operational capabilities diff --git a/pages/plural-features/workbenches/configuration.md b/pages/plural-features/workbenches/configuration.md index 88934f0a..7e3870ba 100644 --- a/pages/plural-features/workbenches/configuration.md +++ b/pages/plural-features/workbenches/configuration.md @@ -10,7 +10,6 @@ Before creating a workbench you need: * Any external tools (Datadog, Prometheus, GitHub, Slack, etc.) configured in **Workbenches → Integrations**. Tools can be added later, but it is easiest to have them ready before creating the workbench. See [Workbench tools](/plural-features/workbenches/tools). * If you plan to enable the coding agent, an `AgentRuntime` resource deployed to your management cluster. See [Configure an AgentRuntime](/plural-features/plural-ai/ai-agent/configure-agent). ---- ## Creating a workbench @@ -18,7 +17,6 @@ Navigate to **Workbenches** in the Plural Console sidebar and click **Create wor ![](/assets/workbenches/workbench-create-wizard.png) ---- ## Step 1: Workbench setup @@ -51,7 +49,6 @@ These capabilities give the agent access to Plural's own internal tooling — th The **Observability** capabilities use the backends you set up under [Observability Integration](/plural-features/observability). **Pod logs** is a separate, direct Kubernetes log stream — it works without any observability backend. {% /callout %} ---- ## Step 2: Skills configuration @@ -74,7 +71,6 @@ Skill files are fetched from Git at job start, so they stay current as your runb ![](/assets/workbenches/workbench-skills-step.png) ---- ## Step 3: Coding agent @@ -82,7 +78,6 @@ This step configures optional code-reading and code-writing capabilities. Skip i For detailed guidance on setting up and using the coding agent, see [Coding agent](/plural-features/workbenches/webhooks/coding-agent). ---- ## Step 4: Access policy @@ -93,7 +88,6 @@ Control who can view and trigger jobs. Bindings use the same user and group model as the rest of Plural. If you leave both lists empty, access falls through to the parent project's policy. ---- ## Step 5: Attach tools @@ -103,7 +97,6 @@ Attach only the tools this specific workbench needs. A tightly-scoped tool list ![](/assets/workbenches/workbench-attach-tools-step.png) ---- ## Running your first job @@ -121,7 +114,6 @@ The agent will stream activities as it works and produce a structured conclusion * [Set up a cron schedule](/plural-features/workbenches/automation#cron-schedules) to run it automatically * [Add a webhook trigger](/plural-features/workbenches/automation#webhook-triggers) to fire it on alerts ---- ## Editing a workbench diff --git a/pages/plural-features/workbenches/index.md b/pages/plural-features/workbenches/index.md index f89a8fff..0a3dd2a4 100644 --- a/pages/plural-features/workbenches/index.md +++ b/pages/plural-features/workbenches/index.md @@ -5,15 +5,11 @@ description: Configurable AI agent environments for automated infrastructure ope ## Overview -Workbenches are named, project-scoped environments for running AI-driven operations against your infrastructure. Each workbench bundles a system prompt, a set of capabilities, connected tools, and automation triggers into a reusable workspace that your team can run on-demand, on a schedule, or in response to incidents. +Workbenches are named, project-scoped environments for running AI-driven operations against your infrastructure. Each workbench bundles a system prompt, a set of capabilities, connected tools, and automation triggers into a reusable workspace. -At runtime, a **workbench job** is created — the agent executes using the configured capabilities and tools, emitting a live stream of activities as it works. When finished it produces a structured conclusion that can include summaries, dashboards, follow-up todos, topology pointers, and opened pull requests. +At runtime, a **job** is created — the agent executes using the configured capabilities and tools, emitting a live stream of activities as it works. When finished it produces a structured conclusion that can include summaries, dashboards, follow-up todos, topology pointers, and opened pull requests. -Key things you can do with a workbench: - -* Run an AI agent against your Plural-managed services, stacks, and Kubernetes clusters — respecting your existing RBAC -* Connect external tools like Datadog, Prometheus, Elasticsearch, Slack, GitHub, and custom HTTP APIs so the agent has full operational context -* Trigger jobs automatically from observability alerts, issue trackers, or cron schedules +![](/assets/workbenches/workbenches-overview.png) ## Core concepts @@ -21,35 +17,30 @@ Key things you can do with a workbench: The parent configuration object. It defines the agent's identity (name, system prompt), the project it belongs to, the agent runtime to use, which capabilities are enabled, which tools are attached, and who has access. -### Workbench job - -A single run of the agent against a prompt. Jobs are created manually in the UI, by a cron schedule, by a webhook trigger, or from a [Plural Flow](/plural-features/flows). Each job has a status (`pending`, `running`, `complete`, `failed`) and a streaming activity log you can follow in real time. +### Job -### Activities - -Step-by-step records produced while a job runs — tool calls, subagent results, internal thoughts, and intermediate conclusions. Activities are surfaced in the job detail panel and also feed the workbench's AI memory so future runs can learn from past work. +A single run of the agent against a prompt. Each job has a status (`pending`, `running`, `complete`, `failed`) and a streaming activity log you can follow in real time. See [Running workbench jobs](/plural-features/workbenches/running-jobs). ### Tools -External integrations the agent can call during a job. Tools are managed globally under the **Tools** section and then attached to individual workbenches. See [Tools](/plural-features/workbenches/tools) for the full list of supported integrations. +External integrations the agent can call during a job. Tools are managed globally under **Tools** and then attached to individual workbenches. See [Tools](/plural-features/workbenches/tools). ### Skills Instruction files that extend what the agent knows how to do. Skills can be loaded from a Git repository or defined inline in the workbench. They are included in the agent's context alongside the system prompt. -## How workbenches fit into Plural +## How jobs can be run -Workbenches live under a **project**, inheriting and extending that project's RBAC. Within a project they complement the rest of the Plural surface: +Jobs can be started on demand or automatically: -| Integration | How it connects | -|---|---| -| [Flows](/plural-features/flows) | A flow can launch a workbench job directly from its UI or via `FlowWorkbenchJobLauncher`, scoping the job to that flow's services and pipelines | -| Alerts | Observability alerts can automatically trigger workbench jobs via [webhook triggers](/plural-features/workbenches/automation#webhook-triggers) | -| Issues | Issue tracker events can trigger workbench jobs the same way, and the job has access to the originating issue | -| Pull requests | Jobs that open PRs record them on the job | -| Agent runtime | The AI model and sandbox environment that executes each job; configured at the workbench level | +* **UI** — Open a workbench, go to the **Launch** tab, and submit a prompt. See [Running workbench jobs](/plural-features/workbenches/running-jobs). +* **API** — Create a job with the Console REST API or GraphQL (`createWorkbenchJob`). See [CreateWorkbenchJob](/api-reference/rest/CreateWorkbenchJob) and the [GraphQL API](/api-reference/graphql). +* **Automatically** — Jobs can also fire without a manual prompt: + * [Webhook triggers](/plural-features/workbenches/automation#webhook-triggers) — observability alerts and issue tracker events + * [Cron schedules](/plural-features/workbenches/automation#cron-schedules) — recurring prompts on a crontab + * Slack chatbot — @mention the workbench bot in a Slack channel to start a job -![](/assets/workbenches/workbenches-overview.png) +Webhook, cron, and chatbot bindings are configured on the workbench. See [Automating workbench jobs](/plural-features/workbenches/automation) for webhook and cron setup. ## Getting started @@ -57,5 +48,3 @@ Workbenches live under a **project**, inheriting and extending that project's RB 2. Click **Create workbench** and step through the [creation wizard](/plural-features/workbenches/configuration). 3. (Optional) Set up shared [tools](/plural-features/workbenches/tools) your workbench can call. 4. Run your first job from the workbench's **Launch** tab. - -Once you have a job running, you can layer in [automation](/plural-features/workbenches/automation) to trigger jobs on a schedule or from incidents. diff --git a/pages/plural-features/workbenches/running-jobs.md b/pages/plural-features/workbenches/running-jobs.md index 8b34124e..3c3313c2 100644 --- a/pages/plural-features/workbenches/running-jobs.md +++ b/pages/plural-features/workbenches/running-jobs.md @@ -12,7 +12,6 @@ A workbench job is a single execution of the workbench agent against a prompt. I Jobs can be started manually from the UI, by a [cron schedule](/plural-features/workbenches/automation#cron-schedules), by a [webhook trigger](/plural-features/workbenches/automation#webhook-triggers), or from a [Plural Flow](/plural-features/flows). You can also trigger a job by writing `Plural fix this` or `Plural deploy this` (or any instruction prefixed with "Plural") in a Jira ticket, GitHub PR comment, or other connected issue source — see [Triggering jobs with "Plural" mentions](/plural-features/workbenches/automation#triggering-jobs-with-plural-mentions). ---- ## Starting a job manually @@ -24,7 +23,6 @@ Open a workbench, select the **Launch** tab, and type your prompt into the new-j Frequently-used prompts can be saved under **••• → Saved prompts** so your team can launch common investigations without retyping. When starting a job, select a saved prompt from the dropdown to pre-fill the prompt field. ---- ## The Jobs tab @@ -32,7 +30,6 @@ The **Jobs** tab on each workbench shows all runs in reverse-chronological order You can filter the list to show only jobs triggered by an **alert** or **issue** using the filter controls at the top of the table. ---- ## Job detail: activities @@ -49,7 +46,6 @@ While a job is running, activities stream in real time. You do not need to refre ![](/assets/workbenches/workbench-job-activities.png) ---- ## Job detail: result @@ -63,7 +59,6 @@ Once a job completes, the **Result** panel appears on the right side of the job ![](/assets/workbenches/workbench-job-result.png) ---- ## Canvas view @@ -77,7 +72,6 @@ And here is one for an alert analysis: ![](/assets/workbenches/metrics-canvas.png) ---- ## Alerts and issues tabs @@ -85,7 +79,6 @@ If your workbench has [webhook triggers](/plural-features/workbenches/automation This gives you an at-a-glance view of how automated incident response is performing without having to dig through the full job list. ---- ## Re-running a job diff --git a/pages/plural-features/workbenches/tools.md b/pages/plural-features/workbenches/tools.md index 08ce859f..10094be6 100644 --- a/pages/plural-features/workbenches/tools.md +++ b/pages/plural-features/workbenches/tools.md @@ -11,7 +11,6 @@ Navigate to **Workbenches → Integrations** to browse the available tool types, ![](/assets/workbenches/workbench-tools-list.png) ---- ## Tool types @@ -92,7 +91,6 @@ The agent is also always equipped with a **calculator tool** that evaluates arit | **HTTP** | A custom REST endpoint. You define the request shape (URL, method, headers, body, JSON schema) and the agent can call it as a named tool | | **MCP** | Any [Model Context Protocol](https://modelcontextprotocol.io) server. Plural handles authentication and audit-logs every call | ---- ## Creating a tool @@ -106,16 +104,34 @@ Each tool type has a setup form for its required credentials (API keys, endpoint Once saved, the tool appears in **Workbenches → Configured tools** and can be attached to any workbench. ---- ## Attaching tools to a workbench Tools are attached to workbenches during creation (Step 5) or via **Edit** on an existing workbench. A workbench can only call the tools explicitly attached to it — this gives you fine-grained control over what each agent can reach. ---- -## Tool RBAC +## Tool policies + +Tools are governed in two layers: who can attach and edit the tool, and what the agent is allowed to do when it calls the tool during a job. + +### Access policy + +Each tool has its own **read** and **write bindings**: + +* **Read permissions** control who can see the tool and attach it to a workbench +* **Write permissions** control who can modify the tool configuration and access policy + +Users or groups without at least read access cannot attach the tool to their workbenches. This is particularly useful for restricting production cloud connections or sensitive API credentials. + +Configure bindings by opening a tool in **Workbenches → Configured tools** and clicking **Edit**. If both lists are empty, access falls through to the parent project's policy. + +Built-in tools also enforce authorization against the resource they access at execution time. For example, Kubernetes tools federate the user running the job to the target cluster using their Console email and groups. The Kubernetes API server then applies that identity's native RBAC rules to each request. Attaching or enabling a built-in tool therefore does not give the agent broader access than the user already has. + +### Workbench policies + +[Workbench policies](/plural-features/policy-management/workbench-policies) evaluate each matching tool call the agent makes. They extend tool access bindings with Rego rules that can: -Each tool has its own **read** and **write bindings**. Users or groups without at least read access to a tool cannot attach it to their workbenches. This is particularly useful for restricting access to production cloud connections or sensitive API credentials. +* **Deny** a call based on the actor, tool name, and arguments — for example, blocking deletes in `kube-system` +* **Automatically approve** a call that would otherwise wait for human approval -Tool permissions are configured by navigating to a tool in **Workbenches → Configured tools** and clicking **Edit**. +A policy cannot make an unavailable tool accessible or grant permissions the actor does not already have. Attach a policy to a workbench (optionally scoped to selected tool names) from **Security → Policies**, or use a binding policy to attach it automatically. See [Workbench policies](/plural-features/policy-management/workbench-policies) for the input schema, decision model, and examples, and [Simulating and testing policies](/plural-features/policy-management/simulating-policies) to inspect real tool-call inputs before writing rules. diff --git a/pages/plural-features/workbenches/use-cases.md b/pages/plural-features/workbenches/use-cases.md index 810c1607..359e43a0 100644 --- a/pages/plural-features/workbenches/use-cases.md +++ b/pages/plural-features/workbenches/use-cases.md @@ -5,7 +5,6 @@ description: Worked examples for alert RCA, Slack incident response, cost analys The patterns below each represent a complete workbench setup for a common operational need. For each one, the agent's behavior is shaped by [skills](/plural-features/workbenches/configuration#step-2-skills-configuration) — pre-built instruction documents from Plural's skills library, or custom runbooks from your own Git repository. You do not need to write a system prompt from scratch; attach the relevant skills for the use case and add a brief system prompt to orient the agent to your platform if needed. ---- ## Alert root cause analysis @@ -32,7 +31,6 @@ Navigate to **••• → Webhook trigger** and create a trigger on your Datad **Cron schedule (optional):** Add a `@daily` cron with a prompt asking for a summary of all alerts that fired in the last 24 hours and their current status, to get a morning digest. ---- ## Slack incident channel creation @@ -58,7 +56,6 @@ Create a trigger on your observability webhook targeting high-severity or produc The Slack bot token must have permission to create public channels and invite members. If your workspace requires admin approval for channel creation, coordinate with your Slack admin to pre-approve the bot. {% /callout %} ---- ## Cost information and reporting @@ -102,7 +99,6 @@ Because the workbench is also available for manual jobs, engineers can open it a * `Which EKS nodes are driving the most compute cost this week?` * `Is our staging environment spend unusually high right now?` ---- ## Ticket-driven infrastructure self-service diff --git a/public/assets/ai/ai-providers.png b/public/assets/ai/ai-providers.png new file mode 100644 index 00000000..7e501261 Binary files /dev/null and b/public/assets/ai/ai-providers.png differ diff --git a/public/assets/ai/model-routing.png b/public/assets/ai/model-routing.png new file mode 100644 index 00000000..920e4a60 Binary files /dev/null and b/public/assets/ai/model-routing.png differ diff --git a/src/markdoc/tags/doclink.tsx b/src/markdoc/tags/doclink.tsx index efa62747..76506f6c 100644 --- a/src/markdoc/tags/doclink.tsx +++ b/src/markdoc/tags/doclink.tsx @@ -113,10 +113,10 @@ const oldDocIDtoRouteMap: Record = { '/plural-features/service-catalog/contribution-program', plural_features_kubernetes_dashboard: '/plural-features/kubernetes-dashboard', plural_features_plural_ai: '/plural-features/plural-ai', - plural_features_plural_ai_setup: '/plural-features/plural-ai/setup', - plural_features_plural_ai_architecture: - '/plural-features/plural-ai/architecture', - plural_features_plural_ai_cost: '/plural-features/plural-ai/cost', + plural_features_plural_ai_setup: + '/plural-features/plural-ai/multi-model-configuration', + plural_features_plural_ai_architecture: '/plural-features/plural-ai', + plural_features_plural_ai_cost: '/plural-features/plural-ai', plural_features_pr_automation: '/plural-features/pr-automation', plural_features_pr_automation_crds: '/plural-features/pr-automation/crds', plural_features_pr_automation_testing: diff --git a/src/routing/docs-structure.ts b/src/routing/docs-structure.ts index f7708e28..1a2317e8 100644 --- a/src/routing/docs-structure.ts +++ b/src/routing/docs-structure.ts @@ -67,6 +67,7 @@ export const docsStructure: DocSection[] = [ title: 'Advanced configuration', sections: [ { path: 'sandboxing', title: 'Sandboxing your cluster' }, + { path: 'edge-configuration', title: 'Edge configuration' }, { path: 'network-configuration', title: 'Network configuration' }, { path: 'private-ca', title: 'Handling private CAs' }, ], @@ -211,13 +212,44 @@ export const docsStructure: DocSection[] = [ { path: 'contribution-program', title: 'Contribution program' }, ], }, + { + path: 'workbenches', + title: 'Workbenches', + sections: [ + { path: 'configuration', title: 'Setting up a workbench' }, + { path: 'coding-agent', title: 'Coding agent' }, + { + path: 'tools', + title: 'Workbench tools', + sections: [{ path: 'datadog', title: 'Datadog integration' }], + }, + { path: 'running-jobs', title: 'Running workbench jobs' }, + { path: 'automation', title: 'Automating workbench jobs' }, + { + path: 'follow-up-automation', + title: 'Automating workbench follow-up', + }, + { path: 'use-cases', title: 'Common use cases' }, + ], + }, + { + path: 'policy-management', + title: 'Policy management', + sections: [ + { path: 'stack-policies', title: 'Stack policies' }, + { path: 'workbench-policies', title: 'Workbench policies' }, + { + path: 'simulating-policies', + title: 'Simulating and testing policies', + }, + { path: 'common-use-cases', title: 'Common use cases' }, + ], + }, { path: 'kubernetes-dashboard', title: 'Kubernetes dashboard' }, { path: 'plural-ai', title: 'Plural AI', sections: [ - { path: 'setup', title: 'Setup Plural AI' }, - { path: 'architecture', title: 'Plural AI Architecture' }, { path: 'ai-agent', title: 'AI Background Agent', @@ -236,11 +268,9 @@ export const docsStructure: DocSection[] = [ path: 'sentinels', title: 'At-Scale Infrastructure Testing with Sentinels', }, - { path: 'arch-diagram', title: 'Infrastructure Deep Research' }, - { path: 'cost', title: 'Plural AI cost analysis' }, { path: 'multi-model-configuration', - title: 'Configure Against Multiple Providers', + title: 'Set Up and Configure Plural AI', }, ], }, @@ -259,39 +289,6 @@ export const docsStructure: DocSection[] = [ }, ], }, - { - path: 'workbenches', - title: 'Workbenches', - sections: [ - { path: 'configuration', title: 'Setting up a workbench' }, - { path: 'coding-agent', title: 'Coding agent' }, - { - path: 'tools', - title: 'Workbench tools', - sections: [{ path: 'datadog', title: 'Datadog integration' }], - }, - { path: 'running-jobs', title: 'Running workbench jobs' }, - { path: 'automation', title: 'Automating workbench jobs' }, - { - path: 'follow-up-automation', - title: 'Automating workbench follow-up', - }, - { path: 'use-cases', title: 'Common use cases' }, - ], - }, - { - path: 'policy-management', - title: 'Policy management', - sections: [ - { path: 'stack-policies', title: 'Stack policies' }, - { path: 'workbench-policies', title: 'Workbench policies' }, - { - path: 'simulating-policies', - title: 'Simulating and testing policies', - }, - { path: 'common-use-cases', title: 'Common use cases' }, - ], - }, { path: 'observability', title: 'Observability Integration', @@ -568,17 +565,37 @@ export const redirects = [ }, { source: '/ai/setup', - destination: '/plural-features/plural-ai/setup', + destination: '/plural-features/plural-ai/multi-model-configuration', + permanent: true, + }, + { + source: '/plural-features/plural-ai/setup', + destination: '/plural-features/plural-ai/multi-model-configuration', permanent: true, }, { source: '/ai/architecture', - destination: '/plural-features/plural-ai/architecture', + destination: '/plural-features/plural-ai', permanent: true, }, { source: '/ai/cost', - destination: '/plural-features/plural-ai/cost', + destination: '/plural-features/plural-ai', + permanent: true, + }, + { + source: '/plural-features/plural-ai/architecture', + destination: '/plural-features/plural-ai', + permanent: true, + }, + { + source: '/plural-features/plural-ai/arch-diagram', + destination: '/plural-features/plural-ai', + permanent: true, + }, + { + source: '/plural-features/plural-ai/cost', + destination: '/plural-features/plural-ai', permanent: true, }, {