How do I install the Service Deployment Orchestrator skill?

Run npx skillmds@latest add knuckles-team/service-deployment-orchestrator in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Service Deployment Orchestrator safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Service Deployment Orchestrator?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Service Deployment Orchestrator free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Service Deployment Orchestrator?

Knuckles-Team (@knuckles-team) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Service Deployment Orchestrator by knuckles-team

Name: Service Deployment Orchestrator
Author: Knuckles-Team

Service Deployment Orchestrator

Deploy a containerized service through configured source-control, DNS, routing, OIDC, registry, orchestrator, observability, and health-monitor providers. Use when a new service must be provisioned end-to-end from AgentConfig profile references. Do not use for an ad hoc local container or raw endpoint setup.

Knuckles-Team d522c62 2 files · 3.4 KB Updated Sep 17, 2026

File contents

service-deployment-orchestrator Workflow

Deploy a containerized service without embedding deployment topology. Every step accepts named AgentConfig connection or policy references; provider URLs, realms, namespaces, node identities, credentials, and local paths remain external.

Step 0: user-interaction

Gather the service contract and named source-control, DNS, routing, identity, registry, orchestrator, observability, and monitoring profile references. Reject raw endpoints, credentials, hostnames, nodes, namespaces, and local paths. Expected: service_specifications

Step 1: gitlab-repository-seeder [depends_on: Step 0]

Provision a Git repository on GitLab CE, configure CI/CD variables, and push standard boilerplate configurations (compose.yml, .gitlab-ci.yml, README.md, AGENTS.md). Expected: git_repository_url

Step 2: dns-record-manager [depends_on: Step 0]

Register zone records (A/CNAME) for the service subdomain in Technitium DNS pointing to the primary Caddy reverse-proxy host. Expected: dns_record_status

Step 3: caddy-route-manager [depends_on: Step 0]

Generate proxy route configuration blocks, append them to Caddyfile, and perform a hot reload of the Caddy service. Expected: caddy_route_status

Step 4: keycloak-client-onboarder [depends_on: Step 0]

Onboard the service through the configured OIDC provider and realm reference. Expected: oidc_client_credentials

Step 5: portainer-sync-agent [depends_on: Step 1, Step 2, Step 3, Step 4]

Deploy or update the stack through the configured orchestrator and verified registry connection/trust profile. Never enable an insecure registry fallback. Expected: swarm_stack_status

Step 6: service-observability-provisioner [depends_on: Step 5]

Integrate the container log path with Promtail, verify Prometheus is scraping service metrics, and execute an end-to-end service health sweep check. Expected: service_health_report

Step 7: uptime-kuma-sync [depends_on: Step 5]

Discover the Caddy front-end routing entry and provision a corresponding HTTP health monitor in the Uptime Kuma monitoring service. Expected: uptime_kuma_sync_status

Execution

Run this workflow as a dependency-ordered DAG. Steps with no unmet depends_on run in parallel; dependents run after their prerequisites complete.

Run first (in parallel): Step 0 — user-interaction
After level 0: Step 1 — gitlab-repository-seeder; Step 2 — dns-record-manager; Step 3 — caddy-route-manager; Step 4 — keycloak-client-onboarder
After level 1: Step 5 — portainer-sync-agent
After level 2: Step 6 — service-observability-provisioner; Step 7 — uptime-kuma-sync

Execution: If graph-os is reachable, offload the whole DAG via graph_orchestrate action=execute_workflow (or the kg-delegate skill) for true parallel/swarm execution. Otherwise execute the steps natively in dependency order: run steps with no unmet depends_on in parallel, then their dependents.

---name: service-deployment-orchestratordescription: Deploy a containerized service through configured source-control, DNS, routing, OIDC, registry, orchestrator, observability, and health-monitor providers. Use when a new service must be provisioned end-to-end from AgentConfig profile references. Do not use for an ad hoc local container or raw endpoint setup.---# service-deployment-orchestrator WorkflowDeploy a containerized service without embedding deployment topology. Every stepaccepts named AgentConfig connection or policy references; provider URLs, realms,namespaces, node identities, credentials, and local paths remain external.### Step 0: user-interactionGather the service contract and named source-control, DNS, routing, identity,registry, orchestrator, observability, and monitoring profile references. Rejectraw endpoints, credentials, hostnames, nodes, namespaces, and local paths.Expected: service_specifications### Step 1: gitlab-repository-seeder [depends_on: Step 0]Provision a Git repository on GitLab CE, configure CI/CD variables, and push standard boilerplate configurations (compose.yml, .gitlab-ci.yml, README.md, AGENTS.md).Expected: git_repository_url### Step 2: dns-record-manager [depends_on: Step 0]Register zone records (A/CNAME) for the service subdomain in Technitium DNS pointing to the primary Caddy reverse-proxy host.Expected: dns_record_status### Step 3: caddy-route-manager [depends_on: Step 0]Generate proxy route configuration blocks, append them to Caddyfile, and perform a hot reload of the Caddy service.Expected: caddy_route_status### Step 4: keycloak-client-onboarder [depends_on: Step 0]Onboard the service through the configured OIDC provider and realm reference.Expected: oidc_client_credentials### Step 5: portainer-sync-agent [depends_on: Step 1, Step 2, Step 3, Step 4]Deploy or update the stack through the configured orchestrator and verifiedregistry connection/trust profile. Never enable an insecure registry fallback.Expected: swarm_stack_status### Step 6: service-observability-provisioner [depends_on: Step 5]Integrate the container log path with Promtail, verify Prometheus is scraping service metrics, and execute an end-to-end service health sweep check.Expected: service_health_report### Step 7: uptime-kuma-sync [depends_on: Step 5]Discover the Caddy front-end routing entry and provision a corresponding HTTP health monitor in the Uptime Kuma monitoring service.Expected: uptime_kuma_sync_status## ExecutionRun this workflow as a dependency-ordered DAG. Steps with no unmet `depends_on` run in parallel; dependents run after their prerequisites complete.- **Run first (in parallel):** Step 0 — user-interaction- **After level 0:** Step 1 — gitlab-repository-seeder; Step 2 — dns-record-manager; Step 3 — caddy-route-manager; Step 4 — keycloak-client-onboarder- **After level 1:** Step 5 — portainer-sync-agent- **After level 2:** Step 6 — service-observability-provisioner; Step 7 — uptime-kuma-sync**Execution:** If graph-os is reachable, offload the whole DAG via `graph_orchestrate action=execute_workflow` (or the `kg-delegate` skill) for true parallel/swarm execution. Otherwise execute the steps natively in dependency order: run steps with no unmet `depends_on` in parallel, then their dependents.

Frequently asked questions