[Support Guide] How can I disable automatic git deploys?

[laura]

Last reviewed by Netlify Support staff: December 2024

Sometimes your projects may really benefit from automatic deploys, sometimes they won’t. For such sites, you can create them entirely as manual deploys or using Netlify’s CLI. If you want to turn off automatic deploys from git for a site that was linked with a repository, there are four easy options outlined here. You can choose the option that works best with your workflow.

1. We have a feature called Locked Deploys that you can use to 'pin' a deploy on your production URL.

   To turn on the lock feature from your Deploys page, click the Stop auto publishing button.

That’s it! Netlify will no longer autopublish any deploys at your production URL.

However, deploys will still be built and will be available for you to preview and manually publish whenever you want. You can still see all of your deploys as usual on your Deploys page in our UI.

When you are ready to resume automatic deploys, just click the Start auto publishing button.

2. If you no longer want to trigger deploys via git, you can remove the webhook created by Netlify from your repository's webhook settings at your git provider. This is the way all GitLab and BitBucket repos are configured, and some legacy GitHub sites as well. And as long as you don't remove our deploy key, you can then trigger a deploy some other way - for instance, by pushing the “Trigger deploy” button on the Deploys page in our UI, or via Build Hooks or via our API. Note that folks using the GitHub app won’t have this option!

   No deploy previews for pull requests are created when you deploy this way, FYI.

3. Use GitHub checks to stop automatic deploys under certain conditions using the protected branches feature. This last option is what we use internally at Netlify. We set it up this way so we have a successful build, all of our tests finish, and we have a deploy preview to look at before merging. So if a check fails, you’ll see a red x and your site will not merge & deploy:

If you’ve never used GitHub checks before, GitHub has easy, step-by-step instructions on how to set them up.

Note: If you want to keep your Netlify site but permanently remove the link from your site to your git repo, you can do so from the UI by visiting Site settings > Build & deploy > Repository . Then click ‘Manage repository’ and select unlink repositories name.

There is an API endpoint to unlink the repo from the site, however. This means it is possible to unlink repos using the API without contacting the support team if you want to do it yourself. The Netlify CLI tool is a great way to call the API and it can be done using this below:

netlify api unlinkSiteRepo  --data '{ "site_id": "<site API ID goes here>" }'

Note, the angle brackets should not be included. Here is a real world example (without angle brackets):

netlify api unlinkSiteRepo  --data '{ "site_id": "1a997e22-11b7-44b7-945b-c062ef03c8bf" }'

[devm33]

Hey, it looks like option 2 is no longer possible for GitHub since Netlify moved to using a GitHub App instead of webhooks. Removing the the GitHub App would apply to all of a user’s GitHub repos integrated with Netlify.

Is there any update on removing the link to a repo from a site?

[Und3Rdo9]

I didn’t see the option I needed, so I decided to post my solution here in case somebody has a similar use-case.

I’m using a monorepo which currently contains two Netlify sites that need to be built & deployed if there is any change in the respective package. I want to let my CI decide which Netlify site to deploy, so I don’t want to enable automatic deploys from master. However I do want to keep the deploy previews from Pull Requests to master.

Option 1 in the original post doesn’t really work for me because it might build a site when it is not necessary and won’t publish my site if I trigger a build in CI. Option 2 does work completely either because the webhook is also responsible for reading pull requests.
However, you can customise the permissions of the webhook, and remove the " Pushes: Git push to a repository." permission to disable automatic master deploys, but keep pull requests builds and previews.

I’m not sure if this is the correct/best way to handle my case, so please let me know if you have any suggestions.

[cdierkens]

Hey, it looks like option 2 is no longer possible for GitHub since Netlify moved to using a GitHub App instead of webhooks. Removing the the GitHub App would apply to all of a user’s GitHub repos integrated with Netlify.

Is there any update on removing the link to a repo from a site?

I’m looking for an answer to this question as well.

[luke]

Sure, @root. Both @devotox and I did answer this question. I’ll be happy to go into more detail though.

We are unlinking sites here so that people can still use manual deploys but stop deploys from occurring when a git push to the upstream repo happens.

So, if you want start deploying again for the git push events, just re-link the repo again (or a different repo if that is want you want to do). That is done at Site Name > Settings > Build & deploy > Build settings, then click “Link site to Git”.

I said the button was labeled “Edit settings” earlier but I was wrong. When no repo is linked it is labeled “Link site to Git”. Here is a screenshot to clarify:

I’m also not sure if you could instead be asking, “How to I enable auto-publishing again if I’ve locked deploys?”

If that is the question, the answer can be found at the link below:

Manage deploys

Please do let us know if there are other questions.

[brianjychan]

Does the unlinking + manual deploys method still allow Build Hooks to work? I want to only publish after a certain step of my CI (deploying new serverless functions) passes. I really wish there was an easier solution, but it seems that stopping auto publishing also disables Build Hooks, and then the build won’t automatically run

Currently I’m considering:

1. stopping auto-publishing, but continuing auto builds
2. From my CI environment, use env variables to parse what github commit hash is building
3. If the branch is master, use the netlify CLI / API to contact the netlify GET /api/v1/sites/:site_id/deploys API to find the commit_ref that matches
4. Use POST /api/v1/sites/:site_id/deploys/:deploy_id/restore to effective ‘restore’ aka publish that desired commit

Will this work? Does anyone know a better way?

I wish there was an analogous feature to Build Hooks that was essentially a Publish Hook (make a POST request to a URL to publish a build, while specifying parameters to specify which build)

[luke]

Hi, @brianjychan, if you are doing a build in some CI system you can skip building at Netlify and directly deploy the locally built site to Netlify from the CI system itself.

This is done using manual deploys and the Netlify CLI tool:

Get started with Netlify CLI

To summarize, you can install Netlify CLI as a build dependency in the CI system and when the checks pass you can the CI script/system then executes netlify deploy --prod for the the “publish directory” (as we call it at Netlify). If this is done you will know the version deployed exactly matches you CI build because it is the version from the CI build.

Would that solution meet your requirements?

[chrisworman-pela]

Still seeing the Netlify check when opening a PR against the pelacase/pelacase-web repo in github. Is there something else that I need to do to remove this?

[jen]

Hey @chrisworman-pela,
Is this a protected branch? If so, you may have to remove the check on the GitHub side. Even though these instructions are for enabling instead of disabling status checks, they will take you to the right place in GitHub where you should be able to remove netlify/pelacase/deploy-preview:

Managing a branch protection rule - GitHub Docs

Let us know if that works for you!

[bigwoof91]

@bigwoof91

Same as Sstoney200 I want to disable automatic builds & deploys when a branch is merged to master, and allow CI to call a webhook to trigger a build/deploy for the netlify site. Do I need to just request for github to be unlinked from the netlify site?

If no, then please provide the recommended way to do this

Maybe this helps someone Instead of unlinking my Github repo (i.e. asking about that in my comment above), I ended up just doing:

// netlify.toml
[build]
  ignore = "/bin/true"

And calling a webhook from CI.

This isn’t ideal because although all automatic builds are cancelled (triggered as a result of a merge to master, in my case)…

1. We can no longer manually deploy from the Netlify Site UI
2. the build log is still cluttered w/ “cancelled” builds
3. it’s also a misleading workaround which is unintuitive for my fellow engineers to follow and/or duplicate in other projects.

This leads me to really want a clean way to configure “Active Builds” without automatically building&deploying. I’m sure something like this is in the works, but wanted to just post this for posterity and the Netlify team’s visibility…

[bhagaban]

Please remove the Gitlab association for the following API key

4f91d854-1b29-4779-bc8f-9267d5f8f3ce

[luke]

Hi, @bhagaban. The workflow being repeated in this topic is unlinking repositories from sites. For this workflow, we need the site API id, not the API key.

There are no sites with the API id you listed. You can find the API id under “Site Name” > Settings > General > Site information.

If you send us that id, we can unlink the repo. Note, this can also be done using the API. The Netlify CLI tool makes calling the API easier and it can be done like so:

netlify api unlinkSiteRepo  --data '{ "site_id": "1a997e22-11b7-44b7-945b-c062ef03c8bf" }'

You would need to replace 1a997e22-11b7-44b7-945b-c062ef03c8bf in the command above with the actual API id as found under “Site Name” > Settings > General > Site information. If you use Netlify CLI you can unlink the repo without the support team’s assistance.

If you would prefer for us to unlink the repo, again, please let us know the API id (not the key) and we will unlink it.

[zehawki]

Hello Netlify folks - this is something I’d also like, but there’s got to be a better way than this round about method of manually unlinking. Surely it would be simple to have the GUI set to “stop builds”, and still allow a specific webhook / API call to trigger. Eg a query param ?force_build=true (from Build hooks | Netlify Docs).

This would allow us to self manage this stuff.

[perry]

Hello, somehow this flew a bit under the radar but we released the functionality to self-unlink via the UI in late February of this year. You can now take care of things yourself via this URL:

https://app.netlify.com/sites/[YOUR SITE NAME]/settings/deploys under manage repository:

[carlos.hernandez]

Hello, I stumbled upon this thread as I was trying to block automatic deploys to both my production and staging branches until CI passes but I don’t want to block Deploy Previews.
My approach was similar to option 2, stop auto publishing and triggering a deploy with either a hook or the CLI from my CI pipeline but both seem to fail because of the lock; using the CI give a prompt to unlock deployments but I’m unable to respond to it in a CI context.

Any suggestions on how this could be accomplished?

[hrishikesh]

Unless you’re deploying using netlify deploy --prod this should work fine. --prod is for production deploys.

[carlos.hernandez]

This was done with a --prod flag, that’s what I want to deploy via the CLI or API only after the CI passes

[luke]

One solution would be to use the CLI in the following way. If all CI tests pass:

1. The CLI is used to make an API call to enable auto-publishing.
2. The manual deploy is made using netlify deploy --prod.
3. The CLI is used to make an API call to disable auto-publishing again.

Would that solution work for you? If so, please let us know and we’ll send examples of how to use the CLI to make these changes (steps 1 and 3 above).

[carlos.hernandez]

I tried that approach but to lock/un-lock deploys via de API, I needed to either save the previous deploy id or find it every time since the endpoint requests it.
We ended up disabling builds completely and building on the CI to then deploy with the CLI with a mix of --prod and --alias flags based on the different cases