@mastra/mcp-docs-server 1.2.19-alpha.3 → 1.2.19

package/.docs/integrations/deploy/kubernetes-helm.md

@@ -0,0 +1,332 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Kubernetes (Helm)
+
+> **Enterprise only:** The Helm chart is available exclusively to Mastra Enterprise customers. It is distributed from a private registry: your Enterprise license is exchanged for short-lived pull credentials. [Contact us](https://mastra.ai/contact) to get an Enterprise license.
+
+Deploy the Mastra platform — Mastra Server (your agent runtime) and Mastra Studio (the management UI) — on any Kubernetes cluster using the official `mastra-projects` Helm chart. The chart works on GKE, EKS, AKS, and generic or local clusters, and handles service exposure, TLS, and secret wiring for you.
+
+The chart follows two design principles:
+
+- **Bring your own images.** You build your Mastra project image with `mastra build` and push it to a registry. The chart never builds images.
+- **Bring your own data stores.** You point the chart at your PostgreSQL database and, optionally, an S3-compatible object store. Nothing stateful is bundled.
+
+This guide covers the Helm chart, which manages Deployments, Services, Ingress or Gateway resources, and secrets for you. To write the Kubernetes manifests yourself, or to run multiple server pods with shared pub/sub, see [Kubernetes](https://mastra.ai/integrations/deploy/kubernetes).
+
+## Before you begin
+
+You'll need:
+
+- A Kubernetes 1.27+ cluster and [`kubectl`](https://kubernetes.io/docs/tasks/tools/)
+- [Helm](https://helm.sh/docs/intro/install/) 3.8+ (OCI registry support)
+- A container registry your cluster can pull from
+- A PostgreSQL database reachable from the cluster
+- A Mastra Enterprise license key — required both to pull the chart and at runtime in production
+- For `ingress` mode: an ingress controller, or let the chart install one
+- For `gateway` mode: Gateway API CRDs and a Gateway controller (for example GKE's managed Gateway)
+
+## Deploy
+
+> **Warning:** Configure [authentication](https://mastra.ai/docs/auth/overview) in your Mastra application before building and installing the image. The default `loadBalancer` mode creates externally reachable Services that may expose Server and Studio to the internet, depending on your cluster and cloud provider.
+
+1. Build your Mastra project and containerize the output. Pass `--studio` so the same image can serve both Server and Studio:
+
+   ```bash
+   mastra build --studio
+   ```
+
+   ```dockerfile
+   FROM node:22-slim
+   WORKDIR /app
+   # Install dependencies inside the image: native modules (for example libsql)
+   # are platform-specific, so node_modules built on your machine must not be
+   # copied into the image (see .dockerignore below).
+   COPY .mastra/output/package.json .mastra/output/package-lock.json* ./
+   RUN npm install --force --prefer-offline --no-audit --no-fund
+   COPY .mastra/output ./
+   EXPOSE 4111
+   CMD ["node", "index.mjs"]
+   ```
+
+   ```text
+   .mastra/output/node_modules
+   ```
+
+   > **Warning:** Don't `COPY` the host-built `node_modules` into the image. `mastra build` installs native modules for your local platform — an image built on an Apple Silicon Mac for an amd64 cluster will crash at startup with errors like `Cannot find module '@libsql/linux-x64-gnu'`. Installing dependencies in-image (as above) always matches the target platform.
+
+   Push the image to your registry. If your machine's architecture differs from your cluster nodes (for example an arm64 Mac deploying to amd64 nodes), build with `--platform`:
+
+   ```bash
+   docker buildx build --platform linux/amd64 \
+     -t your-registry/my-mastra-app:1.0.0 --push .
+   ```
+
+   See [Mastra server](https://mastra.ai/docs/deployment/mastra-server) for build details.
+
+2. Store your application secrets in the release namespace. The chart reads database, license, and model-provider credentials from a Secret you own:
+
+   ```bash
+   kubectl create namespace mastra
+   kubectl create secret generic mastra-app-env -n mastra \
+     --from-literal=DATABASE_URL='postgresql://user:pass@host:5432/mastra' \
+     --from-literal=MASTRA_EE_LICENSE='<your-license-key>' \
+     --from-literal=OPENAI_API_KEY='<provider-key>'
+   ```
+
+   Include any other environment variables your agents need, such as model provider API keys.
+
+3. Create a values file pointing the chart at your image and secret:
+
+   ```yaml
+   global:
+     cloud: generic # gke | eks | aks | generic | local
+
+   mastra-server:
+     image:
+       repository: your-registry/my-mastra-app
+       tag: '1.0.0'
+     existingSecret: mastra-app-env
+
+   mastra-studio:
+     image:
+       repository: your-registry/my-mastra-app
+       tag: '1.0.0'
+     existingSecret: mastra-app-env
+   ```
+
+   Both components reference the same Secret because this guide runs the same application image for Server and Studio. Only use separate Secrets when the Studio deployment doesn't execute routes that need your application's provider credentials.
+
+   Set `global.cloud` to your platform so the chart emits the correct LoadBalancer and Ingress annotations for that cloud.
+
+   If your cluster doesn't already have access to the application image registry, create an image pull Secret:
+
+   ```bash
+   kubectl create secret docker-registry mastra-registry -n mastra \
+     --docker-server=your-registry \
+     --docker-username='<username>' \
+     --docker-password='<access-token>'
+   ```
+
+   Reference it from both components:
+
+   ```yaml
+   mastra-server:
+     imagePullSecrets:
+       - name: mastra-registry
+
+   mastra-studio:
+     imagePullSecrets:
+       - name: mastra-registry
+   ```
+
+   Public images and registries integrated with your cluster don't need an image pull Secret.
+
+   This is only the minimal configuration. After `helm registry login`, inspect the selected chart version's annotated defaults and README for every available value:
+
+   ```bash
+   CHART_VERSION=0.2.0
+   CHART=oci://us-central1-docker.pkg.dev/mastra-cloud/mastra-helm-ee/mastra-projects
+
+   helm show values "$CHART" --version "$CHART_VERSION"
+   helm show readme "$CHART" --version "$CHART_VERSION"
+   ```
+
+4. Exchange your Enterprise license key for a short-lived registry access token, log in to the private chart registry, then install the chart:
+
+   ```bash
+   CHART_VERSION=0.2.0
+   CHART=oci://us-central1-docker.pkg.dev/mastra-cloud/mastra-helm-ee/mastra-projects
+
+   TOKEN=$(curl -s https://license.mastra.ai/v1/registry-token \
+     -H "Authorization: Bearer $MASTRA_EE_LICENSE" | jq -r .token)
+
+   printf '%s' "$TOKEN" | helm registry login us-central1-docker.pkg.dev \
+     --username oauth2accesstoken \
+     --password-stdin
+
+   helm install mastra "$CHART" \
+     --version "$CHART_VERSION" \
+     -n mastra -f mastra-values.yaml
+   ```
+
+   Tokens expire after a short period; if an upgrade later fails with an authorization error, request a fresh token and log in again.
+
+   By default each component is exposed through a Service of type `LoadBalancer`.
+
+5. Verify the release. Wait for the pods, then check the server's health endpoint:
+
+   ```bash
+   kubectl -n mastra rollout status deployment -l app.kubernetes.io/instance=mastra
+   kubectl -n mastra get svc
+   ```
+
+   ```bash
+   curl http://<server-external-ip>:4111/health
+   ```
+
+   A `{"success":true}` response means the server is up. Open the Studio service address in a browser to reach the Mastra Studio UI.
+
+## Exposure modes
+
+The chart supports three ways to expose Server and Studio, selected once via `global.exposure.mode`:
+
+| Mode                     | What you get                                                          | Required values                                                |
+| ------------------------ | --------------------------------------------------------------------- | -------------------------------------------------------------- |
+| `loadBalancer` (default) | One `LoadBalancer` Service per component with per-cloud annotations   | —                                                              |
+| `ingress`                | ClusterIP Services plus one Ingress per component                     | `mastra-server.ingress.host`, `mastra-studio.ingress.host`     |
+| `gateway`                | ClusterIP Services, a shared Gateway, and one HTTPRoute per component | `mastra-server.httpRoute.host`, `mastra-studio.httpRoute.host` |
+
+### Ingress with Let's Encrypt TLS
+
+Use `ingress` mode with cert-manager to serve both components over HTTPS. The chart can install ingress-nginx and cert-manager for you, or use controllers you already run:
+
+```yaml
+global:
+  exposure:
+    mode: ingress
+  tls:
+    clusterIssuer: letsencrypt
+
+ingressController:
+  install: true # omit if you already run an ingress controller
+
+tls:
+  certManager:
+    install: true # omit if cert-manager is already installed
+  letsEncrypt:
+    email: ops@example.com
+
+mastra-server:
+  ingress:
+    host: api.example.com
+
+mastra-studio:
+  ingress:
+    host: studio.example.com
+```
+
+When `tls.letsEncrypt.email` is set, the chart renders a `ClusterIssuer` and annotates each Ingress so certificates are issued automatically. HTTP requests redirect to HTTPS.
+
+On `generic` clusters the chart doesn't set an `ingressClassName` unless you configure one, so your cluster's default ingress class applies.
+
+### Gateway API
+
+Use `gateway` mode on clusters with Gateway API support. On GKE the chart selects the managed `gke-l7-global-external-managed` class automatically; on other clouds set `global.gateway.className` explicitly:
+
+```yaml
+global:
+  exposure:
+    mode: gateway
+  tls:
+    clusterIssuer: letsencrypt
+
+mastra-server:
+  httpRoute:
+    host: api.example.com
+
+mastra-studio:
+  httpRoute:
+    host: studio.example.com
+```
+
+The chart creates a shared Gateway with HTTP and per-component HTTPS listeners. To attach to a Gateway you already run, set `global.gateway.name` instead.
+
+## Cloud presets
+
+The chart ships a values preset per platform that sets `global.cloud` and platform-appropriate defaults:
+
+| Platform              | Preset              | Notes                                                                                 |
+| --------------------- | ------------------- | ------------------------------------------------------------------------------------- |
+| GKE                   | `values-gke.yaml`   | Gateway API recommended; Workload Identity supported via `serviceAccount.annotations` |
+| EKS                   | `values-eks.yaml`   | NLB by default; ALB via ingress annotations; IRSA supported                           |
+| AKS                   | `values-aks.yaml`   | Azure LoadBalancer annotations                                                        |
+| Local (kind/minikube) | `values-local.yaml` | Ingress on `api.localhost` / `studio.localhost`                                       |
+
+## Object storage
+
+To connect an S3-compatible object store (S3, GCS with HMAC interoperability, or MinIO), set the generic object-store values on the server:
+
+```yaml
+mastra-server:
+  externalServices:
+    objectStore:
+      endpoint: https://storage.googleapis.com
+      bucket: my-mastra-bucket
+      region: us-central1
+```
+
+Put `S3_ACCESS_KEY_ID` and `S3_SECRET_ACCESS_KEY` in your existing Secret rather than in values. On EKS and GKE, prefer IRSA or Workload Identity over static keys.
+
+## Scale server replicas
+
+The chart starts one Server replica by default. A HorizontalPodAutoscaler can add pods, but it doesn't make Mastra's in-process state available across them.
+
+Before setting `replicaCount` above one or enabling `mastra-server.autoscaling`:
+
+- Configure a shared storage backend, such as `PostgresStore`, for persisted run state.
+- Configure a distributed PubSub backend and shared cache. The [Kubernetes guide](https://mastra.ai/integrations/deploy/kubernetes) uses `RedisStreamsPubSub` and `RedisServerCache`, with `REDIS_URL` stored in the application Secret.
+- Use [durable agents](https://mastra.ai/docs/harness/durable-agents) for streams, approvals, and runs that must continue when requests reach different pods.
+- Start with one replica to initialize the database schema before scaling. For stricter deployments, initialize the schema in a Kubernetes Job and disable initialization in each pod.
+- Review [worker roles](https://mastra.ai/docs/deployment/workers). Run only one scheduler instance when your application uses scheduled workflows.
+
+After those requirements are in place, set resource requests and enable autoscaling:
+
+```yaml
+mastra-server:
+  resources:
+    requests:
+      cpu: 250m
+      memory: 512Mi
+  autoscaling:
+    enabled: true
+    minReplicas: 2
+    maxReplicas: 5
+    targetCPUUtilizationPercentage: 80
+```
+
+## Production checklist
+
+- Reference credentials with `existingSecret` instead of plaintext values.
+- Set resource requests via `mastra-server.resources` and `mastra-studio.resources`.
+- Prefer standalone cert-manager and ingress controller installs over the bundled toggles; CRD lifecycle inside an umbrella chart complicates upgrades.
+- Enable multiple replicas only after configuring shared storage, distributed PubSub, shared cache, and the required process roles.
+- The chart applies hardened defaults: non-root containers, read-only root filesystem, seccomp `RuntimeDefault`, and no service account token automount.
+
+## Upgrade and uninstall
+
+Upgrade to a new chart version or roll out a new image tag with the same command:
+
+```bash
+CHART_VERSION=0.2.0
+CHART=oci://us-central1-docker.pkg.dev/mastra-cloud/mastra-helm-ee/mastra-projects
+
+helm upgrade mastra "$CHART" \
+  --version "$CHART_VERSION" \
+  -n mastra -f mastra-values.yaml
+```
+
+The chart hashes config and secret contents into pod annotations, so configuration changes trigger a rolling restart automatically.
+
+Uninstall the release:
+
+```bash
+helm uninstall mastra -n mastra
+```
+
+Your database and object store are unaffected, because the chart never manages stateful services.
+
+## Troubleshooting
+
+- **`helm install`/`upgrade` fails with `401 Unauthorized` or `UNAUTHORIZED`.** Your registry access token is missing or expired. Request a fresh token from `https://license.mastra.ai/v1/registry-token` using your Enterprise license and run `helm registry login` again.
+- **Pods crash with `Cannot find module '@libsql/linux-x64-gnu'` (or similar).** The image contains `node_modules` built for a different platform. Install dependencies inside the image and exclude host-built `node_modules` via `.dockerignore`, then rebuild with `--platform` matching your nodes.
+- **Pods crash-loop with a license error.** Production mode requires a valid `MASTRA_EE_LICENSE` in your secret when enterprise features are configured.
+- **Studio shows the server API instead of the UI.** The image was built without Studio assets. Rebuild with `mastra build --studio`.
+- **Ingress has no address.** Confirm an ingress controller is running, or set `ingressController.install=true`.
+- **Certificates stay pending in gateway mode.** Some Gateway controllers can't serve ACME challenges until a listener certificate exists. Check the chart's per-cloud presets and release notes for the bootstrap procedure on your platform.
+
+## Related
+
+- [Kubernetes](https://mastra.ai/integrations/deploy/kubernetes): Hand-written manifests and multi-pod scaling with shared pub/sub
+- [Mastra server](https://mastra.ai/docs/deployment/mastra-server): Build output and server behavior
+- [Deployment overview](https://mastra.ai/docs/deployment/overview)
+- [Workers](https://mastra.ai/docs/deployment/workers): Split background processing into separate containers

package/.docs/integrations/deploy/kubernetes.md

@@ -4,7 +4,7 @@
 
 Run a Mastra application across multiple pods on [Kubernetes](https://kubernetes.io/), so it scales horizontally behind a load balancer. Because each pod is a separate process, the pods must share a pub/sub backend and a database, otherwise work started on one pod is invisible to the others.
 
-> **Note:** This guide covers deploying the [Mastra server](https://mastra.ai/docs/server/overview). If you're using a [server adapter](https://mastra.ai/docs/server/server-adapters) or [web framework](https://mastra.ai/docs/deployment/web-framework), deploy the way you normally would for that framework.
+> **Note:** This guide covers deploying the [Mastra server](https://mastra.ai/docs/server/overview) with hand-written manifests. To deploy Mastra Server and Studio with a managed chart instead, see [Kubernetes (Helm)](https://mastra.ai/integrations/deploy/kubernetes-helm). If you're using a [server adapter](https://mastra.ai/docs/server/server-adapters) or [web framework](https://mastra.ai/docs/deployment/web-framework), deploy the way you normally would for that framework.
 
 > **Beta:** Multi-pod support relies on [durable agents](https://mastra.ai/docs/harness/durable-agents). Breaking changes may occur without a major version bump until the API is stable. Read [Known limitations](#known-limitations) before you rely on this in production.
 

package/.docs/integrations/deploy/render.md

@@ -12,7 +12,7 @@ Choose the deployment path that fits your application:
 
 This guide builds an editorial pipeline that reviews a draft from three perspectives in parallel, then passes the feedback to an editor agent. Use the links above if you want to deploy a Mastra API or execute an entire Mastra workflow as one task.
 
-## How Render Workflows works with Mastra
+## How Render Workflows integrate with Mastra
 
 Mastra supplies the agents and application logic, while Render Workflows defines the execution boundaries. A typical pipeline has three layers:
 
@@ -93,8 +93,6 @@ yarn add @renderinc/sdk tsx
 bun add @renderinc/sdk tsx
 ```
 
-> **Note:** Render Workflows requires `@renderinc/sdk@^0.5.0` or later.
-
 Set the API key for your model provider. This example uses OpenAI:
 
 ```text
@@ -103,9 +101,9 @@ OPENAI_API_KEY=your_openai_api_key
 
 Any supported [Mastra model provider](https://mastra.ai/models) works.
 
-## Building a distributed agent pipeline
+## Build a distributed agent pipeline
 
-### Creating the agents
+### Create the agents
 
 In `src/mastra`, create an `agents` directory with `reviewer-agent.ts` and `editor-agent.ts`. Define both agents:
 
@@ -139,7 +137,7 @@ export const editorAgent = new Agent({
 })
 ```
 
-### Configuring the Mastra instance
+### Configure the Mastra instance
 
 Add both agents to the Mastra instance in `src/mastra/index.ts`:
 
@@ -158,7 +156,7 @@ export const mastra = new Mastra({
 
 Retrieving agents from the Mastra instance gives them access to shared application services such as logging, storage, and observability.
 
-### Creating the review task
+### Create the review task
 
 In `src`, create a `tasks` directory. The reviewer agent handles one area of focus. Its compute plan, five-minute timeout, and retry policy apply only to that analysis. A temporary model-provider failure can trigger another attempt without restarting the other reviewers.
 
@@ -199,7 +197,7 @@ export const reviewDraft = task(
 )
 ```
 
-### Creating the revision task
+### Create the revision task
 
 This task combines the feedback and produces a revised draft. It uses a larger compute plan and a longer timeout than each reviewer.
 
@@ -240,7 +238,7 @@ export const reviseDraft = task(
 )
 ```
 
-### Creating the orchestration task
+### Create the orchestration task
 
 The parent dispatches three reviews in parallel with `Promise.all()`, then sends their combined feedback to the revision step. Retries are disabled at this level because each child defines its own policy. If you enable orchestration retries, ensure that another attempt cannot duplicate external side effects or other non-idempotent work.
 
@@ -268,7 +266,7 @@ export const editorialPipeline = task(
 )
 ```
 
-### Registering the tasks
+### Register the tasks
 
 Create `src/index.ts` and import the editorial task:
 
@@ -278,7 +276,7 @@ import './tasks/editorial-task.js'
 
 Running the entry point loads the module and registers every task defined with `task()`.
 
-`create mastra` already wrote `tsconfig.json` and `package.json`. Keep those files. For the workflow start command, `tsc` must emit JavaScript into `dist`, so set these compiler options (do not leave `noEmit: true`):
+Change your `tsconfig.json`:
 
 ```json
 {
@@ -292,7 +290,7 @@ Running the entry point loads the module and registers every task defined with `
 }
 ```
 
-Add these scripts next to the ones `create mastra` already added. `create mastra` already sets `"type": "module"`:
+Add these scripts to `package.json`:
 
 ```json
 {
@@ -304,13 +302,11 @@ Add these scripts next to the ones `create mastra` already added. `create mastra
 }
 ```
 
-Relative imports in the examples above end in `.js` because Node resolves the compiled output as ES modules. Keep those extensions so the built entry point resolves its imports.
-
-Those files are the complete pipeline. [render-examples/render-workflows-mastra](https://github.com/render-examples/render-workflows-mastra) mirrors this `src/` layout and adds a web UI that starts the parent task. Its agents use the provider-specific model ID `openai/gpt-5.6-sol`. In this page's source, that value is represented by a documentation token that is replaced during the docs build. Clone it to skip copying the snippets before you run it.
+Those files are the complete pipeline. [render-examples/render-workflows-mastra](https://github.com/render-examples/render-workflows-mastra) mirrors this `src/` layout and adds a web UI that starts the parent task.
 
-## Running the pipeline
+## Run the pipeline
 
-### Running locally
+### Local
 
 Start the local Render Workflows development server:
 
@@ -334,56 +330,56 @@ render workflows tasks start editorial_pipeline \
 
 The local server keeps runs and their logs in memory, so you can inspect them after they finish with `render workflows runs list <task-name> --local`.
 
-### Running in production
+### Production
 
 Running the pipeline on Render requires a _workflow service_. This is the Render service that holds your task definitions: it builds your repository, registers every task it finds, and provisions an instance for each run.
 
-#### 1. Push the project to a Git repository
+1. #### Push the project to a Git repository
 
-Render builds workflow services from a repository on GitHub, GitLab, or Bitbucket, so push your project to one of those providers. The first time you use a provider, Render asks for permission to access your repositories.
+   Render builds workflow services from a repository on GitHub, GitLab, or Bitbucket, so push your project to one of those providers. The first time you use a provider, Render asks for permission to access your repositories.
 
-#### 2. Create the workflow service
+2. #### Create the workflow service
 
-In the [Render Dashboard](https://dashboard.render.com), click **New > Workflow** and link the repository from the previous step. Then complete the creation form:
+   In the [Render Dashboard](https://dashboard.render.com), click **New > Workflow** and link the repository from the previous step. Then complete the creation form:
 
-| Field             | Value                                                         |
-| ----------------- | ------------------------------------------------------------- |
-| **Language**      | Node                                                          |
-| **Region**        | The region of any other Render services your tasks connect to |
-| **Build Command** | `npm install && npm run build`                                |
-| **Start Command** | `npm run start:workflows`                                     |
+   | Field             | Value                                                         |
+   | ----------------- | ------------------------------------------------------------- |
+   | **Language**      | Node                                                          |
+   | **Region**        | The region of any other Render services your tasks connect to |
+   | **Build Command** | `npm install && npm run build`                                |
+   | **Start Command** | `npm run start:workflows`                                     |
 
-Click **Deploy Workflow**. Render builds the project and registers `review_draft`, `revise_draft`, and `editorial_pipeline`, which then appear on the workflow's **Tasks** page.
+   Click **Deploy Workflow**. Render builds the project and registers `review_draft`, `revise_draft`, and `editorial_pipeline`, which then appear on the workflow's **Tasks** page.
 
-The Render CLI creates the same service without leaving your terminal:
+   The Render CLI creates the same service without leaving your terminal:
 
-```bash
-render workflows create \
-  --name mastra-workflows \
-  --repo . \
-  --runtime node \
-  --build-command "npm install && npm run build" \
-  --run-command "npm run start:workflows"
-```
+   ```bash
+   render workflows create \
+     --name mastra-workflows \
+     --repo . \
+     --runtime node \
+     --build-command "npm install && npm run build" \
+     --run-command "npm run start:workflows"
+   ```
 
-`--repo .` reads the `origin` remote of your local repository, so the project must already be pushed.
+   `--repo .` reads the `origin` remote of your local repository, so the project must already be pushed.
 
-#### 3. Set the workflow's environment variables
+3. #### Set the workflow's environment variables
 
-Add `OPENAI_API_KEY`, or the key for your chosen model provider, to the workflow service in the Dashboard before the first run.
+   Add `OPENAI_API_KEY`, or the key for your chosen model provider, to the workflow service in the Dashboard before the first run.
 
-#### 4. Start a run
+4. #### Start a run
 
-```bash
-render workflows tasks start mastra-workflows/editorial_pipeline \
-  --input='["Render Workflows runs long-running tasks outside the request lifecycle."]'
-```
+   ```bash
+   render workflows tasks start mastra-workflows/editorial_pipeline \
+     --input='["Render Workflows runs long-running tasks outside the request lifecycle."]'
+   ```
 
-The first part of that identifier is your workflow's slug and the second is the task name. Both appear on the task's page in the Render Dashboard, so use the slug shown there if your workflow has a different name.
+   The first part of that identifier is your workflow's slug and the second is the task name. Both appear on the task's page in the Render Dashboard, so use the slug shown there if your workflow has a different name.
 
-Open the workflow in the Render Dashboard to inspect each task run, attempt, result, and log stream.
+   Open the workflow in the Render Dashboard to inspect each task run, attempt, result, and log stream.
 
-## Triggering from your application
+## Trigger from your application
 
 You can trigger the pipeline asynchronously from a Mastra application, web service, or script with the Render SDK.
 
@@ -415,17 +411,6 @@ The task continues running after `startTask()` returns. Call `await run.get()` w
 
 Returning the task run ID from a request handler lets the application respond without keeping the request open for the full pipeline.
 
-## Constraints
-
-These limits live in Render's docs and can change. Prefer those pages over this list:
-
-- Task arguments and return values must be JSON serializable. Arguments to a single run cannot exceed 4 MB. See [defining tasks](https://render.com/docs/workflows-defining#task-arguments) and [Workflows limits](https://render.com/docs/workflows-limits).
-- A task can run for up to 24 hours. The default timeout is two hours. See [timeouts](https://render.com/docs/workflows-defining#timeout).
-- A workflow service can register up to 500 task definitions. See [Workflows limits](https://render.com/docs/workflows-limits).
-- Render Workflows currently supports TypeScript and Python task definitions. See [defining tasks](https://render.com/docs/workflows-defining).
-
-To run the pipeline on a schedule, create a [Render cron job](https://render.com/docs/cronjobs) whose command calls `render workflows tasks start` or `startTask()`.
-
 ## Related
 
 - [Live demo](https://render-workflows-mastra.onrender.com)
@@ -433,4 +418,5 @@ To run the pipeline on a schedule, create a [Render cron job](https://render.com
 - [Defining Render workflow tasks](https://render.com/docs/workflows-defining)
 - [Triggering task runs](https://render.com/docs/workflows-running)
 - [Render Workflows TypeScript SDK](https://render.com/docs/workflows-sdk-typescript)
-- [Render Workflows limits and pricing](https://render.com/docs/workflows-limits)
+- [Render Workflows limits and pricing](https://render.com/docs/workflows-limits)
+- [Render cron jobs](https://render.com/docs/cronjobs)

package/.docs/integrations/sandboxes/daytona.md

@@ -282,6 +282,52 @@ await sandbox.instance.updateNetworkSettings({
 })
 ```
 
+### Secrets
+
+Inject credentials without exposing raw values to code running inside the sandbox. Create a [Daytona Secret](https://www.daytona.io/docs/en/secrets/) once for your organization (via the Daytona dashboard or SDK), then map environment variable names to Secret names:
+
+```typescript
+const workspace = new Workspace({
+  sandbox: new DaytonaSandbox({
+    secrets: {
+      GITHUB_TOKEN: 'github-token',
+    },
+  }),
+})
+```
+
+Inside the sandbox, the environment variable holds an opaque placeholder. Daytona's egress proxy substitutes the real value into HTTPS request headers toward the Secret's allowed hosts, so the raw credential never enters the sandbox. Secrets are applied at sandbox creation and are preserved by `clone()`.
+
+### Computer use (desktop)
+
+`DaytonaSandbox` exposes the [computer capability](https://mastra.ai/docs/sandbox/overview): screenshot, mouse, and keyboard control of a desktop environment inside the sandbox. When the sandbox is used in a workspace, agents automatically get the `mastra_workspace_computer_*` tools.
+
+The desktop processes (Xvfb, xfce4, x11vnc, noVNC) are started lazily on the first computer operation:
+
+```typescript
+const sandbox = new DaytonaSandbox()
+await sandbox.start()
+
+await sandbox.computer.leftClick(100, 200)
+await sandbox.computer.type('hello')
+const { data } = await sandbox.computer.screenshot() // PNG bytes
+
+// Live desktop view via the noVNC preview link
+const url = await sandbox.computer.streamUrl()
+```
+
+Disable the capability, or manage the desktop processes yourself, with the `computerUse` option:
+
+```typescript
+// No computer capability, no computer tools
+new DaytonaSandbox({ computerUse: false })
+
+// Capability stays on, but you call sandbox.daytona.computerUse.start() yourself
+new DaytonaSandbox({ computerUse: { autoStart: false } })
+```
+
+For Daytona-specific desktop APIs (regions, compressed screenshots, screen recording, accessibility tree), use the [direct SDK access](#direct-sdk-access) escape hatch: `sandbox.daytona.computerUse`.
+
 ## Constructor parameters
 
 **id** (`string`): Unique identifier for this sandbox instance. (Default: `Auto-generated`)
@@ -328,6 +374,10 @@ await sandbox.instance.updateNetworkSettings({
 
 **domainAllowList** (`string`): Comma-separated list of allowed domains when network access is restricted. Supports wildcards, for example \*.githubusercontent.com. Use this instead of networkAllowList for services whose IP addresses change.
 
+**secrets** (`Record<string, string>`): Daytona Secrets to expose inside the sandbox, mapping environment variable names to Daytona Secret names. The env var holds an opaque placeholder; the real value is substituted into HTTPS request headers at egress toward the Secret's allowed hosts.
+
+**computerUse** (`boolean | { autoStart?: boolean; noVncPort?: number }`): Computer-use (desktop) capability configuration. Set to false to disable the capability. Set autoStart to false to manage the desktop processes yourself. noVncPort sets the noVNC viewer port used by computer.streamUrl(). (Default: `true`)
+
 ## Properties
 
 **id** (`string`): Sandbox instance identifier.
@@ -342,6 +392,8 @@ await sandbox.instance.updateNetworkSettings({
 
 **processes** (`DaytonaProcessManager`): Background process manager. See SandboxProcessManager reference.
 
+**computer** (`SandboxComputer | undefined`): Computer-use capability: screenshot, mouse, keyboard, and stream URL. Undefined when constructed with computerUse: false. See SandboxComputer reference.
+
 ## Background processes
 
 `DaytonaSandbox` includes a built-in process manager for spawning and managing background processes. Processes run in the Daytona cloud sandbox using session-based command execution.