Announcing Bitbucket support for Sites and Functions_
Appwrite now deploys from Bitbucket. Connect a workspace, pick a repository, and every push builds a Site or Function, with links that resolve to Bitbucket.
Plenty of teams never chose Bitbucket so much as inherited it. The company runs Jira, the repositories came with the Atlassian license, and moving several hundred repositories to a different host to satisfy a deployment platform is not a project anyone wants to staff.
Today, we are announcing Bitbucket support for Appwrite Sites and Functions, which puts all three of the most widely used Git hosts on equal footing.
Connect a Bitbucket workspace, pick a repository, and pushes build and deploy exactly as they do on GitHub.
What ships today
- Bitbucket as a connect option everywhere Git appears. Project settings, the Site creation wizard, and the Function creation wizard all offer it.
- Workspaces as owners. Every workspace your account can reach shows up as a selectable owner in the repository picker.
- Push to deploy. Production branch pushes build and activate. Other branches build and get a preview link.
- Links that resolve to Bitbucket. Commits, branches, and pull requests link to
bitbucket.orgusing Bitbucket's URL shapes. - Commit statuses and pull request comments. Every commit gets a status on Bitbucket that turns green or red with the Appwrite build. Pull requests get a comment listing every preview the push triggered, with build status, logs, the preview URL, and a QR code.
Connecting a Bitbucket workspace
Open a Site or Function, go to Settings > Version control (Git), choose Connect Bitbucket, and approve the OAuth consent screen. The connection is saved to the project and its repositories become available immediately. You can also connect from Project settings > Git configuration, which covers every Site and Function in the project.
If you are creating your first Site or Function and have no Git connection yet, the wizard's empty state lists the providers your server supports, so you can connect Bitbucket and pick a repository without a detour into settings.
Bitbucket organizes repositories into workspaces, which fill the same role a GitHub organization or a GitLab group does. Each workspace you have access to appears as its own row in the repository picker, sitting next to owners from any other provider you have connected. Picking a Bitbucket repository is the same interaction as picking a GitHub one.
Deploying from Bitbucket
The deployment workflow is documented in full under Deploy from Git, and it does not change per provider.
- Check out the branch you configured as the production branch.
- Commit and push.
- Appwrite creates a deployment, builds it, and activates it.
Pushes to a non-production branch build without activating and produce a preview link restricted to members of your Appwrite organization, which is the useful thing to paste into a pull request for review.
You will rarely need to paste it, though. Appwrite reports a commit status for every push, green when the build passes and red when it fails, and posts a comment on the pull request listing every preview the push triggered, across Sites, Functions, and any other Appwrite project connected to the same repository. Each entry shows the deployment status and links to the build logs and the preview URL, with a QR code for opening the preview on a phone.
Build triggers work the same way too. Branch filters limit which branches deploy automatically, and path filters limit which file changes count.
mainstagingpreview/**Bitbucket URLs, not GitHub URLs with the host swapped
Every Git host disagrees about how to address a commit, a branch, and a pull request. Bitbucket puts commits under /commits/, browses a branch under /src/<branch>, and calls a pull request a pull request but serves it from /pull-requests/<id> rather than GitHub's /pull/<id>.
Appwrite builds each of those links per provider. A deployment created from a Bitbucket push links to the Bitbucket commit, the Bitbucket branch, and the Bitbucket pull request that triggered it. Where the provider behind a repository cannot be determined, the Console leaves the control unlinked rather than guessing, because a plausible-looking link to the wrong host is worse than no link.
Repositories are recognized both by the provider recorded on the deployment and by the repository URL itself, so repositories connected before this release, or imported with a URL rather than a provider field, still resolve correctly.
When Bitbucket support is the right call
The clearest case is the one where Bitbucket is already where your code is, and the cost of moving is the only reason you have been deploying by script. Teams on Atlassian tooling generally have their issues, their branches, and their review history tied together, and untangling that to satisfy a hosting platform trades a small convenience for a large migration.
It is also worth reaching for when your repositories are split. Acquisitions leave companies with Bitbucket in one business unit and GitHub in another, and an Appwrite project can hold connections to both at once. Sites and Functions in the same project can deploy from different providers, so the two halves of the org do not need to agree on a host before either can ship.
Where your repositories are hosted is no longer a question you have to answer before Appwrite can build them.
Getting started with Bitbucket on Appwrite
Open a Site or Function, go to Settings > Version control (Git), and connect Bitbucket. Or start a new one on Appwrite Cloud and choose Bitbucket in the creation wizard.
- Deploy Sites from Git covers build triggers, filters, and build configuration.
- Deploy Functions from Git covers the same for serverless functions.
- Preview deployments explains branch deployments and who can open their links.
