Deployment Mode Matrix

AxonFlow has both edition tiers and deployment modes. Teams often mix those concepts together, but they answer different questions:

• tier controls feature limits and licensing behavior
• deployment mode controls how the platform is operated and what the portal exposes

This page is the fast reference for the deployment side of that picture.

The Important Distinction

For public docs, the most relevant runtime and deployment states are:

• Community: self-hosted runtime with no license
• Evaluation: self-hosted runtime with an evaluation license
• SaaS: enterprise-operated multi-tenant deployment
• In-VPC: enterprise deployment in the customer’s AWS account

Community and Evaluation usually share the same core self-hosted topology. SaaS and In-VPC are enterprise operating models that change visibility, identity, and portal behavior.

Deployment Mode Matrix

Mode	Typical user	Tenant isolation	Node visibility	Platform metrics visibility	Deployment controls	Protected portal workflows
Community	engineer validating locally	self-managed, no portal RLS surface	local only	self-managed via Prometheus/Grafana	Docker Compose / self-managed	No
Evaluation	platform team validating pre-prod	self-managed	self-managed	self-managed	self-managed	Usually no full enterprise portal path
SaaS	enterprise customer using AxonFlow-hosted control plane	yes	hidden in portal	tenant-focused usage only	hidden in portal	Yes
In-VPC	enterprise platform team running AxonFlow in its own AWS account	no RLS-style tenant isolation in portal mode	visible in portal	visible in portal	visible in portal	Yes

What The Enterprise Portal Actually Uses

The customer portal’s deployment-config API currently returns:

• mode
• tenant_isolation
• show_node_usage
• show_platform_metrics
• show_deployments

For the current portal code path:

• saas means request-focused, tenant-isolated portal behavior
• invpc means platform-aware portal behavior with node and deployment visibility

That matters because the same enterprise portal intentionally behaves differently depending on where it is running.

How To Decide Which Mode Fits

Community

Choose community when you want to:

• stand up the core runtime quickly
• validate SDK integration
• test MCP, policies, and workflows locally
• prove that AxonFlow can govern real AI traffic before involving procurement

Evaluation

Choose evaluation when you need to:

• keep the same self-hosted control plane shape
• raise limits to something closer to real staging or pilot usage
• test approval queues, policy simulation, and evidence-export behavior

SaaS

Choose SaaS when the enterprise wants:

• portal-backed operations
• strong tenant isolation in the hosted control plane
• less infrastructure responsibility on the customer side

In-VPC

Choose In-VPC when the enterprise wants:

• AWS-account ownership
• more infrastructure visibility in the portal
• deployment and node operations inside its own environment

Common Mistake

The most common planning mistake is to treat Evaluation like a separate hosting mode. It is usually better understood as a licensed version of the self-hosted runtime. SaaS and In-VPC are the bigger operating-model changes.

Related Docs

• Community vs Evaluation vs Enterprise
• Deploy AxonFlow
• Self-Hosted
• Community To Enterprise Migration

Telemetry's deployment_mode Field

The deployment-mode concept above describes the runtime topology a team chooses. AxonFlow's anonymous heartbeat surfaces a closely related (but narrower) value on the wire as the deployment_mode field.

Wire value	When SDKs / plugins set it
community_saas	The configured AxonFlow endpoint host matches *.try.getaxonflow.com, or the env var AXONFLOW_TRY=1 is set
self_hosted	Any other endpoint configuration
unknown	Endpoint is empty or unparseable

The wire enum is intentionally a closed three-value set so analytics queries don't have to enumerate every deployment-side topology variant. The Pilot / Growth / Enterprise tier a team uses is not reflected on the wire — telemetry is anonymous and does not carry license-tier information. For the full wire-level field reference, see Telemetry and Checkpoint Service API.

Operational Readiness Checklist

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

• 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