Frequently asked questions.

A downloadable deployment-operations workspace for intake, readiness, approvals, plan review, guided execution, validation, evidence, and closure. Connector and execution availability is shown in the installed release.

A user selects a repository, branch, and environment, then asks the Agent for an outcome. Read-only tools can run inline. Any GitHub write or deployment stops at an explicit proposal, risk check, and admin approval before the real action runs.

No. The released path uses your GitHub repository, GitHub Actions workflow, AWS role, ECS target, and optional Airflow installation. Axiom adds selection, governance, approval, and evidence around those systems.

AWS ECS deployment is released through the tenant's own GitHub Actions workflow. GitHub Actions uses OIDC to assume the configured AWS role, waits for ECS steady state, and rolls back to the previous task definition if stabilization fails.

GitHub access is minted for one selected repository through the installed GitHub App. AWS credentials are not stored by Axiom; the deployment workflow uses GitHub OIDC and the role configured for the selected environment.

The released AWS deployment path stores no long-lived AWS access key in Axiom. GitHub Actions obtains short-lived AWS credentials through OIDC. Provider tokens and desktop sessions remain tenant-scoped and are handled by the service, not entered into chat.

Remove the GitHub App installation or repository grant, and remove or disable the configured AWS role trust relationship. The desktop Integration Center shows the server-verified connection state.

No. Repository reads can execute inline, but branch creation, file commits, and pull-request creation become persisted action proposals. An authorized workspace admin must approve the proposal before the write function runs.

Every Agent tool call receives an audit record, including low-risk reads. Proposed writes record their inputs, risk, status, approval or rejection, execution result, and timestamps.

AI is opt-in per workspace. The runtime checks AI credit and provider policy before calling a model, and fails closed if either check is not satisfied. A model also has to be enabled in workspace settings.

The desktop app keeps repository, branch, environment, and conversation context visible and click-selectable. Treat persistent cross-conversation memory as release-dependent; the installed app is the authority for what is available.

Read-only checks may execute inline. Medium- and high-risk changes require explicit approval, and production context can only increase risk. The Agent cannot approve its own proposal.

Rollback availability depends on the active adapter, prerequisites, and verified recovery evidence. When automatic rollback is unavailable, the app must keep the failure visible and require an explicit manual recovery path.

The product is designed around explicit authority and evidence. Any emergency or direct-production path must be separately permissioned, visibly labeled, and audited; availability depends on the installed release and workspace policy.

Each environment can map to an AWS region, role ARN, ECS cluster, and ECS service. Selecting an environment gives the Agent and deployment workflow that governed target instead of asking the user to type cloud coordinates into chat.

A configured Airflow connection can expose DAGs for click-based selection and dependency checks. Scheduling or triggering a governed action must still pass the configured approval, retry, notification, and audit boundaries.

The tenant workflow captures the previous task definition, performs the deployment, waits on ECS steady-state validation, and automatically restores the previous task definition if the new service does not stabilize.

Yes. The downloadable Tauri desktop app is the product interface. The download page is the authority for currently published, signed platform builds.

The public website explains and demonstrates the product. Authenticated /dashboard and /operator browser routes redirect to download; operational work happens in the desktop app using desktop-session authentication.

Visit /download for OS-detected install links and the full platform roadmap.

The proposed self-service catalog is Free at $0, Pro at $29 per user each month, and Enterprise at $79 per user each month, with 20% annual pricing. Checkout remains disabled until Stripe test-mode products, webhooks, organization seats, and server-side quotas pass review.

Yes. The interactive demonstration is labeled as scripted sample data, documentation is public, and the Free proposal includes 2 organization members and 10 counted deployments per month once billing entitlements are activated.

Enterprise identity configuration exists, but a configured provider remains pending until a real OIDC or SAML client and sign-in path are verified. A logo or saved provider record does not mean enterprise sign-in is active.