SpeyAI runs inside your environment: your host, your Postgres, your version control, your model account. Three containers and a database. Nothing is hosted by us, and no code or data leaves your building.
Which means the first question is rarely whether it can be governed. It is whether it fits the stack you already have. Every connection below is a setting rather than a code change, because a governance layer that only works on one company’s stack is not a product.
Each row is a choice you make once during setup. None of them requires anything to be rebuilt, and none of them puts your credentials anywhere but your own environment: the configuration names which variable holds a secret, never the secret itself.
GitHub, GitLab, Bitbucket or Azure DevOps, including self-managed instances at your own base URL. The org reads code and opens pull requests through a token you issue and scope.
Claude, through the account you already hold: Anthropic directly, AWS Bedrock, Microsoft Foundry or Google Vertex. Your billing, your region, your cloud. Cost accounting is identical across all four.
Your Postgres. Amazon RDS or Aurora, Azure Database, Google Cloud SQL, a managed provider, or plain Postgres you run yourself. Managed identity is supported where the cloud offers it, so the credential can be an IAM role rather than a password.
Amazon S3 and every S3-compatible store, Azure Blob Storage, or Google Cloud Storage. One endpoint setting points the same implementation at a self-hosted store.
Your relay or your cloud: SMTP for Microsoft 365, Google Workspace or a corporate relay, or the native senders for Amazon SES, Microsoft Graph, Azure Communication Services and Gmail.
Sentry, Datadog, or any OpenTelemetry-compatible backend, which covers Honeycomb, Grafana, New Relic and a collector you run yourself. Personal data is stripped in the seam before any provider sees it.
Any Docker or OCI host, and any scheduler that can make an authenticated request on a timer. Nothing here is a hosted tenant and nothing runs on our infrastructure.
Days, not a quarter. The software is the fast part. The configuration is the part worth slowing down for, because it is where your organization decides what an agent is allowed to do before one ever does it.
Probation is the default state of a new instance, not an option you have to ask for. It holds the merge, so you watch its decisions before it acts on its own, and it keeps doing that until you graduate it.
SpeyAI is built to run on the stack a customer already has. Version control is GitHub, GitLab, Bitbucket or Azure DevOps, including self-managed instances. The database is your own Postgres, whether that is Amazon RDS or Aurora, Azure Database, Google Cloud SQL or one you run yourself. Storage is S3 and S3-compatible stores, Azure Blob or Google Cloud Storage. Error monitoring is Sentry, Datadog or any OpenTelemetry backend. Each of those is a setting rather than a code change, which is the point: nothing in the product is coupled to one customer stack.
Yes. A SpeyAI deployment reaches Claude through the account you already hold: Anthropic directly, AWS Bedrock, Microsoft Foundry or Google Vertex. The model spend appears on a bill you already receive, in the region you already chose, under the agreement you already signed with that provider. Cost accounting inside SpeyAI is identical whichever transport you pick.
SpeyAI runs on Claude, across all four model transports, and only on models that have been certified. Certification means a model has passed the same volume batch at the same quality threshold as everything else in production use. Transports for other model families exist in the codebase, but uncertified means unavailable rather than unsupported-but-working: there is deliberately no run mode that quietly puts your work through a model that has not been tested. A model becomes available when it has earned it.
A coding assistant makes one engineer faster while they drive. SpeyAI is for work no individual is driving: someone describes an outcome, the organization executes it, and a person approves what ships. They solve different problems and they coexist. The distinction that matters commercially is accountability. An assistant leaves the human in the loop by construction, because the human is typing. Once an agent works end to end, the loop has to be rebuilt deliberately, and that is what a governance layer is.
Standing up a SpeyAI instance takes days rather than weeks once the configuration is agreed, because it is containers running against your own database rather than a migration project. The longer part is the configuration itself: deciding which paths are untouchable, what the spend ceilings are, and who approves what. That work is a conversation with your security and engineering owners, and it is worth doing properly rather than quickly.
A new SpeyAI instance spends its first weeks in probation, which is its default state. The organization runs the full pipeline, produces full decision records and a complete audit trail, and holds every merge for a human. You watch its decisions before it acts on its own, and it keeps doing that until you graduate it. Graduation is a person clicking once, never a timer and never an automatic promotion. After graduation a documentation-only change can merge by itself when every required gate is green, and code still goes to a person unless the operator opens the small-change window.
A SpeyAI instance is operated by one person, part-time, and in practice a technical lead rather than a new hire. Their job is ratifying briefs before work starts and clearing the queue of decisions that need a human. The console is built so that everything requiring a person appears in one place with the action attached to it, rather than as a notification that sends you somewhere else to act.
Yes. A SpeyAI instance is pointed at a repository, and starting with one is the sensible way to begin. Start with one that matters enough to be a real test of the work and the gates, and not so much that the first weeks are tense. Monorepos are supported through a project map: a path prefix selects the directory, and the install, typecheck and test commands run there.
No. SpeyAI is not offered as a hosted service, and that is a position rather than a gap. There is no hosted tenant and no data custody. The software runs on your infrastructure, against your database, on your model account, so your code and your data stay inside your environment. A partner can stand it up and manage it for you within your own environment, which is a different thing from us holding it.
Nothing happens, because the licence check is not in the path of your operations. Your SpeyAI instance verifies its licence offline against a key compiled into the build, so our availability is never in the path of your operations. The connection home is outbound-only, initiated by you, and carries a deployment identifier, a version and a health summary. It never carries code, findings or repository content. A licence server that could stop a customer organization would contradict the entire product, so it was designed so that it cannot.
Yes. In SpeyAI an ordered chain of approvers can be configured for the gates that require a human, with approvers named by role rather than by person so the configuration survives your org chart changing. It ships empty, because a control that changes who has to sign should be switched on deliberately by your operator rather than arriving switched on.
SpeyAI configuration is layered: a base library we ship, an optional industry or partner layer, and your own instance layer on top. An update replaces the base without touching what you changed. That layering is a structural requirement rather than a convenience, because without it every release becomes a services project.
A briefing walks your governance requirements, your stack, and what a governed organization would run and where.