PentAGI setup: the sandbox boundary, tenant gaps, and report export

The agent picks its own steps, then asks Docker to run them

PentAGI does not replay a fixed script. The agent decides which penetration testing steps to take and executes them, with a delegation system that hands research, development and infrastructure work to specialist agents. Everything runs in a sandboxed Docker container rather than on the host, and each command with its output lands in PostgreSQL carrying the pgvector extension. The toolkit inside that container is fixed at 20+ tools, nmap, metasploit and sqlmap among them.

The compose file shows how small the surface is. One service named pentagi, port 8443, and a hard dependency on the pgvector service reaching a healthy state first:

    expose:
      - 8443/tcp
    ports:
      - ${PENTAGI_LISTEN_IP:-127.0.0.1}:${PENTAGI_LISTEN_PORT:-8443}:8443
    depends_on:
      pgvector:
        condition: service_healthy

A flow that needs a listener publishes it on the host from a reserved window: DOCKER_PORTS_BASE is 28000 unless changed, and one instance owns the 2000 ports above it. Human review is a switch rather than a default, since ASK_USER starts as false.

TENANT_ID does not move DATA_DIR, so a second instance overwrites the first

One PostgreSQL, one worker node, one Neo4j and one Langfuse can serve several instances. The namespace that separates them is TENANT_ID, and the value gets validated rather than trimmed:

## Must match ^[a-z][a-z0-9_]{0,31}$; invalid value aborts startup.
TENANT_ID=

The next comment in the same file is the part that bites. TENANT_ID is not derived into DATA_DIR, DOCKER_PORTS_BASE, listen ports or INSTALLATION_ID, and each instance sets those itself. The stated reason for DATA_DIR is that sharing it overwrites flow data. A second instance created by copying the compose file and typing a new tenant name therefore still points at the first one's flow directory unless DATA_DIR moves by hand, and because DOCKER_PORTS_BASE also has to differ, both instances claim the same 28000 window otherwise. A malformed tenant pattern fails loudly at startup instead of quietly sharing a namespace. backend/docs/config.md holds the detail under Multi-Instance Deployment (TENANT_ID).

The compose file pins DOCKER_GID=998 and binds to 127.0.0.1

Putting PentAGI on a machine means Docker Compose. The root docker-compose.yml pulls a published image, so nothing compiles on the host:

    image: ${PENTAGI_IMAGE:-vxcontrol/pentagi:latest}
    restart: unless-stopped

Configuration arrives as environment variables, and .env.example carries the defaults:

DEBUG=false
DATA_DIR=
DOCKER_PORTS_BASE=
INSTALLATION_ID=
LICENSE_KEY=

Two of those values decide whether the first run works. The port mapping binds to 127.0.0.1, so the web UI is reachable from the host and nothing else until PENTAGI_LISTEN_IP changes; TRUSTED_PROXIES and CORS_ORIGINS sit in the same environment for the same reason. DOCKER_GID is the harder one, because the compose file sets the literal 998 rather than reading it from the environment. On a host whose docker socket belongs to a different group id, the fix belongs in the compose file. What you should see is a healthy pgvector container, a pentagi container that started after it, and the UI answering on 8443. DATA_DIR resolves to ./data on the host and to /opt/pentagi/data inside the image.

Thirteen provider sections and a separate embedding story

No flow starts without a model, so keys come first. The compose environment carries OPEN_AI_KEY, OPEN_AI_SERVER_URL, ANTHROPIC_API_KEY and ANTHROPIC_SERVER_URL, and the README gives each provider its own configuration section, among them Azure OpenAI, Ollama, AWS Bedrock, DeepSeek, GLM, Kimi, Qwen, MiniMax, Mistral and xAI. Custom OpenAI-compatible endpoints go through the same path, which is how a private gateway gets used, and aggregators such as OpenRouter, DeepInfra and Atlas Cloud are wired in alongside them. For a local deployment the repository points at examples/guides/vllm-qwen35-27b-fp8.md, which serves Qwen3.5-27B-FP8 on vLLM.

Provider choice is not the whole configuration story. Embedding configuration and its own test path are separate sections, and the database image is the pgvector build rather than stock Postgres, so vector storage belongs to the base stack and not to an optional extra.

Report export stops at Markdown and PDF, and BAS scripts are future work

The capability boundaries are stated inside the project itself, and the first line refuses a category rather than a version of one. PentAGI is an autonomous and assistant-guided penetration testing platform, not a CALDERA-style breach and attack simulation product with predefined campaigns or attack plans. Agent-authored attack scripts of the BAS kind are named as conceptual or future work. The consequence is concrete: there is no campaign library to pick from, and every run is a path the agent constructs from scratch.

The second limit is narrower and more annoying on a Tuesday. The flow report view gives a web view, copy to clipboard, Markdown download and PDF download. JSON flow-report export is not documented as a supported output today, so a ticketing or CI pipeline that wants machine-readable findings has nothing documented to consume. Automation goes through the REST and GraphQL APIs with Bearer token authentication instead, which is a different integration shape from importing a finished report.

Four extra compose files, and the project's own images float on latest

Optional capability arrives as separate stacks rather than as flags. docker-compose-graphiti.yml, docker-compose-langfuse.yml, docker-compose-observability.yml and docker-compose.e2e.yml sit next to docker-compose.yml, each declaring its own networks and volumes. The Langfuse file pulls six services on its own, and the observability file brings a Grafana, a node exporter, cAdvisor, an OpenTelemetry collector and VictoriaMetrics. That means a second PostgreSQL and a second Redis to size, monitor and back up, running on the same machine as the agent doing the scanning.

Pinning is inconsistent, and the difference shows up at upgrade time:

NEO4J_IMAGE=neo4j:5.26.2
GRAFANA_IMAGE=grafana/grafana:11.4.0
POSTGRES_IMAGE=postgres:16
REDIS_IMAGE=redis:7

Third party images name a tag. PentAGI's own images, PENTAGI_IMAGE, PGVECTOR_IMAGE, SCRAPER_IMAGE and GRAPHITI_IMAGE, default to latest, so a restart of the stack can pull a newer PentAGI than the one you tested against.

Two major versions in three months, so upgrades need pinning

The repository is not archived and the last push was on 2026-09-23. The tag history says what an upgrade costs: v1.2.0 on 2026-02-25, v2.0.0 on 2026-04-11, then v2.1.0 on 2026-05-29. Two major lines inside three months, layered on a latest-by-default image, turns an upgrade into deliberate work rather than a pull. There is contributor-facing material for that work: CLAUDE.md, CONTRIBUTING.md, a scripts directory and examples/tests at the root.

The build pins its toolchain tightly, node:24.17.0-slim for the frontend and golang:1.26-bookworm for the backend, with a frozen lockfile and a cache mount on the package store:

RUN --mount=type=cache,target=/root/.local/share/pnpm/store \
    pnpm install --frozen-lockfile

A build from source therefore needs those exact toolchains, not whatever Node and Go happen to be on the machine.

MIT licensed, next to an EULA and a cloud callback block

The repository carries an MIT license and describes itself as a self-hosted solution with complete control over your deployment and data. The compose environment complicates that in small ways. INSTALLATION_ID and LICENSE_KEY are described in .env.example as being for communication with the PentAGI Cloud API, and UPDATE_STRATEGY, UPDATE_CHECK_INTERVAL, UPDATE_SERVER_HOST and SUPPORT_SERVER_HOST sit right beside them. They are empty rather than absent, so a shop that means self-hosted has to look at what those hosts do before the first boot rather than after it.

The root directory also holds EULA.md and NOTICE next to LICENSE, and the frontend build emits a dependency license report through license-checker into /licenses/frontend. The Dockerfile injects an edition string, and its own comment notes that ce is not a release number, so GetBinaryVersion reports the edition alone. Which obligations attach to a given deployment is a question for whoever owns the license, not something this repository settles for you.

Editorial conclusion

Adopt PentAGI if you want an agent that invents its own test path inside a container, and you can take machine-readable findings from its REST and GraphQL APIs instead of a report file. Do not adopt it as a campaign library or as a breach and attack simulation platform. Before the first boot, read EULA.md, pin PENTAGI_IMAGE to a tag rather than latest, and decide whether UPDATE_SERVER_HOST should point anywhere at all.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes