Deploying from a git repository

Git deploys are included on Pro and above. They are the cleanest way to work, because the repository is the single record of what is live.

Connecting a repository

1. Open the site or app in your panel.
2. Choose Connect repository.
3. Authorise access to your git provider and pick the repository.
4. Choose the branch that represents production, usually main.
5. Set a build command, if your project needs one, and a start command if it is an app.
6. Save.

From then on, every push to that branch deploys. We fetch the code, run the build, and swap the new version in.

Deploying manually

You can trigger a deploy from the panel at any time without pushing, which is useful after changing an environment variable.

Rolling back

If a deploy goes wrong, roll back to the previous one from the panel. It is far faster than trying to fix forward under pressure.

Using staging with git

A good workflow, on Pro and above:

1. Connect a staging branch to your staging environment.
2. Push your work to staging.
3. Test it on the staging address.
4. Merge into main, which deploys to production.

Secrets

Environment variables belong in the panel, not in the repository. If a secret has ever been committed, treat it as compromised and rotate it, even in a private repository.

What deploys and what does not

The repository controls your code. It does not control your database or your uploaded files. That matters most on WordPress, where content and media live outside the repository. Deploying does not overwrite your database or your uploads.

When a deploy fails

The build log in the panel tells you why, and it is nearly always one of:

• A dependency that installs on your machine but is not in your lock file
• A build step that needs an environment variable you have not set here
• A build that runs out of memory, which means your plan's memory is the constraint

The previous version keeps serving while a failed deploy is investigated. A failed build does not take your site down.