xAutodocs Sign in

The three-level model every screen reads, and why a connection is the thing that actually holds credentials.

Projects, environments and connections

Everything in xAuto hangs off three levels. Understanding them is most of understanding the app.

Organization
└── Project              a system you operate
    └── Environment      QA / UAT / Staging / Production / ...
        └── Connection   one provider account, one region/scope
            └── Resource tracked infrastructure

Organizations

An organization is the tenant boundary — the billing, the members and the plan all belong to it. One person can belong to several, with a different role in each, and switching between them is in the account menu. Nothing crosses the boundary: a project in one organization is invisible from another, including to you.

See Organization, branding, plans and billing.

Projects

A project is one system you operate. It owns its environments, its connections, its pipelines, its alert rules and its tracked resources.

Most screens are locked until a project is selected, because most screens have no meaningful answer without one. The exceptions are deliberate: Organization, Approvals, Access requests and, when the plan and role include it, Compliance. These are organization-wide screens and remain useful before the first project exists. This guide is public at xauto.dev/docs/ and does not require signing in.

Environments

Environments are names you choose. The platform attaches no meaning to them except one: an environment whose name marks it as Production raises the bar on consequential actions — triggering a pipeline needs a second eligible approver, and provisioning or restoring into it needs the trigger-production permission. An administrator can also require approval on a non-Production environment from the project's Approvals settings.

An environment is also the unit of access scoping. A colleague can be an operator on QA and a viewer on Production — see Roles and access.

Connections

A connection binds one provider account to a project. It carries the region or scope, and it carries the credential.

Three things about credentials are worth knowing up front, because they shape what the app can and cannot show you:

  • The secret is never returned. Registering a connection writes the credential straight to AWS Secrets Manager and strips it before the connection is stored. No API response and no log line ever carries it back. Revealing one again is its own permission and is written to the audit trail.

  • Every provider call runs under the connection's own credential, resolved per request. The platform's own identity reaches nothing but its own table and the secret store — so whatever you scope the credential to is exactly what the app can do.

  • A narrow credential limits exactly what the connector can show or change. Depending on the provider, an under-permissioned call can fail that view or leave a partial inventory. Connectors with independent per-service reads—most notably GCP—report which kinds could not be listed so an unreadable API is not mistaken for an empty account.

A connection may be scoped to one environment, or left project-wide and shared by all of them. Project-wide is right when one account really does serve every environment.

The generic connection form supports AWS, MongoDB Atlas, Azure, Azure DevOps, SendGrid, FCM, GCP and Cloudflare. Self-hosted PostgreSQL, MongoDB and MySQL connections are registered from Backups, because their lifecycle is a database-backup workflow rather than a cloud inventory. The Connectors screen shows one card per registered connection and opens the provider's live account view; management for an imported service lives on that service in Resources. See the Connector reference for the credential and capability differences.

Testing a connection

"Test connection" in the Connectors drawer header asks the provider whether the stored credential still authenticates. It is a property of the connection, not of the provider pane you happen to have open — a rotated or expired key is the first thing to rule out when a screen stops answering.

Where the selection lives

The project/environment/connection selection is persisted per operator and stamped onto the URL. Two consequences worth knowing:

  • Copying a URL copies the context. Sharing a link to a resource sends your colleague to the same project and environment you were in.

  • Switching organization clears the project selection, because a project id from one tenant is correctly refused in another.