Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.hexr.dev/llms.txt

Use this file to discover all available pages before exploring further.

hexr build is the first command in every Hexr deployment. You point it at your Python agent file and it performs deep AST analysis — roughly 2,900 lines of it — to understand your agent’s framework, sub-agent roles, cloud resource requirements, and A2A topology. From that analysis it generates everything needed for a production Kubernetes deployment: a multi-stage Dockerfile, namespace and RBAC manifests, per-process SPIFFE context files, an A2A agent card, and a build metadata manifest. You never write these files by hand.

​
Usage

hexr build <agent_file> --tenant <tenant> [options]

​
Arguments

​
agent_file
path
required
Path to your Python agent file.
hexr build my_agent.py --tenant acme-corp
hexr build agents/content_crew.py --tenant acme-corp

​
Options

​
--tenant, -t
string
required
Tenant identifier. Maps to the Kubernetes namespace tenant-{tenant}.
​
--name, -n
string
Override the agent name. Defaults to the value in @hexr_agent(name=...) or the filename.
​
--target
string
default:"development"
Target environment: development, staging, or production.Affects OPA policies, resource limits, and security scanning levels.
​
--registry
string
Container registry base URL.
hexr build agent.py -t acme --registry us-central1-docker.pkg.dev/my-project/images
​
--pypi-url
string
default:"https://pypi.hexr.cloud/simple/"
Private PyPI URL for SDK installation in agent pods.
​
--python-version
string
default:"3.11"
Python version to use in the container image.
​
--base-image
string
default:"python:3.11-slim"
Base Docker image for the generated Dockerfile.
​
--multi-cloud
string
Comma-separated list of cloud providers to configure for credential exchange.
hexr build agent.py -t acme --multi-cloud aws,gcp,azure
​
--subprocess-support
flag
Enable subprocess role management for multi-process agents.
​
--security-scan
flag
Run a dependency security audit during the build step.
​
--output-dir, -o
path
default:".hexr"
Output directory for all generated artifacts.
​
--dockerfile-only
flag
Generate only the Dockerfile and requirements — skip Kubernetes manifests.
​
--dry-run
flag
Print what would be generated without writing any files.
​
--trust-domain
string
default:"demo.hexr.dev"
SPIFFE trust domain used when generating agent identity paths.

​
What gets generated

After a successful build, your .hexr/ directory contains: 
.hexr/
├── Dockerfile                    # Multi-stage build with SDK injection
├── requirements.txt              # Auto-detected from imports
├── agent-pod.yaml                # Pod spec with 4 containers
├── namespace.yaml                # tenant-{name} namespace
├── rbac.yaml                     # ServiceAccount + RoleBindings
├── agent-card.yaml               # ConfigMap for A2A discovery
├── process-contexts/             # Per-process SPIFFE context
│   ├── researcher.json
│   ├── writer.json
│   └── editor.json
└── hexr-manifest.json            # Build metadata

​
AST analysis

The build command inspects your agent file at the syntax-tree level — without executing it — to extract:
  1. Framework detection — CrewAI, LangChain, AutoGen, Strands, Swarm, or pure Python
  2. Agent discovery — all @hexr_agent decorators and framework-specific declarations
  3. Sub-agent mapping — distinct roles (researcher, writer, editor) for per-process identity
  4. Resource inference — hexr_tool() calls that determine required cloud permissions
  5. A2A detection — A2AClient usage and a2a=True parameters
  6. Coordination graph — NetworkX analysis of agent-to-agent relationships

​
Examples

$ hexr build research_agent.py --tenant acme-corp

Analyzing research_agent.py...
  Framework: pure_python
  Agents: 1 (research-agent)
  Resources: aws_s3
  A2A: disabled

Generated .hexr/ (5 files)
Run hexr push from the same directory after hexr build completes. hexr push reads the .hexr/ directory produced here.