Connect the repository you intend to ship
Use build.host’s supported GitHub connection to make the intended repository available to your account. For a private repository, confirm that the integration has access to that repository before starting a deployment. Keep the organization and branch explicit when several projects have similar names.
The project should include its build configuration and lockfile where applicable. Check that the local build works and identify required environment variables before publishing. A repository URL alone does not tell the agent which production configuration is appropriate.
Make updates traceable
Commit the changes you want deployed, then ask the agent to update the existing build.host project. Confirm the deployed revision and test the live application. Keeping one stable project avoids a series of duplicate addresses for the same product.
Auto-deploy on push is configured per project. Until it is enabled, use an explicit deployment request. A successful push to GitHub should not be presented as proof that the hosted app has updated.
Use history to recover with context
When a release regresses, compare the change with the last working deployment and inspect the relevant logs. Rollback restores an available earlier deployment; it does not undo data or configuration changes in an external database.
Once the immediate problem is resolved, commit the correction to the repository as well. Otherwise a later deployment can publish the same broken source again. The repository and the live release should tell a consistent story.