> ## Documentation Index
> Fetch the complete documentation index at: https://antideploy.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy from GitHub

> Connect a repository and every push to its default branch redeploys automatically.

Connecting a repository is the way to ship continuously. Once it is linked,
every push to the default branch builds and releases without you doing
anything.

## Before you start

* An Antideploy account.
* A GitHub account with access to the repository.
* Permission to install a GitHub App on the account or organisation that owns
  it. On an organisation you usually need to be an owner, or have an owner
  approve the request.

## Connect a repository

<Steps>
  <Step title="Start a new application">
    Click **New application** in the dashboard and choose GitHub.
  </Step>

  <Step title="Install the Antideploy GitHub App">
    You are sent to GitHub to install it. Grant access to **selected
    repositories** rather than all of them unless you have a reason not to; you
    can add more later without reinstalling.
  </Step>

  <Step title="Pick the repository">
    Back in Antideploy, choose the repository from the list.
  </Step>

  <Step title="Review the analysis">
    Antideploy reads the repository and shows what it found: runtime, framework,
    install and build commands, start command, port, and any database, each
    with the evidence behind it.

    Read the warnings and hazards before deploying, not after.
  </Step>

  <Step title="Deploy">
    Click deploy. You get an HTTPS URL when it finishes.
  </Step>
</Steps>

## Auto-deploy on push

Every push to the repository's **default branch** triggers a deployment.
Antideploy fetches that commit, builds it, and releases it when the build
succeeds.

If a build fails, the previous version keeps serving and you get an email with
the reason. A failed push never takes your app down.

<Note>
  The branch is the repository's default branch, as GitHub reports it. It is not
  selectable, and pushes to other branches are ignored. There are no per-branch
  or pull-request deployments.
</Note>

## Repositories holding more than one project

If the repository contains several projects (a frontend and a backend, or a
folder of services), Antideploy will say so, and list the directories that look
like projects in their own right.

Pick the one to deploy and it is built as though that directory were the whole
repository: its manifest, its dependencies, its start command.

<Warning>
  One application deploys one directory. To run a frontend and an API, create
  two applications from the same repository and point each at its own directory.

  If nothing at the repository root is buildable, Antideploy will not offer a
  Deploy button until you have chosen a directory: the build could only fail.
</Warning>

## Build configuration

There is none to fill in. Install, build and start commands are worked out from
your code and shown to you before you deploy; they are not editable fields.

The one thing you choose is the **directory** to build, described above.

If the detected commands are wrong for your project, the ways to correct them
are the ones your ecosystem already has: a `Procfile` with a `web:` line, or a
Dockerfile at the root of the directory being built.

## Changing repository access

To add or remove repositories later, go to GitHub → **Settings** →
**Applications** → **Antideploy** → **Configure**. Changes take effect
immediately.

Removing the app's access to a repository stops future auto-deploys. Anything
already deployed keeps running until you delete the application.

<Card title="Deployments and rollback" icon="clock-rotate-left" href="/docs/operations/deployments">
  Release history and restoring a previous version.
</Card>