# Deploy New Service

> Orchestrate a new homelab service from declared configuration through live verification. Use when the user says "deploy a new service", "add this app to the homelab", "create the compose stack", "put this behind SWAG", or requests a complete service rollout. Create version-controlled Compose and documentation, invoke create-swag-config when needed, validate desired state, deploy to the selected host, verify runtime health, update inventory, and finish with wrap-session. Never place real secrets in Git and never overwrite or remove an existing deployment without explicit authorization.

- Skill: `dinglebear-ai/deploy-new-service` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add dinglebear-ai/deploy-new-service`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dinglebear-ai/deploy-new-service/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: dinglebear-ai (https://skillmd.com/u/dinglebear-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dinglebear-ai/deploy-new-service

---


# Deploy New Service

Build the service as one independent Compose project inside the homelab source-of-truth repository, then deploy it to the selected host.

## Phases

1. **Discover**: identify service, target host, ports, storage, networks, authentication, public exposure, health checks, backup needs, and upstream documentation.
2. **Pattern match**: inspect neighboring services on the target host and the homelab standards. Do not invent paths, networks, or IPs.
3. **Declare**: create the Compose file, `.env.example`, service README, non-secret config, inventory entry, and rollback notes.
4. **Proxy**: when public or routed access is required, invoke `create-swag-config`. Keep SWAG config with the SWAG deployment's tracked configuration.
5. **Validate**: run Compose parsing, secret scanning, path checks, external-network checks, image or config validation, and nginx validation when applicable.
6. **Safety**: confirm persistent-data paths, backup or snapshot requirements, collision-free ports, and rollback steps before live changes.
7. **Deploy**: apply only the selected service. Do not restart unrelated stacks.
8. **Verify**: check container health, logs, network reachability, application behavior, proxy response, authentication, and persistence.
9. **Record**: refresh inventory and invoke `wrap-session`; a normal rollout should produce both a code-session log and a maintenance log.

## Guardrails

- Real credentials remain in the approved secret store or host-local env file.
- Do not commit appdata, databases, certificates, backups, logs, or runtime state.
- Do not expose a service publicly by default.
- Do not treat a running container as sufficient verification.
- Stop and report when upstream requirements conflict with host standards or available resources.