Skip to main content

AxonFlow v8.0.0 Release Notes

Released 2026-05-22. The runtime FORCE Row-Level Security work and the application-role default flip ship under the v8.0.0 platform tag. SDK + plugin + Rust numbers (v8.1.0 / v1.5.0 / v0.3.1) released together with v8.0.0 platform.

Row-Level Security default-on. The identity model cleanup landed across the v8.x train; v8.0.0 is the release where AxonFlow's agent and customer-portal default to connecting as axonflow_app_role (a non-owner Postgres role that does not bypass RLS) and rely on FORCE ROW LEVEL SECURITY to enforce tenant isolation.

This is a major version because the runtime database role changes for fresh deploys. For customers using only the SDKs / plugins / HTTP API, there is no breaking change — JSON field names are unchanged, the X-Tenant-ID header is accepted as a deprecated alias, Basic Auth credentials keep working, and existing v7.x / v8.x licenses keep validating.

For the full mapping, see the v8 → v9 Migration Guide.

What changed in v8.0.0 (customer-visible)​

Loud-fail boot guard for misconfigured role envs​

Previously, an operator who forgot to set the new AXONFLOW_DB_PLATFORM_ADMIN_URL env got a silent fallback — the cross-org workers in the agent + orchestrator + customer-portal binaries quietly returned zero rows instead of erroring. Under FORCE Row-Level Security that meant cross-org metering, sweep, recovery, monitoring, and admin handlers all silently no-op'd.

v8.0.0 makes that failure mode loud: the binaries refuse to boot with a FATAL log line naming both the missing env var and the affected worker. If you misconfigure the new role env vars, the agent will not start instead of starting up broken. The detailed operator-facing wiring (six worker prefixes that trigger the guard + the recommended remediation) is shipped to enterprise operators in the v8.0.0 Self-Hosted Upgrade Guide and the v8.0.0 Enterprise Migration Guide.

Self-hosted source-fork operators: customized writes must wrap RLS-protected tables​

If you maintain a fork of axonflow-enterprise with customized handlers issuing their own INSERT / UPDATE / DELETE against FORCE-RLS-protected tables, audit those writes before flipping AXONFLOW_DB_USE_APP_ROLE=true. The brief recipe is in the v8 → v9 Migration Guide § Customized handlers must wrap writes. The full source-fork audit walkthrough is shipped to enterprise operators in the v8.0.0 Enterprise Migration Guide.

Direct SQL on a shared DB under the app role​

If you have direct DB access to the AxonFlow application database (typically self-hosted / in-VPC) and your tooling connects as the app role, SELECTs return zero rows unless app.current_org_id is set first. Connect as axonflow_platform_admin for legitimate cross-org needs, or set the session variable for per-org SELECTs.

What stays the same on the wire​

  • JSON field names are unchanged. The registration response from /api/v1/register still returns "tenant_id". The Plugin Pro Stripe checkout still has a tenant_id custom field. Same field, same value — the v9 model just calls it client_id semantically.
  • X-Tenant-ID HTTP header is accepted as a deprecated alias for X-Client-ID. The agent and orchestrator forward both during the v8.0.0 compatibility window. v10 (no date set) will reject X-Tenant-ID.
  • Basic Auth credentials are unchanged. Existing clientId / clientSecret pairs continue to work. The SDK already uses the v9-correct field name.
  • License payload V3 (deployment_id field) shipped in the v8.x train and is unchanged in v8.0.0. V2 licenses continue to validate; customers do not need to regenerate.
  • Plugin Pro license tokens are unchanged. The tenant_id claim in the encoded token payload is still the Basic-Auth-derived value.
  • Community-SaaS cs_* credentials are unchanged. No re-registration required.

Breaking changes (customer-visible)​

SurfaceWhat breaksWorkaround
AXONFLOW_DB_USE_APP_ROLE defaultFlipped from false to true. Fresh deploys connect as axonflow_app_role (NOBYPASSRLS).Set AXONFLOW_DB_USE_APP_ROLE=false explicitly during a phased rollout to preserve legacy semantics.
Direct SQL under the app roleSELECTs return zero rows unless app.current_org_id is set firstSet the session variable, or connect as axonflow_platform_admin for cross-org needs.

Self-hosted source-fork breaking changes (removed pool-scope helpers + customer-portal API consumer JSON tag rename) are detailed in the protected enterprise release notes — these affect operators, not SDK / plugin / HTTP API consumers.

Everything else stays compatible — SDK clients, HTTP API consumers, plugins, and Basic Auth credentials all keep working.

Upgrade notes by deployment shape​

Self-hosted Community (Docker / docker compose up)​

  • Pull the v8.0.0 image — most community-mode deployments work with the bundled docker-compose Postgres provisioned with both roles at first boot.
  • For your own Postgres (RDS, Aurora, on-prem), follow the simple-path 3-step community upgrade in the v8 → v9 Migration Guide: provision the app role, set AXONFLOW_DB_APP_ROLE_URL, deploy.
  • Custom SQL tooling against the application DB needs to either set app.current_org_id first, or connect as axonflow_platform_admin.

In-VPC Enterprise​

  • Follow the operator-focused v8.0.0 Self-Hosted Upgrade Guide (shipped to enterprise operators).
  • Detailed per-feature env-var combinations (customer-portal admin, multi-node enforcement, AWS Marketplace metering, GDPR right-to-erasure) ship to enterprise operators in the v8.0.0 Enterprise Migration Guide.
  • Existing licenses, credentials, and ORG_ID values keep working unchanged.

Community-SaaS users​

  • No action required. Existing cs_* credentials and Plugin Pro entitlements keep working.

SDK users​

  • Upgrade to v8.1.0 on the next dependency refresh (TypeScript / Python / Go / Java) or Rust v0.3.1 (preview). v8.1.0 SDKs emit X-Client-ID on every outbound request.
  • Existing v7.x / v8.0.0 SDK callers keep working — the v8.0.0 platform accepts X-Tenant-ID as a deprecated alias and derives identity from Basic Auth when X-Client-ID is absent.

Plugin users​

  • Upgrade to v1.5.0 (claude / cursor / codex) or v2.5.0 (openclaw) when those releases are tagged. Existing v1.4.0 / v2.4.0 plugins keep working — same plugin-pro license token format.

What carried over from the v8.x train​

The identity-model and FORCE-RLS schema work landed across the v8.x train as additive changes. v8.0.0 activates them.

Identity model — three distinct identifiers​

The v8.x train separated tenant_id into three concepts:

IdentifierWhat it isWhere it lives
org_idCustomer organization. Row-Level Security boundary.DB rows, auth context, X-Org-ID header (forwarded)
client_idAPI credential / app identity inside an org.Basic Auth username, auth context, X-Client-ID header
deployment license identityThe AxonFlow installation that booted this agent. Never written to customer rows.License payload V3 deployment_id field; V2 org_id field still accepted as back-compat alias; ORG_ID env, stack config

The SDK config field clientId already corresponded to v9's client_id — no SDK code changes required for callers.

X-Tenant-ID deprecation window​

VersionX-Client-IDX-Tenant-IDAgent → orchestrator forwarding
Early v8.xnot recognizedused internally for cross-process forwardingforwards X-Tenant-ID only
Current v8.xrecognized inbound + forwarded outboundaccepted as aliasforwards both X-Client-ID and X-Tenant-ID
v8.0.0 (this release)canonicalaccepted as deprecated aliasforwards both, with X-Client-ID as primary
v10 (planned)requiredrejectedforwards X-Client-ID only

The JSON tenant_id field on /api/v1/register responses, in Plugin Pro license tokens, and in audit-log payloads stays unchanged through v8.0.0. v10 will rename to client_id on the wire.

AxonFlow-operated deployments use the axonflow- prefix​

Internal AxonFlow deployments (community-saas, production-us) migrated to axonflow--prefixed deployment identities (axonflow-community-saas, axonflow-production-us). Telemetry classification uses the axonflow- prefix as the primary signal for "this row came from AxonFlow's own infrastructure."

Customer org_id values are unaffected — they stay free-form and should not start with axonflow- unless the customer is AxonFlow.

Schema additions (delivered as additive migrations 088-107)​

  • client_id columns added to credential / audit / policy / execution / service-identity tables.
  • Backfill: client_id = tenant_id for hot-path credential tables; org_id = client_id for Community-SaaS cs_* rows (migration 100).
  • Composite indexes (org_id, client_id, timestamp/created_at) on audit tables.
  • axonflow_app_role (NOBYPASSRLS) and axonflow_platform_admin (BYPASSRLS) roles created (migration 098).
  • FORCE ROW LEVEL SECURITY enabled on deployment_upgrades, saml_configurations, audit_archive (migration 099); mcp_query_audits, audit_retention_config, decision_chain (migrations 101-102); connectors, connector_configs, agent_heartbeats, node_violations (migration 107); organizations, tenants (migration 103); api_keys, customers (migration 117).
  • community_saas_registrations.org_id remapped from the shared community-saas constant to per-customer org_id=tenant_id=client_id=cs_<uuid> (migration 100).

License payload V3 — deployment_id field​

The v8.0.0 license payload format (V3) adds a deployment_id JSON field carrying the deployment/licensee identity. V3 mints both deployment_id and org_id with the same value so v8 (V2-only) readers continue to validate signed payloads.

Customers do not need to regenerate licenses for v8.0.0. V2 licenses keep working through v8.0.0 and beyond — V3 is purely a clarity rename.

Additional v8.0.0 hardening​

  • Agent agent_heartbeats UPSERT under FORCE RLS — the agent's sendHeartbeat path wraps the UPSERT in an org-scoped transaction so the heartbeat write succeeds under axonflow_app_role against the FORCE-RLS-enabled table.
  • AST audit walker for write-path coverage — a build-time guard preventing customized writes from bypassing the three wrap patterns is in place; CI fails on any unwrapped INSERT / UPDATE / DELETE into an RLS-gated table. Self-hosted source forks inherit the same CI guard when they pick up the v8.0.0 codebase and customize on top.

Migration resources​

  • v8 → v9 Migration Guide — the customer-facing mapping including the deployment-shape decision tree, simple-path community upgrade, cheat sheet, header timeline, and verification commands.
  • v8.0.0 Self-Hosted Upgrade Guide (shipped to enterprise operators) — operator-focused stage-by-stage upgrade.
  • v8.0.0 Enterprise Migration Guide (shipped to enterprise operators) — per-feature env-var combinations, customer-portal admin DSN format, source-fork audit recipe.
  • Auth and Header Matrix — Identity Primer — the three-identifier model.
  • License Management — license deployment identity distinguished from row identity.

See also​

Last updated on