Post-Deployment Configuration
After AxonFlow is running, the next job is not “deploy more YAML.” It is proving that the control plane is healthy, observable, and configured for the workflows your engineers will actually build.
1. Verify Core Runtime Health
curl -s http://localhost:8080/health | jq .
curl -s http://localhost:8081/health | jq .
docker compose ps
What to confirm:
- both services return
status: healthy - Agent reports the expected service identity
- Orchestrator is healthy and reachable
- containers are healthy in Docker Compose, not just running
- the Agent and Orchestrator agree on shared configuration such as internal auth secrets when you set them
2. Verify Metrics and Dashboards
curl -s http://localhost:8080/prometheus | head
curl -s http://localhost:8081/prometheus | head
curl -s http://localhost:9090/-/healthy
curl -s http://localhost:3000/api/health
You want observability working before teams depend on the platform. The built-in Grafana dashboard is one of the fastest ways to confirm requests, blocks, token usage, and connector activity are visible.
If Prometheus scraping is broken, fix that before you roll the platform out to more users. It is much harder to debug provider, connector, or policy incidents after the fact when the monitoring path was never verified.
3. Confirm LLM Provider Configuration
For community self-hosted deployments, provider configuration is driven by environment variables such as:
OPENAI_API_KEYANTHROPIC_API_KEYGOOGLE_API_KEYAZURE_OPENAI_ENDPOINTAZURE_OPENAI_API_KEYAZURE_OPENAI_DEPLOYMENT_NAMEOLLAMA_ENDPOINTOLLAMA_MODELDEFAULT_LLM_PROVIDERLLM_ROUTING_STRATEGYPROVIDER_WEIGHTS
If you expect proxy mode, MAP, or routed workflows to work, at least one provider must be configured correctly.
It is worth running one real request through the configured provider at this point. A healthy Orchestrator with zero usable providers is a common source of confusion during initial rollout.
4. Validate MCP Connector Access
Community Docker Compose mounts config/axonflow.yaml, which registers the default local PostgreSQL-backed connectors. Verify connector-backed workflows against the actual connector names your team will call.
Recommended checks:
- run a simple MCP query through the SDK or API
- confirm policy enforcement and redaction behavior
- verify connector errors appear in logs and metrics
- confirm the connector set matches the active edition so engineers do not design against unavailable tooling
Start with:
5. Set the Security Defaults Intentionally
Do not leave security behavior as an accident of inherited defaults. The important runtime controls to review early are:
| Variable | Why it matters |
|---|---|
PII_ACTION | Global PII behavior |
SQLI_ACTION | Global SQL injection behavior |
MCP_PII_ACTION, MCP_SQLI_ACTION | MCP-specific overrides |
GATEWAY_PII_ACTION, GATEWAY_SQLI_ACTION | Gateway-specific overrides |
MCP_MAX_ROWS_PER_QUERY, MCP_MAX_BYTES_PER_QUERY | MCP exfiltration guardrails |
MCP_DYNAMIC_POLICIES_ENABLED | Orchestrator-backed tenant policy evaluation |
Community is a strong place to validate these controls. Evaluation and Enterprise become important when teams want higher limits, stronger governance workflows, and broader rollout confidence.
6. Add Internal Service Authentication
For shared environments, set:
export AXONFLOW_INTERNAL_SERVICE_SECRET=$(openssl rand -hex 32)
Use the same secret for both the Agent and Orchestrator. This hardens internal service-to-service requests, including Orchestrator calls into agent-side MCP functionality.
If the values drift between services, you can end up with a runtime that looks healthy at a glance but fails once workflow or MCP traffic crosses service boundaries.
7. Run One End-to-End Workflow
Before calling the deployment “done,” run one realistic workflow that proves:
- policy checks happen
- routing and provider behavior works
- audit records are written
- metrics move in Grafana or Prometheus
- developers can debug what happened
That is the threshold a senior engineer will care about, not just whether /health returns 200.
8. Decide Whether Community Is Still Enough
Community is often enough to prototype and even run smaller governed AI systems. But once teams need broader limits, procurement-friendly rollout, enterprise identity, or stronger governance guarantees, that is usually the point where Evaluation or Enterprise becomes the right next step.
That is also the right moment to start documenting your own internal platform standards around providers, connectors, approvals, and audit expectations, because the AxonFlow runtime becomes more valuable as more teams share it.
