Automatic Deployments
Guara Cloud can automatically start a deploy every time you push to your configured GitHub branch. This means your code goes to production without any manual action.
How it works
The automatic deploy flow follows these steps:
- You push to the configured branch (for example,
main) - GitHub notifies Guara Cloud via webhook
- Guara Cloud validates the push and checks for relevant changes
- A new build starts automatically
- When the build finishes, the new version is deployed
The entire process happens in the background. You can track progress in the Deployments tab of your service.
Configuring the deploy branch
When you connect a GitHub repository to your service, you choose the branch that triggers automatic deployments. Only pushes to that branch start a new deployment.
To change the deploy branch:
- Go to the service page in the dashboard
- Navigate to the Source section
- Change the deploy branch to the desired branch
- Save the settings
Path filtering (monorepos)
If you use a monorepo, Guara Cloud offers path filtering. With this feature, a deploy is only triggered when files within the configured service directory are changed.
For example, if the service root directory is /apps/api:
| Changed file | Triggers deploy? | Reason |
|---|---|---|
apps/api/src/main.ts | Yes | Inside apps/api |
apps/api/package.json | Yes | Inside apps/api |
apps/web/src/page.tsx | No | Different directory |
README.md | No | Root-level file |
To configure the root directory, go to the service settings and set the Root Directory field.
Disabling automatic deployments
You can disable automatic deployments without disconnecting the repository:
- Go to the service page in the dashboard
- In the Source section, disable the Automatic deploy option
- Confirm the change
With automatic deploy disabled, pushes to GitHub will not start new deployments. You can still trigger deploys manually at any time.
Superseded deployments
If you push again while a build is still in progress, the previous build is automatically cancelled and a new build starts with the latest code. The cancelled deployment gets the status Superseded in the history.
This prevents deploying intermediate versions and ensures only the most recent code is deployed.