Saltar a contenido

Runbook: Alembic — operations

Field Value
Service Alembic
Owner Olger Avila (IT)
Last verified 2026-07-14 — reflects Alembic changes through 2026-07-14 (tool additions, automated deploy, get_config denylist). Deploy/security details transcribed from the repo, not independently re-run by Athanor/Eduardo.

Purpose

Day-to-day operation of the SAP B1/Oracle MCP server: checking it's up, deploying code changes, restarting after changes, and reloading the reverse proxy without downtime.

Prerequisites

  • RDP/remote access to the Windows server ("Jetty box", 192.168.1.6) — office LAN or VPN. Credentials are IT-managed; not documented here.
  • PowerShell access on that server.
  • For deploys: push access to Alquemis-Automation/Alembic (private repo). Deploys run on a self-hosted GitHub Actions runner installed on the Jetty box — that runner service must be running (see .github/RUNNER_SETUP.md in the repo).

Steps

Check service status

Get-Service caddy, mcp-sapb1

Both should show Running. They're managed as Windows services via NSSM (auto-start, restart on crash).

Deploy a code change

Deploys are automated via a self-hosted GitHub Actions runner on the Jetty box (the MCP host is on a private LAN behind NAT, so GitHub's cloud runners can't reach it — hence a self-hosted runner; see .github/RUNNER_SETUP.md in the repo).

  1. Push or merge to main on Alquemis-Automation/Alembic. The Deploy MCP (Alembic) workflow (.github/workflows/deploy.yml) fires automatically and, on the runner: copies tracked *.py + requirements.txt into C:\Trabajo\MCP\ (never touching .env, the venv, or certs), pip installs requirements, runs Restart-Service mcp-sapb1, then health-checks that the service is Running and listening on 127.0.0.1:8000.
  2. Docs-only changes (**/*.md, .gitignore, .env.example) are ignored — no restart.
  3. Timing caveat: a merge to main restarts the live service immediately. Prefer 8–10 AM; avoid 6–8 AM (dispatches / production orders) and midday; do risky or large changes at night or on weekends. To deploy off-cycle, trigger the workflow's manual Run workflow (workflow_dispatch) button at a safe time rather than merging at a bad one.

Only one deploy runs at a time (concurrency guard); an in-flight deploy finishes before the next.

Change only Caddy config

The Caddyfile is versioned in the repo, but Caddy config is not covered by the deploy workflow — apply it on the server. No restart needed; reload applies the new config without dropping TLS:

.\caddy.exe reload --config Caddyfile

Verification

  • Get-Service caddy, mcp-sapb1 shows both Running.
  • Logs: Caddy at C:\Caddy\logs\, MCP at C:\Trabajo\MCP\logs\.
  • Functional check: connect an MCP client to https://mcp.alquemis.com/<TOKEN>/ and confirm the tool list comes back (thirteen tools — see the catalog entry).
  • After an automated deploy, the workflow's own health-check step (service Running + port 8000 open) is the first signal; a red run in the repo's Actions tab means the deploy failed.

Rollback

  • Code: git revert the change on main and push — the deploy workflow redeploys the previous code automatically. (Manual fallback if the runner is down: copy the previous file(s) to C:\Trabajo\MCP\ and Restart-Service mcp-sapb1.)
  • Caddy config: restore the previous Caddyfile, caddy.exe reload --config Caddyfile.

Contacts

Olger Avila (owner). Escalate to him for anything beyond a simple restart/reload — server access, the .env file, and the shared URL token are all his to manage.