We are experiencing a recurring issue with version control cloud syncing when using Azure DevOps.
Initially, the setup works correctly for a few days. However, after some time, the application suddenly shows the cloud syncing flag/error and version control effectively breaks. Once this happens, syncing is no longer possible.
We attempted to resolve this by:
Removing the existing version control setup
Reconfiguring everything from scratch
Reconnecting the Anvil app to Azure DevOps
Unfortunately, even after a full re-setup, the same cloud syncing flag appears again.
For context, we have extensive experience using GitHub-based workflows and have never encountered a similar persistent issue there. However, as an organization, we are required to use Azure DevOps, so switching providers is not an option for us.
Could you please help us understand:
What specifically triggers this cloud syncing flag?
Whether this is a known issue with Azure DevOps integrations
If there are any stability limitations, configuration requirements, or recommended practices we should follow to prevent this from happening again
At the moment, this behavior makes version control unreliable for our workflow, which is a serious concern for us.
That error icon appears when Anvil experiences an error connecting to the the remote Git server (for example, wrong/expired credentials, server doesn’t respond, etc) or fails to push/pull the relevant branch. Usually there is a little more information supplied with the error - if you open the “Manage Git Remotes” dialog you should see error messages next to all the branches that failed to sync.
To provide a bit more detail, then, I’d want to know:
How are you authenticating to Azure DevOps? Unlike GitHub, Anvil doesn’t have a native integration for Azure DevOps, so it only supports standard Git authentication and requires manual syncing to pick up changes from remote repositories. (This should work just fine; we just don’t have the same bells and whistles as when talking to GitHub.) What sort of auth/passwords/tokens are you using? Are you using HTTP or SSH to access your repository?
What error message is shown when syncing fails? (see above)
When you say “Unfortunately, even after a full re-setup, the same cloud syncing flag appears again”, does that mean that the error reappears instantly, or that the actions you list here work but only for a few days, or something else? Does this
When you say “reconfiguring everything from scratch”, what do you mean? What are you reconfiguring? (I think this may be similar to my previous questions asking for more details about your configuration)
We’re not specifically aware of any known issues with Azure DevOps, which ought to work like any other Git repository once appropriate credentials are provided. Hopefully your answers here will help narrow it down!
Thanks for the detailed response — happy to clarify further below.
Authentication / setup
We are authenticating via HTTP, using Manage Git Remotes.
The remote is added manually by providing the repository URL along with username & password credentials.
We are not using SSH or any Anvil-native integration (since Azure DevOps is not supported natively), only standard Git authentication.
Error details
The only visible indication of failure is in Manage Git Remotes, where all branches show a warning icon with the message “out of sync”.
There is no additional or more specific error message shown per branch beyond that.
The cloud syncing icon appears at the same time.
Behavior over time
Historically, removing the Git remote and setting it up again from scratch would resolve the issue temporarily.
After re-adding the remote, syncing would work normally for a few days.
Recently, however, after deleting and re-adding the Git remote, the out-of-sync warning and cloud sync flag appear immediately, without any successful sync occurring in between.
What we mean by “reconfiguring from scratch”
Deleting the existing Git remote from Anvil
Re-adding the remote via URL
Re-entering credentials
Re-attempting sync on the existing branches
This used to act as a workaround, but no longer does.
At this point, credentials appear to be accepted (no explicit authentication failure), but syncing never completes successfully, and all branches remain out of sync.
and version control effectively breaks. Once this happens, syncing is no longer possible.