Skip to main content

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_KEY
  • ANTHROPIC_API_KEY
  • GOOGLE_API_KEY
  • AZURE_OPENAI_ENDPOINT
  • AZURE_OPENAI_API_KEY
  • AZURE_OPENAI_DEPLOYMENT_NAME
  • OLLAMA_ENDPOINT
  • OLLAMA_MODEL
  • DEFAULT_LLM_PROVIDER
  • LLM_ROUTING_STRATEGY
  • PROVIDER_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.

Enterprise provider setup​

For AWS-native enterprise deployments, Bedrock is a common first provider integration. The operational pattern is:

  1. attach the required IAM permissions to the relevant ECS task role
  2. confirm regional Bedrock access for the target models
  3. configure the provider through the provider-management surface available in your deployment
  4. validate routing and fallback behavior before exposing real traffic

Use AWS Bedrock Setup, Provider Routing, and Provider Credential Matrix as the public baseline. Licensed enterprise customers should use protected provider-management docs for portal-specific API behavior.

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:

VariableWhy it matters
PII_ACTIONGlobal PII behavior
SQLI_ACTIONGlobal SQL injection behavior
MCP_PII_ACTION, MCP_SQLI_ACTIONMCP-specific overrides
GATEWAY_PII_ACTION, GATEWAY_SQLI_ACTIONGateway-specific overrides
MCP_MAX_ROWS_PER_QUERY, MCP_MAX_BYTES_PER_QUERYMCP exfiltration guardrails
MCP_DYNAMIC_POLICIES_ENABLEDOrchestrator-backed tenant policy enforcement

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.

Enterprise secrets and dependencies​

For enterprise deployments, finish the secrets and runtime dependency story immediately after deployment:

  • store provider, connector, database, and admin credentials in the deployment's approved secret manager
  • align task-role or workload-identity permissions with the secrets and cloud services the platform needs
  • confirm database, provider, and connector credentials are not embedded in task definitions, scripts, manual shell history, or screenshots
  • set a rotation schedule for credentials that survive beyond evaluation

This matters especially for Bedrock, enterprise connectors, and customer-portal admin flows.

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. Complete Production Hardening​

Production hardening should happen before the first high-risk workload, not after the first incident.

Review:

  • TLS and certificate configuration
  • VPC endpoint usage where appropriate
  • backup and restore checks
  • CloudTrail, flow-log, and audit-log coverage
  • ALB and service-to-service security-group rules
  • telemetry and data-boundary expectations
  • database users, permissions, and tenant-isolation settings

Database security​

Enterprise deployments commonly separate database ownership from application access:

  • axonflow: owner role with schema access, used for migrations and administrative maintenance
  • axonflow_app: restricted application role, used by runtime services with Row-Level Security where the deployment enables tenant-isolated access

Where the deployment uses a restricted application database role and Row-Level Security, validate tenant isolation with a low-risk query in a non-production environment before onboarding teams:

psql -U axonflow_app -d axonflow -c "SET app.tenant_id = 'tenant-a'; SELECT * FROM connectors;"

The query should only return rows for tenant-a. Use a test tenant and a non-production database when validating this path.

If the database password is stored in AWS Secrets Manager, rotate it through the approved secret workflow:

aws secretsmanager rotate-secret --secret-id axonflow/production/database

8. 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.

9. 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.

Next Steps​

Operational Readiness Checklist​

Before relying on this page in a production rollout, pair it with the core operations docs:

Last updated on