Deployment¶

G6 supports multiple deployment models through its fourteen delivery bases, Docker containers, and CI/CD pipeline.

Delivery bases¶

Each base is a thin protocol adapter that exposes G6's 270 registry components via a different protocol:

Base	Protocol	Framework	Entry Point	Primary Use
CLI	Terminal UI	Textual + Click	`python -m mvp.cli`	Interactive development
REST	HTTP/REST	FastAPI + Uvicorn	`python -m mvp.rest`	API integrations
MCP	MCP (SSE/stdio)	FastMCP	`python -m mvp.mcp`	Claude Code integration
gRPC	gRPC	betterproto	`python -m mvp.grpc`	High-performance RPC
SOAP	SOAP/XML	spyne	`python -m mvp.soap`	Enterprise/legacy systems
Erlang	Custom	Custom protocol	`python -m mvp.erlang`	Distributed systems
CI/CD	Pipeline stages	GitHub Actions / GitLab CI	`python -m mvp.cicd`	Continuous integration
Computer Use	Screen control	Automation API	`python -m mvp.computer_use`	Desktop automation
VirtualBox	VM management	VBoxManage API	`python -m mvp.virtualbox`	Sandboxed execution
Skill	Skill protocol	Skill runtime	`python -m mvp.skill`	Agent skill delivery
Desktop	Native binary	Textual + MCP	Desktop app bundle	End-user distribution
Web	HTTP/HTML	Django	`python -m mvp.web`	Web application
GUI API	GUI control	Native GUI bridge	`python -m mvp.gui_api`	GUI automation
Patch	Diff/patch	Unified diff	`python -m mvp.patch`	Code patching

Entry points: desktop app vs. self-hosted server

The Entry Point column shows each base's module entry point in the self-hosted server / development distribution. End users of the downloaded desktop app drive the local surfaces through the g6 binary instead — g6 --gui, g6 --tui, g6 --mcp, g6 --gui-api, and g6 --rest (a local REST server bound to loopback). The gRPC, SOAP, Erlang, and Web bases are self-hosted only (run via python -m mvp.<base> / Docker), not part of the desktop app.

Base architecture¶

Every base implements three shared helper functions:

def _list_components() -> list[ComponentMeta]:
    """Enumerate all registered components."""

def _invoke_component(name: str, op: str, params: dict) -> Result:
    """Call a component operation by name."""

def _run_pipeline(steps: list[PipelineStep]) -> Result[list]:
    """Execute a pipeline of component operations."""

This ensures identical behavior regardless of delivery protocol.

Docker deployment¶

Each base has a Dockerfile at bases/mvp/<base>/Dockerfile.

Individual services¶

MCP ServerREST ServerCLI

docker build -f bases/mvp/mcp/Dockerfile -t g6-mcp .
docker run -p 8080:8080 \
  -e OPENROUTER_API_KEY=your_key \
  g6-mcp

docker build -f bases/mvp/rest/Dockerfile -t g6-rest .
docker run -p 8010:8010 \
  -e OPENROUTER_API_KEY=your_key \
  g6-rest

docker build -f bases/mvp/cli/Dockerfile -t g6-cli .
docker run -it g6-cli

Full stack¶

There are two deployment paths, plus a dev mode:

Development (docker-compose.yml):

docker compose up -d

Launches: g6-web, g6-mcp, PostgreSQL, Prometheus, Grafana. No nginx/SSL — access services directly on ports 8000/8080.

Simple production (docker-compose.prod.yml):

docker compose -f docker-compose.prod.yml up -d

Self-contained stack: nginx (SSL/TLS), g6-web, g6-mcp, PostgreSQL, Redis, Certbot.

Blue-green production (docker-compose.base.yml + blue/green overlays):

docker compose -f docker-compose.base.yml -f docker-compose.blue.yml up -d

Shared infrastructure (nginx, postgres, redis, pushgateway, prometheus, grafana) with swappable blue/green application slots. BlueGreenManager auto-generates upstream.conf and reloads nginx for zero-downtime deploys.

All production paths launch:

nginx reverse proxy (TLS 1.2+, HSTS, rate limiting, SSE support for MCP)
G6 web server (Django on port 8000)
G6 MCP server (FastMCP over SSE on port 8080)
PostgreSQL (API key storage, usage tracking)
Redis (rate limiting, caching)
Prometheus + Grafana (observability — metrics, dashboards, alerts)

Kubernetes is advanced infrastructure

The deploy_k8s component can generate and apply Kubernetes manifests, but it is not the recommended first-user or Phase 0 launch path. For early pilots, use the simple VPS/Docker deployment unless you already operate Kubernetes and need cluster-native workflows. Kubernetes adds RBAC, ingress, DNS/TLS, secrets, backup, monitoring, and cluster operations overhead that does not help the 10-minute non-developer onboarding goal.

Core readiness is not full launch readiness

The core component is hardened enough to serve as the launch foundation: its focused suite passes, pipeline failures are explicit, resource bounds are enforced, update downloads fail closed on unsafe manifests, and production metrics are guarded for concurrent use. This should not be read as a production-ready claim for the full product.

Before first-user or paid-user deployment, still complete the launch-plan checks outside core: clean MCP install and workflow execution, Docker image verification, staging deployment, Stripe signup/trial/checkout/subscription E2E, production .env validation, database migrations, email delivery, and the non-developer onboarding path.

Autonomous orchestrator deployment scope

The autonomous_orchestrator component is intended for single-process pilot operation at this stage. Its direct block uses JSON-backed task files and process-local dollar-cost accounting, so do not run multiple autonomous orchestrator workers against the same todo/review files in production.

Before enabling unattended paid-user workflows, verify MCP install/run end to end, configure conservative token limits, configure the kill-switch file, and keep human review in the completion path. Durable shared spend accounting and multi-worker queue semantics are still required before this component should be treated as production-hardened orchestration infrastructure.

Vendored claude-mem is for availability and testing

G6 includes a pinned upstream claude-mem source snapshot at vendor/claude-mem so ctx_claude_mem testing and packaging work can continue if upstream becomes unavailable. This is not the same as a cleared commercial end-user bundle.

The root claude-mem package is AGPL-3.0, and the upstream ragtime/ subtree carries PolyForm Noncommercial 1.0.0. Before distributing a paid desktop, Docker, or MCP package that includes this source, explicitly review the bundle contents, remove or separately clear restricted subtrees, and include the required notices.

Installer flows should not silently run upstream npx claude-mem install, because that command can alter global Claude/Gemini/Codex plugin hooks. Prefer an explicit choice: use an existing worker, or build/start the vendored worker with visible license notices.

Container hardening¶

All Dockerfiles follow security best practices:

Multi-stage builds -- separate build and runtime stages
Non-root user -- containers run as unprivileged user
Selective COPY -- only required files are copied
Health checks -- built-in health check endpoints
Pinned base images -- python:3.12-slim, nginx:1.27-alpine, postgres:16-alpine
Version-pinned dependencies -- requirements files with exact versions

Per-base skills¶

Each base includes a skill/ directory with deployment tooling:

bases/mvp/<base>/skill/
├── plugin.json          # Skill metadata and version
├── SKILL.md             # Documentation
├── commands/
│   ├── deploy.py        # Deployment command
│   ├── pipeline.py      # Pipeline management
│   └── health.py        # Health check command
├── agents/
│   └── deployer.py      # Deployment agent
└── hooks.json           # Lifecycle hooks

Skill commands¶

Command	Purpose
`deploy`	Deploy the base to a target environment
`pipeline`	Manage pipeline configurations
`health`	Run health checks against a running instance

Deployable projects¶

Three pre-configured projects assemble specific bases with their dependencies:

g6_tui¶

CLI application for interactive development.

projects/g6_tui/
└── pyproject.toml    # cli base + components + returns + trio

g6_mcp¶

MCP server for Claude Code integration. This is the primary deployment target.

projects/g6_mcp/
└── pyproject.toml    # mcp base + components + returns + trio

g6_rest¶

REST API for HTTP integrations.

projects/g6_rest/
└── pyproject.toml    # rest base + components + returns + trio

nginx configuration¶

The nginx reverse proxy handles:

Concern	Configuration
TLS termination	TLS 1.2+, HSTS, OCSP stapling, Let's Encrypt
Authentication	Bearer token validation against PostgreSQL
Rate limiting	Per-key sliding window (Redis-backed)
CORS	Restricted origin whitelist
Proxy pass	Routes to upstream G6 MCP/REST servers

Example nginx block¶

location /mcp/ {
    proxy_pass http://g6-mcp:8080/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;

    # SSE support
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 300s;
}

CI/CD pipeline¶

The deployment pipeline follows these stages:

flowchart LR
    A[Lint<br/>ruff + mypy] --> B[Test<br/>pytest]
    B --> C[Build<br/>Docker images]
    C --> D[Push<br/>Container registry]
    D --> E[Deploy<br/>Production]

Pipeline stages¶

Stage	Tools	Purpose
Lint	ruff, mypy	Code quality and type checking
Test	pytest	Unit and integration tests
Build	Docker	Container image creation
Push	Container registry	Image distribution
Deploy	Docker Compose / orchestrator	Production deployment

Environment architecture¶

flowchart TD
    subgraph Production
        NG[nginx] --> MCP[G6 MCP Server]
        NG --> REST[G6 REST Server]
        MCP --> PG[(PostgreSQL)]
        MCP --> RD[(Redis)]
        REST --> PG
        REST --> RD
        MCP --> LLM[LLM Backends]
        REST --> LLM
    end

    subgraph External
        CC[Claude Code Clients] -->|HTTPS/SSE| NG
        API[API Consumers] -->|HTTPS/REST| NG
    end

See Security Architecture for details on authentication, rate limiting, and the CSF safety framework.