docs: explain shared-nothing profile resolution

server-admin/distributed/workers/shared-filesystem.md

@@ -1,22 +1,22 @@
 # Migrating Shared-Filesystem Workers
 
-Dagu 2.9 removed direct shared-filesystem access from daemon workers. Current `dagu worker` processes require coordinator addresses and exchange tasks, status, logs, artifacts, and persistent state over gRPC.
+Current `dagu worker` processes require coordinator addresses and exchange tasks, profiles, Dagu-managed secrets, status, logs, artifacts, and persistent state over gRPC.
 
 This page remains at its old URL for upgrade guidance. For current setup instructions, see [Worker Deployment](./shared-nothing).
 
 ## Current Worker Contract
 
 - Set `worker.coordinators` or `DAGU_WORKER_COORDINATORS`.
 - Give every coordinator a stable address reachable from workers.
-- Keep server data, DAG definitions, logs, and artifacts off worker mounts.
+- Keep server data, DAG definitions, profiles, Dagu-managed secrets, logs, and artifacts off worker mounts.
 - Use worker-local or ephemeral storage for work directories and caches.
 - Declare DAG-local files with [`dependencies`](/writing-workflows/file-dependencies); Dagu transfers them with the task.
 
 Server-side processes may still share persistent storage when deployed separately. The Web UI/API server, scheduler, and coordinator need a consistent view of server-owned state.
 
 ## Migration
 
-1. Drain and stop existing workers.
+1. Keep existing worker mounts while upgrading every coordinator to a version that supports coordinator-side profile and managed-secret resolution.
 2. Bind the coordinator to a worker-reachable interface and set its advertise address:
 
    ```bash
@@ -26,17 +26,18 @@ Server-side processes may still share persistent storage when deployed separatel
      --coordinator.port=50055
    ```
 
-3. Configure each worker with one or more coordinator addresses:
+3. Drain and stop existing workers.
+4. Configure each worker with one or more coordinator addresses:
 
    ```bash
    dagu worker \
      --worker.coordinators=coordinator.internal:50055 \
      --worker.labels=region=us-east-1
    ```
 
-4. Remove server data and DAG-directory mounts from worker containers or pods.
-5. Keep coordinator-owned state on persistent storage when it must survive coordinator replacement.
-6. Configure [peer TLS or mTLS](/server-admin/distributed/transport-security) when coordinator traffic crosses an untrusted network.
+5. Remove server data and DAG-directory mounts from worker containers or pods.
+6. Keep coordinator-owned state on persistent storage when it must survive coordinator replacement.
+7. Configure [peer TLS or mTLS](/server-admin/distributed/transport-security) when coordinator traffic crosses an untrusted network.
 
 ## Docker Compose
 

server-admin/distributed/workers/shared-nothing.md

@@ -28,6 +28,14 @@ Workers operate without access to server-side storage. They receive tasks and se
 
 The DAG definition is sent with each dispatched task. If a step also needs files from the authored DAG directory, declare them with step-level [`dependencies`](/writing-workflows/file-dependencies). The coordinator snapshots the DAG and matching files, transfers the workspace bundle, and the worker materializes it as `DAG_RUN_WORK_DIR`. Files beside the DAG are left out unless they match a declaration, so workers do not need access to the source filesystem.
 
+### Runtime Profiles and Secrets
+
+The coordinator that owns a task resolves Global, workspace, and selected [runtime profile](/writing-workflows/runtime-profiles) layers. It also resolves Dagu-managed [`secrets[].ref`](/writing-workflows/secrets#registry-refs) values. Workers do not need server profile or secret stores. Child DAGs inherit the selected profile and resolve defaults and managed secret refs against the child's workspace.
+
+Direct secret providers resolve where the DAG executes. Give workers the provider configuration, credentials, files, and network access required by those providers. These workflow resources are separate from the Dagu server data volume.
+
+Resolved profile and managed-secret values travel over coordinator gRPC. Configure [peer TLS or mTLS](/server-admin/distributed/transport-security) outside an isolated trusted network.
+
 ### Coordinator Addresses
 
 Workers connect directly to coordinators using explicit addresses:
@@ -274,7 +282,7 @@ spec:
             - "worker"
             - "--worker.coordinators=dagu-coordinator.default.svc.cluster.local:50055"
             - "--worker.labels=region=us-east-1"
-          # No volume mounts needed - all state via gRPC
+          # No Dagu server volume: control-plane state uses gRPC
 ```
 
 For Helm-based Kubernetes deployment, see [Kubernetes (Helm)](/server-admin/deployment/kubernetes).

web-ui/profiles.md

@@ -69,6 +69,8 @@ Rotating a secret entry writes a new secret value. New runs and new retry attemp
 
 When starting or enqueueing a DAG from the Web UI, select a profile from the **Profile** field in the start dialog. If no profile is selected, the run still receives any matching Global or workspace default entries, plus the environment, parameters, and secrets defined by the DAG and server configuration.
 
+The same selection applies to distributed runs. Profiles remain coordinator-managed and require no per-worker profile configuration or server data mount.
+
 ![Start DAG dialog showing the runtime profile selector](/runtime-profile-start-dialog.png)
 
 Run history and run details show the selected profile name when a profile was used.
@@ -94,6 +96,7 @@ This also applies to profile default layers. Default-layer secret entries should
 - [Runtime Profiles](/writing-workflows/runtime-profiles)
 - [DAG Secret Refs](/web-ui/secrets)
 - [Workflow Secrets](/writing-workflows/secrets)
+- [Worker Deployment](/server-admin/distributed/workers/shared-nothing)
 - [Workspaces](/web-ui/workspaces)
 - [User Management](/server-admin/authentication/user-management)
 - [Multi-Environment Deployments](/server-admin/deployment/multi-environment)

writing-workflows/runtime-profiles.md

@@ -154,6 +154,12 @@ Secret entry plaintext is write-only. API and UI responses show secret entry met
 
 Default profile entries are fallback values. A selected profile overrides default layers for matching keys. Step-level `env:` can still override variables for a single step. Profile secrets are treated as secrets, so they participate in secret masking. Avoid reusing the same key across DAG `env:`, DAG `secrets:`, default layers, and selected profiles unless the override behavior is intentional.
 
+### Distributed Runs
+
+For a distributed run, the coordinator that owns the task resolves the profile layers and sends the values to the active worker. Workers do not need a copy of the profile or Dagu-managed secret stores. Child DAGs inherit the selected profile while resolving defaults against each child's workspace, including nested children started from a worker.
+
+Profile secrets travel over coordinator gRPC. Configure [peer TLS or mTLS](/server-admin/distributed/transport-security) outside an isolated trusted network.
+
 ## Retries
 
 Retries inherit the original run's profile name. Profile selection is immutable across retry paths, including CLI, API, queue, scheduler, worker, and sub-DAG retry flows.
@@ -264,5 +270,6 @@ Secret values are write-only. Profile responses include the secret entry key, ki
 - [Environment Variables](/writing-workflows/environment-variables)
 - [Workflow Secrets](/writing-workflows/secrets)
 - [Runtime Context and Variables](/writing-workflows/runtime-variables)
+- [Worker Deployment](/server-admin/distributed/workers/shared-nothing)
 - [Web UI Profiles](/web-ui/profiles)
 - [Multi-Environment Deployments](/server-admin/deployment/multi-environment)

writing-workflows/secrets.md

@@ -178,6 +178,14 @@ When a DAG run starts, Dagu:
 
 If any secret fails to resolve, run initialization fails and steps do not execute. `dagu dry` also resolves secrets. `dagu validate` checks YAML shape and DAG structure, but it does not contact providers and does not verify that a secret exists.
 
+## Distributed Runs
+
+For distributed runs, the coordinator that owns the task resolves Dagu-managed registry refs for the active worker. Nested child DAGs resolve refs against each child's workspace. Workers do not need the server secret store or data volume.
+
+Direct provider refs resolve where the DAG executes. A distributed worker therefore needs the provider configuration, credentials, files, identity, and network access used by those refs. For example, a `file` provider path must exist on that worker.
+
+Managed secret values travel over coordinator gRPC. Configure [peer TLS or mTLS](/server-admin/distributed/transport-security) outside an isolated trusted network.
+
 ## Variable Precedence
 
 During step execution, the environment scope is layered so later layers override earlier layers:
@@ -239,6 +247,7 @@ Masking is not a process sandbox. The step process receives the raw secret in it
 ## Provider Pages
 
 - [Runtime Profiles](/writing-workflows/runtime-profiles)
+- [Worker Deployment](/server-admin/distributed/workers/shared-nothing)
 - [Web UI DAG Secret Refs](/web-ui/secrets)
 - [Dotenv Loading](/writing-workflows/secrets/dotenv)
 - [`env` Provider](/writing-workflows/secrets/env-provider)