Ports & Services

Inventory of every service in the trial bundle / self-hosted stack (brutor-trial-service/trial_bundle/docker-compose.yml). Brutor images are tagged with BRUTOR_VERSION (e.g. 0.9.67). Install walkthrough: Docker Compose; architecture overview: Architecture.

Two planes

Plane	Service	Port	Role
Core Proxy (:8100)	core (Rust/Axum)	8100	ALL runtime traffic — LLM/MCP/A2A/OAuth/Skills proxying and the end-user Portal API (/v1/portal/*). Reads config from the shared DB (read-only).
Control Plane (:5050)	control-plane (Python/FastAPI)	5050	ALL config writes — admin API, DB schema ownership (Alembic migrations on startup), seeding. Backs the Admin UI only.

Both planes share PostgreSQL and must share JWT_SECRET and ENCRYPTION_KEY — see Environment Variables.

Service inventory

Service	Image	Port(s)	Plane	Purpose	Depends on
core	Brutor core (:BRUTOR_VERSION)	8100	Runtime	LLM/MCP/A2A/OAuth/Skills proxy + Portal API	postgres, redis, qdrant, minio
control-plane	Brutor control plane	5050	Admin	Admin API, migrations, seeding	postgres, redis
admin-console	Brutor admin UI	3002	Admin	React management console → Control Plane	control-plane
portal	Brutor portal	3001	Runtime	React end-user chat UI → Core Proxy	core
kb-uploader	Brutor KB uploader	8200	Runtime	Document extraction, chunking, embedding into Qdrant	postgres, qdrant
kb-connector-sync	Brutor KB connector	8201	Runtime	Confluence/Notion/GDrive/Slack/GitHub/Jira/SharePoint sync	postgres, kb-uploader
skill-runner	Brutor skill runner	8210 (internal only)	Runtime	Sandboxed skill execution — JWT-authed, read-only rootfs, cap_drop: ALL; never exposed publicly	core
mcp-app-map	Demo MCP server	3010	Demo	Leaflet map demo (MCP-Apps UI)	—
postgres	postgres:16	5432	Shared	Single shared database for both planes	—
redis	redis:7.4	6379	Shared	Cache, rate-limit counters, pub/sub	—
qdrant	qdrant:1.18	6333 (REST) / 6334 (gRPC)	Shared	Vectors — semantic cache + knowledgebases	—
minio	MinIO	9000 (API) / 9001 (console)	Shared	S3-compatible media storage (images/audio/video)	—
ollama	Ollama	11434	Optional	Local embeddings (nomic-embed-text)	profile local-embedding
localstack	LocalStack	4566	Optional	AWS KMS emulation	profile kms
vault	Vault	8200	Optional	Vault Transit key management	profile kms
presidio-analyzer	Presidio	3030	Optional	PII NER engine for guardrails	profile presidio
anthropic-mock	Anthropic Enterprise mock	8085	Optional	Mock Anthropic Enterprise Analytics API for Traffic Data Import demos	profile anthropic-mock

Note

Host-side ports are remappable via env (PROXY_PORT, GATEWAY_PORT, ADMIN_UI_PORT, PORTAL_PORT, DB_PORT, REDIS_PORT, QDRANT_REST_PORT/QDRANT_GRPC_PORT, MINIO_API_PORT/MINIO_CONSOLE_PORT). Vault (profile kms) and kb-uploader both use 8200 — Vault is only relevant in the kms profile.

Compose profiles

Profile	Adds	When to use
(default)	Core stack: core, control-plane, admin-console, portal, kb-uploader, kb-connector-sync, skill-runner, mcp-app-map, postgres, redis, qdrant, minio	Always
local-embedding	ollama (:11434)	Embeddings without an external API key
kms	localstack (:4566) + vault (:8200)	Testing KEY_PROVIDER=aws_kms / vault
presidio	presidio-analyzer (:3030)	Presidio-backed PII guardrails
anthropic-mock	anthropic-mock (:8085)	Demo Traffic Data Import without an Anthropic Enterprise plan

cd trial_bundle
./docker-start.sh                              # interactive (asks about local embeddings)
docker compose up -d                           # non-interactive, remote embeddings
docker compose --profile local-embedding up -d # with Ollama
./docker-cleanup.sh                            # teardown

Windows: .\docker-start.ps1.

URL quick reference

Which base URL for which task:

Task	URL	Notes
Admin UI (configure everything)	http://localhost:3002	Login admin / Admin123! (tenant default) — change in production
User Portal (end-user chat)	http://localhost:3001	Seeded user trial / Trial123!
Admin API (config writes, scripts)	http://localhost:5050/v1/admin/...	Admin API reference
Admin API interactive OpenAPI	http://localhost:5050/docs	Full schema on a running Control Plane
LLM calls (OpenAI-compatible)	http://localhost:8100/v1/proxy/llm/...	LLM Proxy API
Anthropic SDK / Claude Code	http://localhost:8100/v1/messages	Native Messages API
MCP / VMCP / OAuth / Skills	http://localhost:8100/v1/proxy/...	MCP & A2A reference
A2A v1.0 agents	http://localhost:8100/a2a/{tenant}/{card}	Discovery at /.well-known/agent-card/...
Portal API (custom portals)	http://localhost:8100/v1/portal/...	Portal API reference
Runtime Swagger UI	http://localhost:8100/docs	Core Proxy OpenAPI at /api-docs/openapi.json
Prometheus metrics	http://localhost:8100/metrics	Core Proxy
Health checks	http://localhost:8100/health, http://localhost:5050/health	Public by design (Docker health checks)
MinIO console	http://localhost:9001	minioadmin / minioadmin by default

Which plane am I talking to?

Rule of thumb: writes configuration → Control Plane (:5050); moves AI traffic or serves end users → Core Proxy (:8100). The User Portal never talks to the Control Plane.

Local development (infra-only compose)

brutor-gateway-control/docker-compose.yml runs only the infrastructure in Docker (postgres, redis, qdrant, mcp-app-map, skill-runner; kms profile adds localstack + vault) while both planes run natively:

cd brutor-gateway-control && docker compose up -d && python main.py   # Control Plane :5050
cd brutor-gateway-core && cargo run                                    # Core Proxy :8100
cd brutor-gateway-admin && npm run dev                                 # Admin UI :3002 (VITE_GATEWAY_URL=http://localhost:5050)
cd brutor-gateway-portal && npm run dev                                # Portal :3001 (VITE_GATEWAY_URL=http://localhost:8100)

See Local Development.

Production reference (AWS)

The reference production architecture (Terraform, brutor-saas-infra) runs the same services on ECS Fargate: ALB host-routing app.brutor.ai → admin UI and portal.brutor.ai → portal, path-routing api.brutor.ai/v1/admin/* → control-plane:5050 and /v1/proxy/* → core:8100, with Aurora PostgreSQL Serverless v2 and ElastiCache Redis in private subnets. Sizing and details: Production on AWS.