Frequently asked questions

A DevOps team made of AI agents, for teams without a dedicated DevOps engineer. It connects to the infrastructure you already run on AWS, Kubernetes, Vercel, and GitHub, maps it, deploys apps from your repositories, and investigates and fixes incidents. Every change waits for an approval from your team.

Small teams and agencies running apps across one or more clouds, who want deploys and incident response handled with the same care a DevOps engineer would take, without giving an automated tool free rein.

No. Groundcrew works with your existing tools. Fixes arrive as pull requests on your repositories, so your reviews, checks, and deploy workflows still run. It reads your Terraform and workflows to understand your system; it does not take them over.

Yes. Every connection starts read-only. You get the map, incident detection, and Medic's root cause analysis with fix pull requests. Deploys and emergency fixes are separate switches you can leave off.

No. You create an IAM role that only Groundcrew can assume, and only with your workspace's ExternalId. Groundcrew stores the role ARN, the ExternalId, and the account ID. Sessions last at most an hour. Connect AWS.

No. The AWS role has an explicit deny on reading secret values, SSM parameters, KMS decryption, and S3 objects. The Kubernetes account cannot read Secrets. Vercel values are not kept, with one narrow exception described in the Vercel guide. Groundcrew reads configuration, metadata, logs, and metrics, never rows in your databases or objects in your buckets.

No. Agents read freely, but every write is a plan that an owner or approver approves, tied to that exact plan and usable once. Approvals.

Never. It opens pull requests on new groundcrew/fix-* branches. Merging is up to you. We recommend branch protection with a required review on your default branch.

An emergency action checks the current state again just before it writes. If it no longer matches the plan you approved, nothing is written and the fix is marked failed with the reason.

In an isolated sandbox on Groundcrew's servers: a rootless container engine with every container in gVisor, no route to private networks or cloud metadata, and fixed memory and CPU. Everything is deleted when the run ends. Isolated builds.

Delete the connection in Groundcrew, then remove the access in your account: delete the CloudFormation stack, uninstall the GitHub App, delete the Vercel token, or delete the Kubernetes service account. Delete data.

• Scout reads repositories and the map, and summarizes your system.
• Builder writes and fixes Dockerfiles and builds in the sandbox, up to 5 attempts.
• Deployer plans, deploys after approval, and verifies.
• Medic investigates incidents, finds the root cause, and proposes fixes.

NVIDIA Nemotron models through Nebius Token Factory: Nano for Scout, Super for Builder and Deployer, and Ultra for Medic's root cause and fix proposals. Each run shows the model, tokens, and cost of every call.

No. See the Privacy Policy for what is sent to the model provider and why.

Every claim in a root cause links to the evidence lines it rests on, and claims without real evidence are dropped. You review the diagnosis and the fix before approving. After a fix, Medic checks the signals again, and the incident only resolves when they are healthy.

The incident watcher checks linked resources every minute. Most rules look at the last 5 minutes, so an outage is usually noticed within a few minutes. What it checks.

AWS, GitHub, Vercel, and Kubernetes. Azure is in preview: a service principal with Reader on one resource group. Direct VM connections are not available yet.

Each AWS connection has its own list of up to 10 regions to discover, watch, and act in. An owner changes it with Regions on the connection. AWS regions.

Not yet. Groundcrew reaches clusters over the internet, so the API server needs a public address. It also refuses kubeconfigs with exec plugins or auth providers; use a service account token. Connect Kubernetes.

With GitHub, or with a sign-in link sent to your email address. Both reach the same account when the address is the same and verified.

To know which of your addresses GitHub verified at sign-in, so invitations and accounts with the same address are matched to you.

Yes. The repository has a self-hosting guide that covers the platform identity, the GitHub App, email, sign-in, limits, and every required setting.