CompTech AIOps - ze-tower deployment

Public-safe summary of the Phase 1 ze-tower control-plane deployment model.

ze-tower is the Phase 1 AIOps control-plane host. It is not the location for managed OpenShift clusters, hypervisors, bare-metal estates, network devices, or facilities systems.

Deployment Model

Deployment is defined in the canonical comptech-aiops repository and executed through a manual GitHub Actions workflow.

The workflow:

runs from main;
uses the ze-tower GitHub environment;
runs on a repository-scoped self-hosted runner on ze-tower;
syncs the repository to the host;
renders runtime configuration from GitHub Secrets;
runs preflight checks;
starts the Docker Compose stack;
runs a portal and Compose stability health check.

Secret values are not stored in the repository or in this blog.

Deployed Baseline

The first non-dry-run deployment completed on 2026-05-22.

The deployed Phase 1 baseline includes:

ingress gateway;
portal API;
operator portal frontend MVP;
agent orchestrator placeholder;
MCP gateway placeholder;
RAG ingestion service with durable metadata and Qdrant indexing;
Postgres;
Qdrant;
Temporal;
OPA;
LiteLLM;
Keycloak;
NetBox;
n8n;
Prometheus, Alertmanager, Grafana, Loki, Tempo, and OpenTelemetry Collector.

GPU model-serving profiles exist for vLLM and TGI-class runtimes but are optional profile services.

Network Boundary

Docker networks are segmented by role:

Network	Purpose
`ingress`	Host-facing ingress boundary
`app_internal`	Portal, API, stateful services, identity, agent runtime
`model_internal`	Model gateway and model-serving services
`observability_internal`	Metrics, logs, traces, dashboards
`target_access`	Controlled path for future target integrations

Services are internal by default. Host-facing exposure is by explicit exception.

The operator portal is exposed through one trusted-LAN ingress path on ze-tower. Internal service endpoints, databases, model-serving APIs, and tool gateways remain Docker-internal unless a later ADR approves exposure.

Superseded OpenWebUI Cleanup

The historical rag-open-webui container from the earlier /srv/rag experiment was removed after the current AIOps control plane was verified. Its old data paths were preserved for recoverability pending a separate archive or deletion decision.

Portal MVP Smoke Direction

The portal MVP was verified through the deployed ingress after GitHub Actions deployment. Public-safe smoke scope included portal readiness, a non-secret execution task, approval queue behavior, task event history, knowledge query citations, inventory target rendering, evidence lookup behavior, and the standard health check.

The LAN portal exposure uses the same portal API boundary. Public-safe verification confirmed direct portal health, readiness, placeholder operator profile, browser-render checks, and the standard remote health script without publishing credentials or private raw evidence.

RAG semantic indexing verification uses public-safe reviewed source fixtures only. The latest smoke scope confirmed ingestion, indexed chunk state, Qdrant point metadata, direct and portal-mediated citation queries, the internal index rebuild endpoint, and the standard remote health script. Secret values and raw private evidence are not published here.

Retrieval evaluation now also runs before deployment in canonical validation. The current fixture checks public-safe control-plane questions against the reviewed knowledge pack using the in-memory RAG store; deployed Qdrant behavior is still checked separately by smoke tests.

Remaining Guardrails

Before production-changing tools are enabled, the platform still needs:

identity and role model;
target-specific backup readiness for any future production-changing scope;
first read-only agent workflows;
explicit MCP tool contracts;
real orchestrator and MCP gateway behavior behind the existing contracts.