---

name: deployment-configuration description: "Operate TaskingAI self-hosted deployment topology, environment configuration, storage choices, health checks, and deployment troubleshooting." disable-model-invocation: true metadata: disco-role: operating license: Apache 2.0

deployment-configuration

Use this sub-skill when the task is to self-host, inspect, configure, or troubleshoot a TaskingAI deployment rather than to reason about TaskingAI business objects or provider/plugin schemas.

Read when

• A user is starting, upgrading, or diagnosing a self-hosted TaskingAI stack.
• The task mentions Docker Compose, service roles, ports, health checks, nginx routing, image tags, or version skew.
• The task asks whether environment variables are sufficient, especially TASKINGAI_INFERENCE_URL, TASKINGAI_PLUGIN_URL, OBJECT_STORAGE_TYPE, local storage, or S3 storage.
• The console is deployed but cannot reach API routes, generated files, provider icons, plugin icons, inference, plugin execution, Postgres, or Redis.

Route elsewhere

• Backend object models, REST object semantics, authentication flows, assistant/retrieval/tool/model APIs, database models, and request/response bodies belong to ../backend-api/.
• Provider/model catalogs, provider credentials, model schema details, credential validation behavior, and provider execution belong to ../inference-providers/.
• Plugin bundle catalogs, plugin execution semantics, plugin bundle storage details beyond deployment-level storage selection, and bundle-specific failures belong to ../plugin-bundles/.
• Deep React/frontend implementation is out of scope; the console is treated here only as a deployed service behind nginx.

Operating pattern

1. Identify the deployment shape: full Compose stack, standalone microservices for development, or a user-modified deployment.
2. Map service reachability before changing application settings: external HOST_URL, nginx public port, internal service DNS names or host ports, and health-check paths.
3. Audit the environment against configuration. For OBJECT_STORAGE_TYPE=s3, fail the audit if required S3 fields are missing; do not wait for runtime upload failures.
4. Use deployment workflows for the Compose topology, service roles, storage mode decisions, upgrade/version-skew checks, and safe native-test skip criteria.
5. Use troubleshooting to turn symptoms into likely causes and recovery steps. Start with network topology and env mismatches before escalating to backend/provider/plugin semantics.

Minimum facts to collect from the user or running deployment

• Deployment manager and manifest location, if any, without assuming the original source checkout exists.
• Current image tags for console/server/inference/plugin, and whether they were changed independently.
• External base URL and published HTTP port.
• Storage mode (local or s3) and whether generated files must be publicly reachable.
• Backend-to-inference and backend-to-plugin URLs as seen from the backend service network.
• Whether Docker/service startup, network image pulls, port binding, external provider calls, or S3 calls are allowed for this task.

Native-testing stance

The source-backed native deployment case for this sub-skill is a full multi-container stack. Treat it as optional and side-effectful: it pulls images, starts system services, binds ports, creates persistent volumes, and may need network/S3/provider credentials. Prefer static env/topology audits unless the user explicitly authorizes service startup and supplies a suitable deployment environment. Expected native success signals are healthy service checks and a reachable console on the configured public URL.