Quick start

Open Sign in and choose Continue with GitHub, or enter your email address to get a sign-in link. A sign-in link works once and expires after 15 minutes. It opens a page with a Sign in button, so a mail scanner that opens the link does not use it up.

The first sign-in creates your account and a workspace of its own, and you are its owner. A workspace holds everything else: connections, the map, deploys, incidents, approvals, and members. You can create more workspaces later and switch between them.

A GitHub sign-in and an email link to the same verified address reach the same account, so you can use either one later.

Open Connections. Each card says what Groundcrew will be able to see and do before you add anything. Only workspace owners add, change, or remove connections.

1. AWS

   Create one read-only IAM role from Groundcrew's CloudFormation template. Only Groundcrew can assume it, and only with your workspace's ExternalId. No AWS keys are stored. Connect AWS.

2. GitHub

   Install the Groundcrew GitHub App on the repositories you choose. Groundcrew reads them to see how your apps are built and deployed, builds them for deploys, and opens fix pull requests. Connect GitHub.

3. Vercel or Kubernetes

   Paste a Vercel team token, or a kubeconfig for a read-only service account. Connect Vercel, Connect Kubernetes.

Choose Run discovery at the top of the Connections page. Groundcrew reads every connection in parallel and streams what it finds. When it is done, open Map: your resources grouped by provider, with lines for how they connect, such as a service that reads a database, uses a secret, or is deployed by a workflow in a linked repository.

Scout, the agent that reads your system, writes a short summary of what it found at the top of the map. Use Refresh on a single connection when only that one changed. How discovery works.

With GitHub connected and a deploy target (a Kubernetes cluster, or an AWS account with deploys turned on), open Deploy. Pick a repository and a branch, tag, or commit, pick the target, and add env vars if the app needs them.

Groundcrew reads the repository, writes or uses its Dockerfile, builds and smoke-tests the image in an isolated sandbox, and shows you the plan: every resource it will create, with secret values masked. Nothing leaves the sandbox until you choose Approve and deploy. Then it deploys, checks the app answers, and shows the live URL. Deploys in detail.

The incident watcher checks linked services, databases, functions, and workloads every minute. When a signal goes bad, such as a failing health check, tasks stopping, or an error spike in the logs, it opens an incident and Medic starts investigating. You can also open one yourself with Report incident on the Incidents page.

Medic gathers logs, metrics, and recent changes, finds the root cause with each claim linked to its evidence, and proposes fixes: a pull request, and when production is down, an emergency action such as a rollback. Each one waits for your approval. Incidents and fixes.

In Settings, Members, add people by email address or GitHub login, as an owner, an approver, or a viewer. New members are viewers unless you pick another role. Members and roles.

In Settings, Notifications, add a Slack channel or choose who gets email when an incident opens, waits for an approval, resolves, or fails. Notifications.

• Read the security model: what each role and connection can do, and how to remove access.
• See the limits each workspace has, and set a lower daily model spend cap if you want one.
• Running Groundcrew on your own server instead? The repository's docs/self-hosting.md covers the settings an operator needs.