How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

deploy - Prompt - OpenSmartRoute

Name: deploy
Author: achimdehnert

Prompt file imported from achimdehnert/platform (.windsurf/workflows/deploy.md). Fill in {{GITHUB_DIR}}, {{end}} before use. Copyright stays with the author.

Deploy Workflow

⛔ DEPRECATED — Prod-Deploy-Kanon ist /ship (Standard-Pfad). Nutze /ship für den regulären App-Deploy (verify → push → CI → migrate → health-check) und /run-prod nur als manuellen Notfall-Handpfad (direktes docker compose mit sauberem Ja/Nein-Gate). Dieser Workflow (infra-deploy-Actions) wird nicht mehr als Einstieg gepflegt und bleibt nur als Referenz für die infra-deploy-Mechanik stehen. Rollback: /rollback.

Architektur (ADR-075 + ADR-100): Deployments sind Aufgabe des Deployment Agent. Cascade (Tech Lead) genehmigt nur bei Gate-2-Situationen (neue Migrations, Breaking Changes). Write-Ops laufen über GitHub Actions — NICHT via direktem SSH (hängt). Read-Ops (Logs, Status) via deployment-mcp Tools.

Rollen-Trennung (ADR-100)

Wer	Was
Deployment Agent	Deploy-Ausführung nach CI grün — Freigabe-Pflicht siehe `~/.claude/policies/autonomy-gates.md` Gate 2 (Prod-Deploy braucht IMMER Freigabe, keine Routine-Ausnahme)
Cascade (Tech Lead)	Gate-2-Approval bei neuen Migrations / Breaking Changes
Mensch	Gate-3/4 bei kritischen Prod-Änderungen

Workflow-Übersicht

Operation	Methode	Link
Deploy	`infra-deploy` → `deploy-service.yml`	https://github.com/achimdehnert/infra-deploy/actions
Rollback	`infra-deploy` → `rollback.yml`	https://github.com/achimdehnert/infra-deploy/actions
Migrations	`infra-deploy` → `migrate.yml`	https://github.com/achimdehnert/infra-deploy/actions
DB-Backup	`infra-deploy` → `db-backup.yml`	https://github.com/achimdehnert/infra-deploy/actions
Health-Check	`infra-deploy` → `health-check.yml`	https://github.com/achimdehnert/infra-deploy/actions

Pre-Deploy: ADR Freshness Gate (iil-adrfw v0.4.0)

ℹ️ CC-Fallback: Die mcp2_adr_*-Aufrufe unten sind Windsurf-Ära-Namen; in Claude-Code-Sessions heißen dieselben Tools mcp__<orchestrator-prefix>__adr_* (Prefix aus project-facts.md). Bindet die Session keinen ADR-MCP-Server, ist der Fallback der iil-adrfw-CLI-Weg bzw. direkte Reads in docs/adr/ — der Deploy bricht nicht ab, nur die MCP-Automatik entfällt. (Muster: session-start.md.)

Vor jedem Deploy prüfen ob die ADRs noch zum aktuellen Repo-Stand passen:

MCP: mcp2_adr_freshness(repo_path="{{GITHUB_DIR}}/<SERVICE>")
→ Prüft Version/Port/Image Claims in ADRs gegen compose + requirements
→ severity=warning: Version-Drift (z.B. ADR sagt PostgreSQL 15, Repo hat 16)
→ severity=info: Port-Abweichung (oft irrelevant, nur bei eigenem Repo-Port warnen)

Ergebnis	Aktion
0 stale_claims	✅ Deploy fortsetzen
Nur `info` Findings	✅ Deploy fortsetzen, optional ADR updaten
`warning` Findings	⚠️ User informieren — Deploy möglich, aber ADR-Update empfohlen
Version-Mismatch bei Kern-Infra (DB, Python)	❌ Erst ADR aktualisieren, dann deployen

→ Verhindert Drift zwischen ADR-Dokumentation und tatsächlichem System-Stand.

Deploy via GitHub Actions (Standard)

1. Service deployen (GitHub UI)

→ https://github.com/achimdehnert/infra-deploy/actions/workflows/deploy-service.yml
Run workflow → Inputs:
- service: bfagent | travel-beat | weltenhub | risk-hub | dev-hub | wedding-hub
- image_tag: latest oder SHA
- has_migrations: true oder false

2. Service deployen (Agent)

Verwende <deployment-mcp>_cicd_manage (Prefix aus mcp-tools.md) mit action: dispatch:

owner: achimdehnert
repo: infra-deploy
workflow_id: deploy-service.yml
ref: main
inputs: {service: "travel-beat", image_tag: "latest", has_migrations: "false"}

Dann Status pollen mit <deployment-mcp>_cicd_manage (Prefix aus mcp-tools.md) → action: run_status.

Rollback

→ https://github.com/achimdehnert/infra-deploy/actions/workflows/rollback.yml
Run workflow → service + optional target_tag (leer = vorheriger Tag)

Migrations (ohne Deploy)

→ https://github.com/achimdehnert/infra-deploy/actions/workflows/migrate.yml
Run workflow → service + backup_first: true (empfohlen)

DB-Backup (manuell)

→ https://github.com/achimdehnert/infra-deploy/actions/workflows/db-backup.yml
Run workflow → service

Automatisch: täglich 02:00 UTC für alle Services.

Deploy-Status prüfen (Read-Only via deployment-mcp)

Container-Logs

Verwende deployment-mcp → container_logs Tool.

Compose-Status

Verwende deployment-mcp → compose_ps Tool.

Deploy-History

→ https://github.com/achimdehnert/infra-deploy/actions

Troubleshooting

Workflow hängt: Runner-Status → https://github.com/achimdehnert/infra-deploy/settings/actions/runners
Deploy fehlgeschlagen: Auto-Rollback greift — Deploy-Log via deployment-mcp → ssh_manage file_read /opt/deploy/production/.deployed/deploy.log
Health-Check manuell: infra-deploy → health-check.yml → Run workflow
NIEMALS: deployment-mcp Write-Tools (compose_up, compose_restart) für Deploys verwenden → hängt (ADR-075)

Lessons Learned (Feb 2026)

Private Repo Dependencies im Docker-Build

git+https:// in requirements.txt schlägt im Docker-Build fehl (keine GitHub-Auth). Lösung: Vendor-Pattern — Package unter vendor/ im Repo, requirements.txt referenziert lokalen Pfad. Siehe: wedding-hub/.windsurf/workflows/platform-package-integration.md

SSH-Timeouts bei Build-Operationen

Operation	Min. Timeout
Docker Build	300-600s
Docker Push	300s
Compose Pull	120s
Git Pull	30s

Bei deployment-mcp → ssh_manage exec immer timeout: 600 für Build-Operationen!

DB-Credentials nie raten

Immer zuerst Container-Environment inspizieren:

docker inspect <container> --format '{{range .Config.Env}}{{println .}}{{end}}' | grep POSTGRES

Server-Pfade nachschlagen

Nicht raten — in project-facts.md des jeweiligen Repos nachschauen oder:

find /opt -maxdepth 2 -name "docker-compose.prod.yml" 2>/dev/null

Install deploy and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Deploy Workflow > ⛔ **DEPRECATED — Prod-Deploy-Kanon ist `/ship` (Standard-Pfad).** > Nutze `/ship` für den regulären App-Deploy (verify → push → CI → migrate → health-check) > und `/run-prod` nur als manuellen Notfall-Handpfad (direktes `docker compose` mit > sauberem Ja/Nein-Gate). Dieser Workflow (infra-deploy-Actions) wird nicht mehr als > Einstieg gepflegt und bleibt nur als Referenz für die infra-deploy-Mechanik stehen. > Rollback: `/rollback`. > **Architektur (ADR-075 + ADR-100)**: Deployments sind Aufgabe des **Deployment Agent**. > Cascade (Tech Lead) genehmigt nur bei Gate-2-Situationen (neue Migrations, Breaking Changes). > Write-Ops laufen über GitHub Actions — NICHT via direktem SSH (hängt). > Read-Ops (Logs, Status) via `deployment-mcp` Tools. ## Rollen-Trennung (ADR-100) | Wer | Was | |-----|-----| | **Deployment Agent** | Deploy-Ausführung nach CI grün — Freigabe-Pflicht siehe `~/.claude/policies/autonomy-gates.md` Gate 2 (Prod-Deploy braucht IMMER Freigabe, keine Routine-Ausnahme) | | **Cascade (Tech Lead)** | Gate-2-Approval bei neuen Migrations / Breaking Changes | | **Mensch** | Gate-3/4 bei kritischen Prod-Änderungen | ## Workflow-Übersicht | Operation | Methode | Link | |-----------|---------|------| | Deploy | `infra-deploy` → `deploy-service.yml` | https://github.com/achimdehnert/infra-deploy/actions | | Rollback | `infra-deploy` → `rollback.yml` | https://github.com/achimdehnert/infra-deploy/actions | | Migrations | `infra-deploy` → `migrate.yml` | https://github.com/achimdehnert/infra-deploy/actions | | DB-Backup | `infra-deploy` → `db-backup.yml` | https://github.com/achimdehnert/infra-deploy/actions | | Health-Check | `infra-deploy` → `health-check.yml` | https://github.com/achimdehnert/infra-deploy/actions | --- ## Pre-Deploy: ADR Freshness Gate (iil-adrfw v0.4.0) > ℹ️ **CC-Fallback:** Die `mcp2_adr_*`-Aufrufe unten sind Windsurf-Ära-Namen; in > Claude-Code-Sessions heißen dieselben Tools `mcp__<orchestrator-prefix>__adr_*` > (Prefix aus `project-facts.md`). Bindet die Session keinen ADR-MCP-Server, ist der > Fallback der `iil-adrfw`-CLI-Weg bzw. direkte Reads in `docs/adr/` — der Deploy bricht > nicht ab, nur die MCP-Automatik entfällt. (Muster: `session-start.md`.) Vor jedem Deploy prüfen ob die ADRs noch zum aktuellen Repo-Stand passen: ``` MCP: mcp2_adr_freshness(repo_path="{{GITHUB_DIR}}/<SERVICE>") → Prüft Version/Port/Image Claims in ADRs gegen compose + requirements → severity=warning: Version-Drift (z.B. ADR sagt PostgreSQL 15, Repo hat 16) → severity=info: Port-Abweichung (oft irrelevant, nur bei eigenem Repo-Port warnen) ``` | Ergebnis | Aktion | |----------|--------| | 0 stale_claims | ✅ Deploy fortsetzen | | Nur `info` Findings | ✅ Deploy fortsetzen, optional ADR updaten | | `warning` Findings | ⚠️ User informieren — Deploy möglich, aber ADR-Update empfohlen | | Version-Mismatch bei Kern-Infra (DB, Python) | ❌ Erst ADR aktualisieren, dann deployen | → Verhindert Drift zwischen ADR-Dokumentation und tatsächlichem System-Stand. --- ## Deploy via GitHub Actions (Standard) ### 1. Service deployen (GitHub UI) 1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/deploy-service.yml 2. **Run workflow** → Inputs: - `service`: `bfagent` | `travel-beat` | `weltenhub` | `risk-hub` | `dev-hub` | `wedding-hub` - `image_tag`: `latest` oder SHA - `has_migrations`: `true` oder `false` ### 2. Service deployen (Agent) Verwende `<deployment-mcp>_cicd_manage` *(Prefix aus mcp-tools.md)* mit `action: dispatch`: ``` owner: achimdehnert repo: infra-deploy workflow_id: deploy-service.yml ref: main inputs: {service: "travel-beat", image_tag: "latest", has_migrations: "false"} ``` Dann Status pollen mit `<deployment-mcp>_cicd_manage` *(Prefix aus mcp-tools.md)* → `action: run_status`. --- ## Rollback 1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/rollback.yml 2. **Run workflow** → `service` + optional `target_tag` (leer = vorheriger Tag) --- ## Migrations (ohne Deploy) 1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/migrate.yml 2. **Run workflow** → `service` + `backup_first: true` (empfohlen) --- ## DB-Backup (manuell) 1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/db-backup.yml 2. **Run workflow** → `service` Automatisch: täglich 02:00 UTC für alle Services. --- ## Deploy-Status prüfen (Read-Only via deployment-mcp) ### Container-Logs Verwende `deployment-mcp` → `container_logs` Tool. ### Compose-Status Verwende `deployment-mcp` → `compose_ps` Tool. ### Deploy-History → https://github.com/achimdehnert/infra-deploy/actions --- ## Troubleshooting - **Workflow hängt**: Runner-Status → https://github.com/achimdehnert/infra-deploy/settings/actions/runners - **Deploy fehlgeschlagen**: Auto-Rollback greift — Deploy-Log via `deployment-mcp` → `ssh_manage file_read /opt/deploy/production/.deployed/deploy.log` - **Health-Check manuell**: `infra-deploy` → `health-check.yml` → Run workflow - **NIEMALS**: `deployment-mcp` Write-Tools (compose_up, compose_restart) für Deploys verwenden → hängt (ADR-075) --- ## Lessons Learned (Feb 2026) ### Private Repo Dependencies im Docker-Build `git+https://` in `requirements.txt` schlägt im Docker-Build fehl (keine GitHub-Auth). **Lösung**: Vendor-Pattern — Package unter `vendor/` im Repo, `requirements.txt` referenziert lokalen Pfad. Siehe: `wedding-hub/.windsurf/workflows/platform-package-integration.md` ### SSH-Timeouts bei Build-Operationen | Operation | Min. Timeout | | --- | --- | | Docker Build | 300-600s | | Docker Push | 300s | | Compose Pull | 120s | | Git Pull | 30s | Bei `deployment-mcp` → `ssh_manage exec` immer `timeout: 600` für Build-Operationen! ### DB-Credentials nie raten Immer zuerst Container-Environment inspizieren: ```bash docker inspect <container> --format '{{range .Config.Env}}{{println .}}{{end}}' | grep POSTGRES ``` ### Server-Pfade nachschlagen Nicht raten — in `project-facts.md` des jeweiligen Repos nachschauen oder: ```bash find /opt -maxdepth 2 -name "docker-compose.prod.yml" 2>/dev/null ```

{ "prompt": "# Deploy Workflow\n\n> ⛔ **DEPRECATED — Prod-Deploy-Kanon ist `/ship` (Standard-Pfad).**\n> Nutze `/ship` für den regulären App-Deploy (verify → push → CI → migrate → health-check)\n> und `/run-prod` nur als manuellen Notfall-Handpfad (direktes `docker compose` mit\n> sauberem Ja/Nein-Gate). Dieser Workflow (infra-deploy-Actions) wird nicht mehr als\n> Einstieg gepflegt und bleibt nur als Referenz für die infra-deploy-Mechanik stehen.\n> Rollback: `/rollback`.\n\n> **Architektur (ADR-075 + ADR-100)**: Deployments sind Aufgabe des **Deployment Agent**.\n> Cascade (Tech Lead) genehmigt nur bei Gate-2-Situationen (neue Migrations, Breaking Changes).\n> Write-Ops laufen über GitHub Actions — NICHT via direktem SSH (hängt).\n> Read-Ops (Logs, Status) via `deployment-mcp` Tools.\n\n## Rollen-Trennung (ADR-100)\n\n| Wer | Was |\n|-----|-----|\n| **Deployment Agent** | Deploy-Ausführung nach CI grün — Freigabe-Pflicht siehe `~/.claude/policies/autonomy-gates.md` Gate 2 (Prod-Deploy braucht IMMER Freigabe, keine Routine-Ausnahme) |\n| **Cascade (Tech Lead)** | Gate-2-Approval bei neuen Migrations / Breaking Changes |\n| **Mensch** | Gate-3/4 bei kritischen Prod-Änderungen |\n\n## Workflow-Übersicht\n\n| Operation | Methode | Link |\n|-----------|---------|------|\n| Deploy | `infra-deploy` → `deploy-service.yml` | https://github.com/achimdehnert/infra-deploy/actions |\n| Rollback | `infra-deploy` → `rollback.yml` | https://github.com/achimdehnert/infra-deploy/actions |\n| Migrations | `infra-deploy` → `migrate.yml` | https://github.com/achimdehnert/infra-deploy/actions |\n| DB-Backup | `infra-deploy` → `db-backup.yml` | https://github.com/achimdehnert/infra-deploy/actions |\n| Health-Check | `infra-deploy` → `health-check.yml` | https://github.com/achimdehnert/infra-deploy/actions |\n\n---\n\n## Pre-Deploy: ADR Freshness Gate (iil-adrfw v0.4.0)\n\n> ℹ️ **CC-Fallback:** Die `mcp2_adr_*`-Aufrufe unten sind Windsurf-Ära-Namen; in\n> Claude-Code-Sessions heißen dieselben Tools `mcp__<orchestrator-prefix>__adr_*`\n> (Prefix aus `project-facts.md`). Bindet die Session keinen ADR-MCP-Server, ist der\n> Fallback der `iil-adrfw`-CLI-Weg bzw. direkte Reads in `docs/adr/` — der Deploy bricht\n> nicht ab, nur die MCP-Automatik entfällt. (Muster: `session-start.md`.)\n\nVor jedem Deploy prüfen ob die ADRs noch zum aktuellen Repo-Stand passen:\n\n```\nMCP: mcp2_adr_freshness(repo_path=\"{{GITHUB_DIR}}/<SERVICE>\")\n→ Prüft Version/Port/Image Claims in ADRs gegen compose + requirements\n→ severity=warning: Version-Drift (z.B. ADR sagt PostgreSQL 15, Repo hat 16)\n→ severity=info: Port-Abweichung (oft irrelevant, nur bei eigenem Repo-Port warnen)\n```\n\n| Ergebnis | Aktion |\n|----------|--------|\n| 0 stale_claims | ✅ Deploy fortsetzen |\n| Nur `info` Findings | ✅ Deploy fortsetzen, optional ADR updaten |\n| `warning` Findings | ⚠️ User informieren — Deploy möglich, aber ADR-Update empfohlen |\n| Version-Mismatch bei Kern-Infra (DB, Python) | ❌ Erst ADR aktualisieren, dann deployen |\n\n→ Verhindert Drift zwischen ADR-Dokumentation und tatsächlichem System-Stand.\n\n---\n\n## Deploy via GitHub Actions (Standard)\n\n### 1. Service deployen (GitHub UI)\n1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/deploy-service.yml\n2. **Run workflow** → Inputs:\n - `service`: `bfagent` | `travel-beat` | `weltenhub` | `risk-hub` | `dev-hub` | `wedding-hub`\n - `image_tag`: `latest` oder SHA\n - `has_migrations`: `true` oder `false`\n\n### 2. Service deployen (Agent)\nVerwende `<deployment-mcp>_cicd_manage` *(Prefix aus mcp-tools.md)* mit `action: dispatch`:\n```\nowner: achimdehnert\nrepo: infra-deploy\nworkflow_id: deploy-service.yml\nref: main\ninputs: {service: \"travel-beat\", image_tag: \"latest\", has_migrations: \"false\"}\n```\nDann Status pollen mit `<deployment-mcp>_cicd_manage` *(Prefix aus mcp-tools.md)* → `action: run_status`.\n\n---\n\n## Rollback\n\n1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/rollback.yml\n2. **Run workflow** → `service` + optional `target_tag` (leer = vorheriger Tag)\n\n---\n\n## Migrations (ohne Deploy)\n\n1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/migrate.yml\n2. **Run workflow** → `service` + `backup_first: true` (empfohlen)\n\n---\n\n## DB-Backup (manuell)\n\n1. → https://github.com/achimdehnert/infra-deploy/actions/workflows/db-backup.yml\n2. **Run workflow** → `service`\n\nAutomatisch: täglich 02:00 UTC für alle Services.\n\n---\n\n## Deploy-Status prüfen (Read-Only via deployment-mcp)\n\n### Container-Logs\nVerwende `deployment-mcp` → `container_logs` Tool.\n\n### Compose-Status\nVerwende `deployment-mcp` → `compose_ps` Tool.\n\n### Deploy-History\n→ https://github.com/achimdehnert/infra-deploy/actions\n\n---\n\n## Troubleshooting\n\n- **Workflow hängt**: Runner-Status → https://github.com/achimdehnert/infra-deploy/settings/actions/runners\n- **Deploy fehlgeschlagen**: Auto-Rollback greift — Deploy-Log via `deployment-mcp` → `ssh_manage file_read /opt/deploy/production/.deployed/deploy.log`\n- **Health-Check manuell**: `infra-deploy` → `health-check.yml` → Run workflow\n- **NIEMALS**: `deployment-mcp` Write-Tools (compose_up, compose_restart) für Deploys verwenden → hängt (ADR-075)\n\n---\n\n## Lessons Learned (Feb 2026)\n\n### Private Repo Dependencies im Docker-Build\n\n`git+https://` in `requirements.txt` schlägt im Docker-Build fehl (keine GitHub-Auth).\n**Lösung**: Vendor-Pattern — Package unter `vendor/` im Repo, `requirements.txt` referenziert lokalen Pfad.\nSiehe: `wedding-hub/.windsurf/workflows/platform-package-integration.md`\n\n### SSH-Timeouts bei Build-Operationen\n\n| Operation | Min. Timeout |\n| --- | --- |\n| Docker Build | 300-600s |\n| Docker Push | 300s |\n| Compose Pull | 120s |\n| Git Pull | 30s |\n\nBei `deployment-mcp` → `ssh_manage exec` immer `timeout: 600` für Build-Operationen!\n\n### DB-Credentials nie raten\n\nImmer zuerst Container-Environment inspizieren:\n```bash\ndocker inspect <container> --format '{{range .Config.Env}}{{println .}}{{end}}' | grep POSTGRES\n```\n\n### Server-Pfade nachschlagen\n\nNicht raten — in `project-facts.md` des jeweiligen Repos nachschauen oder:\n```bash\nfind /opt -maxdepth 2 -name \"docker-compose.prod.yml\" 2>/dev/null\n```", "variables": [ "GITHUB_DIR", "end" ], "notes": "Deploy any app to production (bfagent, cad-hub, travel-beat, etc.) Mode: write.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/achimdehnert/platform", "path": ".windsurf/workflows/deploy.md", "ref": "26ff2649c7a82cb7138376c80dd081b45f760921", "url": "https://github.com/achimdehnert/platform/blob/26ff2649c7a82cb7138376c80dd081b45f760921/.windsurf/workflows/deploy.md", "key": "achimdehnert/platform/.windsurf/workflows/deploy.md" } } }

deploy

About