License Management

AxonFlow licensing is designed to let engineers start quickly on Community, validate real governed AI workflows on Evaluation, and then move to Enterprise when rollout scale, identity, governance, and retention requirements become serious.

The key operational point is simple: the runtime reads AXONFLOW_LICENSE_KEY on startup and applies the limits and features for the active tier. There is no separate code path or migration required when you upgrade.

Overview

AxonFlow uses a three-tier licensing model. Each tier controls resource limits and feature access rather than node counts.

Tier	License Required	Cost	How to Get
Community	No	Free	Clone the repo
Evaluation	Yes	Free	getaxonflow.com/evaluation-license
Enterprise	Yes	Paid	AWS Marketplace or [email protected]

Current Tier Limits

The following limits are the public runtime defaults reflected in the current platform code.

Resource	Community	Evaluation	Enterprise
Tenant policies	20	50	Unlimited
Organization policies	0	5	Unlimited
Connectors with custom policies	2	5	Unlimited
LLM providers	2	3	Unlimited
Audit retention	3 days	14 days	3650 days
Execution history	50	500	Unlimited
Concurrent executions	5	25	Unlimited
MAP plans	25	100	Unlimited
Versions per plan	10	25	Unlimited
SSE connections	5	25	Unlimited
Cost estimates per day	10	100	Unlimited
Pending approvals	5	100	Unlimited

Evaluation and Enterprise Feature Gates

Feature	Community	Evaluation	Enterprise
Media governance	Opt-in	Enabled	Enabled
Human-in-the-loop approvals	No	Yes	Yes
Policy simulation	No	Yes	Yes
Evidence export	No	Yes	Yes
Impact report inputs	0	50	100
Evidence export window	0	14 days	Unlimited

For the broader narrative and feature framing, see Community vs Enterprise.

Community Tier

Community requires no license key. Run AxonFlow without AXONFLOW_LICENSE_KEY and Community limits apply automatically.

git clone https://github.com/getaxonflow/axonflow.git
cd axonflow
docker compose up -d

Community is not only a toy tier. It is enough to:

• validate SDK integrations
• run real system-policy enforcement
• experiment with MCP connectors and workflow patterns
• prove out a governed AI architecture before procurement or platform rollout

The usual trigger to move beyond Community is not “we want to pay.” It is “we are hitting practical limits on policies, providers, approvals, retention, or internal rollout.”

Evaluation License

Evaluation provides elevated limits for serious pre-production validation. It is the right tier when a team has moved beyond isolated prototyping and wants to validate whether AxonFlow can serve as a real platform for governed AI usage.

Getting an Evaluation License

1. Go to getaxonflow.com/evaluation-license
2. Enter your name, email, and organization
3. Receive the license key by email

Activating an Evaluation License

Set the AXONFLOW_LICENSE_KEY environment variable before starting AxonFlow:

export AXONFLOW_LICENSE_KEY="AXON-eyJ...<payload>.<signature>"
docker compose up -d

Or add it to .env:

echo 'AXONFLOW_LICENSE_KEY=AXON-eyJ...<payload>.<signature>' >> .env
docker compose up -d

AxonFlow validates the license on startup and applies Evaluation limits immediately.

Enterprise License

Enterprise is for teams turning AxonFlow into shared platform infrastructure across departments, products, or regulated workloads. It unlocks broader governance workflows, enterprise identity, longer retention, richer compliance modules, and effectively unbounded operational limits.

Getting an Enterprise License

AWS Marketplace

1. Subscribe to AxonFlow through AWS Marketplace
2. Receive the Enterprise license key
3. Inject it through the supported deployment path for that package

Direct Purchase

1. Contact [email protected]
2. Receive an Enterprise license key and deployment guidance

Activating an Enterprise License

At runtime, Enterprise activation is still the same basic mechanism as Evaluation: the platform reads AXONFLOW_LICENSE_KEY on startup and applies the licensed limits and features. What changes is how you inject that secret into your deployment.

Self-managed or container-based deployments

export AXONFLOW_LICENSE_KEY="AXON-eyJ...<payload>.<signature>"
docker compose up -d

Managed deployments and cloud packages

If you are running a protected enterprise deployment package, inject the key through the supported secret-management path for that environment. The protected enterprise docs cover the exact flow for AWS Marketplace, CloudFormation, and customer-specific deployment models.

Rotating or replacing a license

aws secretsmanager update-secret \
  --secret-id axonflow/license-key \
  --secret-string "AXON-eyJ...<payload>.<signature>"

aws ecs update-service --cluster axonflow-cluster \
  --service axonflow-agent-service --force-new-deployment

aws ecs update-service --cluster axonflow-cluster \
  --service axonflow-orchestrator-service --force-new-deployment

If you are not on AWS, the principle is the same:

1. update the secret or environment variable that backs AXONFLOW_LICENSE_KEY
2. restart the Agent and Orchestrator so they reload the license
3. verify the runtime is on the expected tier before re-enabling higher-tier workflows

License Format

AxonFlow license keys are signed tokens with the format:

AXON-{BASE64URL(JSON_PAYLOAD)}.{BASE64URL(ED25519_SIGNATURE)}

• AXON- is the fixed prefix
• the payload encodes the deployment identity (V2 payloads named the field org_id; V3 payloads shipped 2026-05-19 in PR #2257 add deployment_id alongside as the canonical name and keep org_id as a back-compat alias), the tier, and the expiry
• the signature protects against tampering

The three distinct identifiers

The license payload, request identity, and DB row identity are three separate concepts in the v9 identity model. Conflating them was the source of several pre-v9 bugs.

Identifier	Purpose	Where it lives
License deployment identity	Identifies the AxonFlow installation allowed to boot. Validated at startup.	License payload: V3 mints both deployment_id (canonical) and org_id (back-compat alias) with the same value; V2-only payloads still validate. Agent reads deployment_id when present and falls back to org_id. Also lives in the ORG_ID env var on the agent.
org_id (customer organization)	Customer/account boundary. Row-Level Security uses this under the v8.0.0 default of AXONFLOW_DB_USE_APP_ROLE=true.	DB rows, request context, X-Org-ID header
client_id (API credential)	The credential/app identity that authenticated this request.	Basic Auth username, request context, X-Client-ID header

For self-hosted Community and In-VPC Enterprise customers, the license deployment identity, org_id, and client_id often share values today — that does not make them the same concept. v9 makes the distinction explicit so RLS, audit, and billing all line up.

Key consequences:

• One license can serve multiple client_id credentials inside the same org_id (e.g., prod, staging, dev) by issuing different clientId values to each.
• Upgrading licenses never changes your row-level data identity — your data stays accessible.
• The license payload's identity is never written into customer-data rows.
• Customers do not need to regenerate licenses to migrate from V2 to V3. V2 licenses keep working through v9 and beyond.

See the v7 → v8 Migration Guide for the full mapping, including the AxonFlow-operated-deployment identity convention (axonflow- prefix) that keeps internal deployments distinct from any customer's org_id. The V3 payload, X-Client-ID header, client_id columns, and FORCE ROW LEVEL SECURITY under axonflow_app_role all ship as part of v8.0.0.

Do not attempt to create or modify license keys manually. Invalid signatures are rejected.

License Expiry and Graceful Degradation

When a license expires, AxonFlow does not stop working. It degrades gracefully to Community limits.

After Expiry	Behavior
Tenant policies	Capped at 20
Organization policies	Disabled
Connectors with custom policies	Capped at 2
Audit retention	3 days
Existing data	Preserved

To restore elevated limits, set a valid non-expired license key and restart AxonFlow.

This behavior is important operationally. It means expired licenses usually show up first as feature-limit or entitlement problems, not as total platform outages. Teams should monitor for degraded capability, not only for process health.

Upgrading Between Tiers

Community to Evaluation

1. Register for an Evaluation key
2. Set AXONFLOW_LICENSE_KEY
3. Restart AxonFlow
4. Limits increase immediately with no migration

Evaluation to Enterprise

1. Purchase or subscribe to Enterprise
2. Replace the Evaluation key with the Enterprise key
3. Restart AxonFlow
4. Enterprise features and limits become available immediately

All upgrades are seamless with zero data loss:

• your clientId (API credential) and org_id (customer organization) stay the same — just swap the license key
• existing policies, configurations, and audit data remain accessible
• SDK integrations do not need code changes
• the same runtime and request paths continue to work

The practical upgrade triggers are usually:

• teams hit the Community or Evaluation ceiling on policies, providers, plans, or execution history
• a shared platform team needs SSO, SCIM, or stronger approval workflows
• procurement or compliance reviewers need longer retention and enterprise controls
• the platform is moving from a few engineers to company-wide governed usage

Troubleshooting

License Not Recognized

Symptoms: AxonFlow starts in Community mode even though you set AXONFLOW_LICENSE_KEY.

Check:

echo "$AXONFLOW_LICENSE_KEY"
echo "$AXONFLOW_LICENSE_KEY" | cut -c1-5
docker compose exec agent printenv AXONFLOW_LICENSE_KEY | cut -c1-5
docker compose exec orchestrator printenv AXONFLOW_LICENSE_KEY | cut -c1-5

Common causes:

• extra whitespace or newline in the key
• the key is set in your shell but not passed into the container or service definition
• typo in the variable name

License Expired

Symptoms: higher-tier features that previously worked now return tier validation errors.

Fix:

1. obtain a renewed license key
2. update AXONFLOW_LICENSE_KEY
3. restart the runtime

Policy or Feature Limit Exceeded

Symptoms: creating policies, provider configs, plans, or approvals starts failing even though the runtime is healthy.

Fix:

• confirm the active tier
• compare the operation with the current tier limits above
• upgrade if the platform has outgrown the current tier

Security Best Practices

Storing License Keys

Recommended:

• store AXONFLOW_LICENSE_KEY in a secret manager or encrypted environment store
• use AWS Secrets Manager or the equivalent secret store on your platform
• limit access to the secret to the runtime only

Avoid:

• hardcoding the key in application code or committed compose files
• storing the key in plaintext files
• sending the key through unencrypted channels

Support

Tier	Support Channel	Response
Community	GitHub Issues	Best effort
Evaluation	GitHub Issues	Best effort
Enterprise	Priority support	Per contract or SLA

License-related issues: [email protected]

Related Docs

• Community vs Enterprise
• Post-Deployment Checklist
• SDK Authentication
• v7 → v8 Migration Guide — identity terminology, RLS enforcement, deprecated header aliases
• Auth and Header Matrix — request-time identity headers reference
• Security Best Practices

Operational Readiness Checklist

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

• Deployment Mode Matrix for self-hosted, Evaluation, Enterprise, SaaS, and In-VPC fit
• Failure Modes And Recovery for degraded-provider, connector, approval, and runtime behavior
• Capacity Planning for sizing and growth signals
• Community vs Evaluation vs Enterprise for limits, support surfaces, and upgrade triggers