How Argo CD reads Bitbucket repositories for GitOps delivery
If your team keeps Kubernetes manifests in Bitbucket and wants Argo CD to deploy from them, Argo CD pulls from Bitbucket using repository credentials stored as Kubernetes Secrets, with webhooks and pull request generators layered on top. The pull itself is the part you must get right before anything else: the Application's repoURL, the target revision and a read-only credential that the repo-server can use. Webhooks only shorten the time between a commit and a sync, and pull request generators only matter if you want preview environments created from open pull requests. Start by proving that a plain pull works from the Argo CD namespace, then add the rest.
Bitbucket Cloud and Bitbucket Data Center handle webhooks differently, so the two deployments need separate plans. Bitbucket Cloud payloads do not include the list of changed files, so Argo CD makes an API callback, which needs the X-Hook-UUID header and a matching webhook.bitbucket.uuid value. Bitbucket Server, the product line behind Data Center, uses webhook.bitbucketserver.secret instead. Confirm which product you run before you copy any webhook example, because a Cloud setup will not validate against a Data Center endpoint, and the reverse is also true.
The Argo CD version decides where credentials live. Since Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap, repositories must be defined as Kubernetes Secrets, so any older runbook that edits that ConfigMap needs rewriting before an upgrade. Pull request generators also differ by product: the Bitbucket Server and Bitbucket Cloud generators do not support label filters and use branch matching instead, so decide your branch naming convention early. Check the Argo CD version you plan to run against the Argo CD webhook guide and the upgrade notes before you build.
What you need before connecting Bitbucket to Argo CD
Connecting Argo CD to Bitbucket touches the Argo CD version you run, the identity it uses to read repositories, the network path from its components to Bitbucket, and the trust and capacity of the cluster it runs on. Confirm each item in your own environment before you write any repository secret or webhook.
Argo CD version and patch line
Pick a supported 3.x minor version and track its patch releases, because only the three most recent minor versions receive patches. Argo CD 3.0 changed how repositories are stored and how Dex RBAC claims are read, so a 2.x installation needs the upgrade notes reviewed before Bitbucket credentials are moved. Confirm which minor line your platform team will patch and who applies patch releases each cycle.
Bitbucket repository access identity
Decide which identity Argo CD uses to read manifests: a dedicated Bitbucket account or service identity with read-only access to the config repositories, not a personal login. Repository credentials must be defined as Kubernetes Secrets because Argo CD 3.0 removed repository entries from argocd-cm. Confirm with your Bitbucket administrator which workspace, projects and repositories this identity can read, and how its token or password is rotated.
Network reach to Bitbucket
Both the repo-server, which fetches and renders manifests, and the API server, which receives webhook callbacks, need outbound paths to your Bitbucket endpoint. Bitbucket Cloud calls back into Argo CD for changed files, so the Argo CD endpoint must also be reachable from Bitbucket where webhooks are used. Confirm egress rules, proxy settings and any allowlists in your firewall, and test both directions before enabling webhooks.
TLS trust for Data Center endpoints
A self-hosted Bitbucket Data Center endpoint usually runs under an internal certificate authority. The repo-server must trust that chain, or Git fetches fail during TLS verification. Confirm with your security team which CA bundle applies, how it is mounted into Argo CD components, and who renews the certificate. Bitbucket Cloud uses a public certificate, so this item applies only to Data Center.
Cluster sizing for high availability
The high availability manifests need at least three nodes because pod anti-affinity rules spread replicas across them, and IPv6-only clusters are not supported. Confirm your cluster has three or more schedulable nodes in the zones you intend to use, and that node capacity covers the controller, repo-server and Redis replicas you plan. Ask your platform team to verify this before the Bitbucket integration is scheduled.
Configure Bitbucket repository access and webhooks in order
This sequence gives Argo CD read access to a Bitbucket repository, proves it can sync, and then connects change notifications so commits reconcile without waiting for the polling interval. Each step ends with a check you can run before moving on.
Create the repository credential as a Secret
The platform team creates a Kubernetes Secret in the namespace where Argo CD runs, labeled as a repository credential, and stores the Bitbucket access method in it: an access token or app password for HTTPS, or a private SSH key for SSH. Argo CD 3.0 no longer reads repositories from the argocd-cm ConfigMap, so this Secret is the only supported place to define the repository. Confirm which credential type your Bitbucket plan and identity policy allow, and apply the Secret with a least-privilege, read-only scope. The step is complete when the Secret exists in the cluster and its values are not committed to Git.
Register the repository and verify the first sync
Point an Argo CD Application at the Bitbucket repository URL and the path it should deploy, using the credential from the previous step. Sync it once in a test or non-production project so any authentication, path or manifest-rendering problem appears where it is cheap to fix. Check the repository connection status in the Argo CD UI or CLI, then trigger a manual refresh and confirm that Argo CD reads the revision and reports the expected sync state. The step is complete when the refresh succeeds, the reported revision matches the latest commit on the branch, and the application reaches the expected health status.
Decide on the Bitbucket Cloud or Data Center path
Choose the webhook configuration that matches your hosting model before you open the Bitbucket side. Bitbucket Cloud and Bitbucket Data Center use different webhook authentication settings in Argo CD, so the Argo CD instance must be configured for the platform you actually run. Record the owner of the Bitbucket webhook settings and the owner of the Argo CD ConfigMap, because the two changes must be made together. The step is complete when the team has written down which platform the repository lives on and who will apply each half of the configuration.
Set the Bitbucket Cloud webhook UUID
For Bitbucket Cloud, add the webhook UUID to the Argo CD configuration under webhook.bitbucket.uuid, and create a webhook in the repository settings that sends push events to the Argo CD webhook endpoint. Bitbucket Cloud payloads do not list changed files, so Argo CD calls back to the Bitbucket API to find them. That callback is validated against the X-Hook-UUID header that Bitbucket sends, so the UUID in Argo CD must match the one Bitbucket issues for the webhook. Confirm the match by inspecting a recent delivery in the Bitbucket webhook log and comparing its X-Hook-UUID value with the configured one. The step is complete when the value matches and the delivery returns a successful response.
Set the Bitbucket Data Center webhook secret
For Bitbucket Data Center, generate a shared secret, store it in the Argo CD Secret used for webhooks under webhook.bitbucketserver.secret, and enter the same value in the webhook configuration on the Bitbucket Data Center repository. Bitbucket signs each delivery with that secret, and Argo CD rejects deliveries whose signature does not validate. Use a long random value and keep it out of Git, and plan how you will rotate it, since changing it requires updating both sides at the same time. The step is complete when a test push produces a delivery that Bitbucket marks as successful and Argo CD accepts without a signature error in its logs.
Confirm that a commit triggers reconciliation
Make a small, reversible change on the watched branch, such as a label or a comment in a non-production manifest, and push it. Watch the Argo CD application controller and API server logs for the webhook receipt, then confirm the application shows the new revision and moves to OutOfSync or Synced without a manual refresh. Measure how quickly the change appears compared with the normal polling interval in your configuration, so you know whether webhooks are doing their job. The step is complete when the commit appears in Argo CD on the webhook path, and you can show that to the security or change-management reviewer as evidence that the integration works end to end.
How Bitbucket Cloud and Data Center differ for Argo CD
Bitbucket Cloud and Bitbucket Data Center signal changes to Argo CD in different ways, so the webhook setup is not interchangeable between them. Cloud webhook payloads do not include the list of changed files. Argo CD therefore makes an API callback to Bitbucket to find out which files changed, and that callback only works when the incoming request carries the X-Hook-UUID header and the Argo CD configuration holds a matching webhook.bitbucket.uuid. Data Center instead relies on a shared secret stored as webhook.bitbucketserver.secret, which the webhook sender uses to sign requests.
- Cloud identifier: the webhook UUID must match the header value exactly, so a webhook recreated in Bitbucket needs its UUID updated in Argo CD.
- Cloud callback: Argo CD needs outbound access to the Bitbucket Cloud API from the cluster, which matters for segmented networks.
- Data Center secret: the shared secret is a credential, so store it in a Kubernetes Secret and rotate it on a schedule.
- Repository access: both products need repository credentials defined as Kubernetes Secrets, because Argo CD 3.0 removed repository configuration from
argocd-cm. - Verification: push a test commit to a watched path and confirm that the application refreshes without waiting for the polling interval.
Confirm the exact webhook fields and header names against the current Argo CD webhook guide for your Argo CD version before you write any configuration.
Bitbucket Cloud limits how many API calls a client can make, and the Argo CD callback counts against that budget. Atlassian documents 60 requests per hour for anonymous requests and 1,000 requests over a rolling one-hour window for most authenticated resources. Those numbers come from Atlassian's API request limits documentation and are the figures to plan around for Cloud. Data Center is self-managed, so Atlassian's Cloud API limits do not apply in the same way, and capacity there depends on your own server sizing and network design.
- Callback volume: every change notification that triggers a file-list lookup consumes budget, so many repositories pushing often can approach the limit.
- Shared credentials: one service account used by many Argo CD applications shares a single hourly budget.
- Fallback behavior: when requests are throttled, changes can reach Argo CD late, so confirm the polling interval you accept as a fallback.
- Data Center load: plan capacity against your own server and network, and ask Atlassian or your administrators for current figures.
- Monitoring: watch Argo CD logs for failed callbacks and track API responses from Bitbucket during peak pushes.
Before you choose the Cloud pattern, estimate peak push frequency across the repositories Argo CD will watch and compare it with the documented limits.
The pull request generator in an ApplicationSet creates temporary applications for open pull requests, and its filtering behaves differently on each Bitbucket product. For both Bitbucket Server and Bitbucket Cloud, the generator does not support label filters. Instead, you select pull requests by branch matching. That means the filter logic belongs in branch names and target branches, not in labels that a reviewer might add in the interface.
- Same filter on both products: branch matching applies to Bitbucket Cloud and Bitbucket Server alike, so the ApplicationSet template is largely portable between them.
- No label control: teams that expect to deploy a preview only when a reviewer adds a label need a naming convention for branches instead.
- Naming discipline: agree on a branch prefix that the generator matches and document it for developers.
- Credential scope: the generator needs read access to pull requests, so review which service account holds that permission.
- Cleanup: confirm that closed or merged pull requests remove their applications as expected in a test project.
Run the generator against a sample repository with a branch that matches and one that does not, and confirm the result before you connect production repositories.
The procurement question for Data Center depends on dates and licensing, and those facts change how far ahead a team should plan. Atlassian announced on September 8, 2025 that its Data Center products reach end of life on March 28, 2029, and that new Data Center subscriptions end for new customers on March 30, 2026. Atlassian's journey-to-cloud page states that Bitbucket Data Center will not reach end of life and will continue beyond 2029. Existing customers can renew to a Bitbucket Hybrid License while their Data Center environments stay where they are. The two statements describe different things, so read both before you decide.
- New purchases: the announced end date for new Data Center subscriptions has a specific cutoff for new customers, so confirm eligibility with Atlassian early.
- Bitbucket-specific statement: Atlassian says Bitbucket Data Center continues past 2029, which differs from the general product end-of-life announcement.
- Hybrid License: the license lets existing customers keep Data Center while gaining Cloud features such as CI/CD and AI under one license.
- Pricing: Data Center pricing is not published, so ask Atlassian for a written quote that names the license type and term.
- Migration cost: moving to Cloud has its own effort and retention questions, so treat it as a separate project.
Ask Atlassian in writing which license and support terms apply to your organization and which Data Center version you will run.
Mapping Bitbucket identities, webhooks and generator fields to Argo CD
This table pairs each Bitbucket object with the Argo CD field, Secret or RBAC subject that represents it. Read it before you write repository Secrets, webhook config or ApplicationSet generators, because the Cloud and Data Center rows use different identifiers. The main takeaway is that pull request generators match on branches, not labels, so branch naming must be settled first.
| Bitbucket item | Argo CD counterpart | Where it is set and what to confirm |
|---|---|---|
| Repository URL | spec.source.repoURL in Application or template field in ApplicationSet | Use the clone URL for the workspace or project and repository. Confirm the exact path format against your Bitbucket edition. |
| Repository access credential | Repository Secret in the argocd namespace with the repo URL and access fields | Repository definitions live in Kubernetes Secrets since Argo CD 3.0, not in argocd-cm. Confirm the credential type your Bitbucket edition supports. |
| Workspace or project path | Path segments inside repoURL, mirrored in Argo CD project source allow-lists | Restrict each Argo CD project to the repositories and paths its team owns so one team cannot point an application at another team's repo. |
| Bitbucket Cloud webhook UUID | webhook.bitbucket.uuid key in argocd-secret, matched to the X-Hook-UUID header | Cloud webhook payloads omit changed files, so Argo CD calls back to the API. Confirm the UUID value in your Bitbucket webhook settings. |
| Bitbucket Server webhook secret | webhook.bitbucketserver.secret key in argocd-secret | Use a high-entropy value stored outside Git. Confirm that the same value is set on the Bitbucket Data Center webhook. |
| Pull request source branch | Branch-matching field in the Pull Request generator for the feature branch | Label filters are not supported for Bitbucket Cloud or Server pull request generators, so branch naming conventions carry this selection. |
| Pull request target branch | Target branch field used to select which pull requests generate Applications | Decide which target branches should create preview environments. Confirm the field name in the generator reference for your Argo CD version. |
| Argo CD RBAC subject that owns the app | Project role or SSO group mapped to the Application's project | Map the Bitbucket team or group to an SSO group, then to an Argo CD role. Since 3.0, Dex RBAC keys on the federated_claims.user_id claim. |
Securing the Bitbucket connection
Bitbucket gives Argo CD read access to your manifests, and Argo CD gives its repo-server code execution on that content. The controls below limit what a stolen credential, a forged webhook or a hostile branch can do, and each one is a check you can run against your own installation.
Scoped read-only Bitbucket identity
Give Argo CD its own Bitbucket identity with read-only access to the repositories it deploys, rather than a personal login. A personal account carries that person's access to every other workspace and survives their departure. Confirm which repositories the identity can see, whether it can push, and who owns its credential rotation. Review the access list whenever a team adds a new repository to Argo CD.
Credentials only in Secrets
Repository credentials belong in Kubernetes Secrets, and since Argo CD 3.0 repositories cannot be defined in the argocd-cm ConfigMap. Confirm that no app password, token or SSH key appears in a manifest, Helm values file or ApplicationSet template committed to Git. Limit which namespaces and service accounts can read those Secrets, because anyone who can read them can read the Bitbucket credential.
Webhook secrets and UUIDs out of Git
Bitbucket Cloud webhooks need the matching webhook.bitbucket.uuid value, and Bitbucket Server webhooks need webhook.bitbucketserver.secret. Store both in the Argo CD Secret, not in a committed ConfigMap. The Cloud flow also depends on the X-Hook-UUID header, so confirm that requests without a matching value are rejected and that the webhook URL is reachable only from Bitbucket.
Control who changes repositories and ApplicationSets
Whoever can edit an Application or ApplicationSet definition decides what Argo CD deploys and to which cluster. Restrict write access to Argo CD objects through Kubernetes RBAC and Argo CD project boundaries, and review changes to source repositories, destination clusters and generator settings. Pull request generators read branches from Bitbucket, so a contributor who can open a branch with a crafted path may influence what gets deployed.
Repo-server exposure to untrusted branches
The repo-server runs Helm and Kustomize on repository content, so a branch or pull request from an untrusted author can execute tooling and read files outside the intended path. Decide which branches Argo CD may render, keep preview generators limited to trusted contributors, and confirm that out-of-tree file access is restricted. Treat this as the highest-impact risk in the Bitbucket integration.
JWT-only API access and redaction
Argo CD authenticates API requests only with JSON Web Tokens and redacts cluster, Git and OAuth2 credentials from API responses and logs. Your job is to verify that behavior in your own install: test that an unauthenticated call is refused, confirm that a repository credential does not appear in a debug log or API output, and add log retention and access review to the operating plan.
Why webhooks, the changed-files callback and polling need separate checks
Argo CD detects a Bitbucket change through two separate steps, and each one needs its own check after go-live. The first step is the webhook, which tells Argo CD that something happened and should trigger a refresh. The second step is the callback: Bitbucket Cloud webhook payloads do not list the files that changed, so Argo CD calls the Bitbucket API to find them. That call depends on the X-Hook-UUID header arriving with the request and matching the webhook.bitbucket.uuid value in the Argo CD configuration. On Bitbucket Server, the equivalent check is the webhook.bitbucketserver.secret value on both sides. A webhook that arrives successfully can still produce no useful refresh if the callback fails, so a delivery log entry alone does not prove the path works.
Polling is the fallback, and it hides failures if nobody looks at it. When a webhook is missing, misconfigured or rejected, Argo CD still checks the repository on its regular polling interval, so changes eventually reach the cluster. Teams should not read that as confirmation that webhooks work, because a slow sync looks the same whether the webhook failed or was never sent. Confirm the webhook path separately by making a real commit to a non-production Application that points at the Bitbucket repository, then timing how long the Application takes to show the new revision. A sync that happens quickly points to the webhook and callback, while a sync that waits for the poll points to a configuration problem to fix.
Run the test with the same credentials and network path that production will use. Confirm which Bitbucket account and repository credential the callback uses, that outbound API calls from the Argo CD server to Bitbucket are allowed, and that the webhook delivery reaches the Argo CD endpoint through any proxy or ingress in place. Also check the Bitbucket API request limits for your workspace, since heavy commit activity across many Applications can exhaust the allowance and delay callbacks. Record the test commit, the expected and observed sync times and the webhook delivery status, so the team has evidence to reuse after credentials rotate or the endpoint changes.
Bitbucket webhook and pull request generator failures and their fixes
This table lists the failures teams most often hit when wiring Argo CD to Bitbucket Cloud or Bitbucket Data Center, with the likely cause and the fix for each. Read each row against the symptom you see, then check the cause in your own Argo CD and Bitbucket configuration before changing anything. Most faults come down to a mismatched identifier, a secret stored in the wrong place, or an API limit reached by polling.
| Failure | Likely cause | Fix |
|---|---|---|
| Cloud webhook ignored or no sync | Webhook UUID in Argo CD does not match the Bitbucket webhook, or the X-Hook-UUID header is missing from the request | Copy the webhook UUID from the Bitbucket webhook into webhook.bitbucket.uuid, then confirm the header arrives on each delivery |
| Cloud sync runs but changes are missed | Payload omits changed files, so the API callback that fetches them fails or is not reachable | Confirm Argo CD can call the Bitbucket Cloud API with the configured credentials and check the controller logs for the callback result |
| Data Center webhook rejected | Shared secret in Bitbucket does not match webhook.bitbucketserver.secret in argocd-secret | Set the same value in both places, restart the Argo CD API server, and redeliver a test event |
| Repository secret ignored after upgrade to 3.0 or later | Repository still defined in the argocd-cm ConfigMap, which 3.0 no longer reads for repositories | Recreate the repository as a Kubernetes Secret labeled for repositories and remove the old entry from argocd-cm |
| Pull request generator returns no applications | Label filters were used, but Bitbucket Cloud and Data Center generators do not support them and rely on branch matching | Replace label filters with branch matching rules and check the source branch name against the generator pattern |
| Cloud API rate limit errors | Many applications and webhooks poll the Bitbucket Cloud API, exhausting the per-hour request allowance | Reduce polling by relying on webhooks, group applications onto fewer repositories where practical, and monitor request volume |
| TLS trust errors to Data Center | Self-hosted Data Center endpoint uses a certificate signed by an internal CA that Argo CD components do not trust | Add the internal CA to the Argo CD trust configuration for the repo-server and API server, then confirm the repository connects over HTTPS |
Questions teams ask before connecting Bitbucket to Argo CD
How much effort does connecting Bitbucket to Argo CD take?
Most of the effort is one-time setup: creating repository credentials, configuring webhooks with their secrets or UUIDs, designing pull request generators, and wiring Argo CD roles to your identity provider. Recurring effort is smaller but continuous: rotating credentials, reviewing repository access, updating the integration when Argo CD releases a new minor version, and watching webhook delivery. Effort rises with the number of repositories, the number of teams that need their own Argo CD projects, and how many clusters receive deployments. Ask any partner for a written breakdown that separates one-time build work from the support or retainer work that continues after go-live.
Should we settle the Bitbucket license before the Argo CD build?
In most cases, yes. The license decides where repositories are hosted, who can reach them, and which features your merge and deployment controls can use, so it shapes the Argo CD design. Bitbucket Cloud Free covers up to 5 users, Standard is listed at $3.65 per user per month and Premium at $8 per user per month, and Premium adds enforced merge checks, IP allowlisting, deployment permissions and required two-step verification, according to Atlassian's pricing page. Bitbucket Data Center pricing is not published, so request a quote from Atlassian. Confirm the current Data Center end-of-life dates and the Hybrid License terms with Atlassian before you commit, because the company has published more than one timeline.
How long does a Bitbucket integration take to build?
The duration depends on scope, and no supplied figure sets a standard timeline, so treat any single number with caution. The main drivers are how many repositories Argo CD must read, whether you run Bitbucket Cloud or Data Center, whether you need pull request generators or only branch-based deployments, whether webhooks must trigger faster syncs, and whether a test cluster is ready. Approvals from security and change management teams often take longer than the technical build. DeployOpen works on fixed scope, with deliverables and timelines agreed in writing before work starts, so ask for a timeline tied to a defined repository list and a named test environment.
What must our team provide before the work starts?
Prepare four inputs before work begins:
- A repository inventory listing each repository, its size, its branch model and the teams that own it
- Identity decisions covering who receives Argo CD admin, project and read roles, and which identity provider signs them in
- A test cluster that is separate from production, with network access from Argo CD to the cluster and to Bitbucket
- A named owner for Bitbucket app credentials and webhook settings
Repository size matters for planning. Bitbucket Cloud blocks most pushes once a repository passes 4 GB, Atlassian recommends staying under 2 GB, and Free workspaces are limited to 1 GB of total storage, according to Atlassian's documentation.
Can an internal platform team connect Bitbucket to Argo CD alone?
A capable internal team can do this alone if it already runs Kubernetes and Argo CD, has Bitbucket administrator rights, and can dedicate time to the build and to testing. The work touches several areas at once: credentials, webhooks, identity, RBAC and pull request generators, so gaps usually appear where those areas meet. Teams without recent Argo CD upgrade experience often benefit from an outside review of the design before production use. Whichever route you choose, write down who owns each credential, who approves changes to repository access and who handles upgrades. DeployOpen can also provide ongoing support and upgrades under a retainer if your team wants that help after the initial build.
How do Bitbucket webhooks work with Argo CD?
Bitbucket Cloud webhook payloads leave out the list of changed files, so Argo CD makes an API callback to find out what changed. That callback only succeeds when the incoming request carries the X-Hook-UUID header and that value matches the webhook.bitbucket.uuid setting in Argo CD. Bitbucket Server uses the webhook.bitbucketserver.secret setting instead. Plan for the Cloud API limits as well: Atlassian documents 60 requests per hour for anonymous calls and 1,000 requests over a rolling one-hour window for most authenticated resources. Many applications polling through one credential can reach that ceiling, so test webhook behavior at your real repository count.
Why does our Bitbucket pull request generator ignore labels?
Bitbucket Server and Bitbucket Cloud pull request generators do not support label filters. They select pull requests by branch matching instead, so the branch naming convention becomes the control that decides which pull requests create preview environments. If your teams name branches loosely, you may create environments for branches that should not have one. Agree on a branch pattern, document it for developers, and test it on a sample repository before you allow the generator to run across production repositories. Confirm the exact matching behavior for your Bitbucket version in the Argo CD generator guide, because it determines how you write the ApplicationSet.
What security risks come with Bitbucket repositories in Argo CD?
The main risk is that the repo-server runs Helm and Kustomize on repository content, so a repository your team does not control can influence what gets generated and deployed. Limit Argo CD to repositories your organization owns or has reviewed, and restrict out-of-tree file access. Use read-only Bitbucket credentials where possible and store them as Kubernetes Secrets, since Argo CD 3.0 removed repository configuration from argocd-cm. Argo CD authenticates API requests with JSON Web Tokens, uses TLS between its components and redacts repository credentials from responses and logs. Review who can change webhook secrets, because a leaked secret lets an outside party trigger refreshes.
Choosing Bitbucket Cloud, Data Center or another Git host for GitOps
Settle the Git host before you write any Argo CD configuration, because the host decides where repository credentials, webhooks and pull request generators have to point. Start with data residency and regulatory requirements. If your policies require the Git server, its backups and its audit logs to stay in your own data centers, Bitbucket Data Center is the Atlassian option built for that case, and Atlassian describes it as its self-managed offering for customers with strict regulatory or security requirements. Confirm with Atlassian which deployment model matches your obligations, since the pricing page for Data Center does not publish a price and directs buyers to contact Atlassian for a quote.
Plan around the Data Center lifecycle before you commit. Atlassian announced on September 8, 2025 that its Data Center products reach end of life on March 28, 2029, and that new Data Center subscriptions end for new customers on March 30, 2026. Atlassian's journey-to-cloud page separately states that Bitbucket Data Center will not reach end of life and will continue beyond 2029, and that existing customers can renew to a Bitbucket Hybrid License while their environments stay where they are. These statements point in different directions for planning, so ask Atlassian in writing which Bitbucket Data Center product line, license type and support end date apply to your contract, and whether a Hybrid License is available to you as a new or renewing customer.
If you choose Bitbucket Cloud, check repository size and storage limits against your largest monorepo. Atlassian's documentation sets a 4 GB repository size limit, after which only pushes that undo the latest commits are accepted, and recommends staying under 2 GB. Free workspaces are limited to 1 GB of total repository storage. Also price your builds: Atlassian charges $15 per month per concurrent build slot for premium self-hosted Bitbucket Pipelines runners from runner version 5, announced on December 3, 2025. Confirm current figures on Atlassian's pricing pages before you budget, because runner and plan terms change.
How DeployOpen scopes and delivers the Bitbucket integration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Argo CD wired to Bitbucket Cloud or Bitbucket Data Center. Each engagement starts from a written scope that fixes what is connected, tested and handed over before work begins.
How we scope
- Confirm whether your repositories live in Bitbucket Cloud, Bitbucket Data Center, or both, and where each Argo CD instance runs.
- Record which repositories, credential types and branches Argo CD will read, and who approves changes to them.
- Agree in writing whether webhooks, the changed-files callback and pull request generators are in or out of the fixed scope.
How we build
- Define repository credentials as Kubernetes Secrets, with Bitbucket access tokens or app passwords scoped to read access.
- Configure Bitbucket Cloud webhook UUIDs or Bitbucket Server webhook secrets, then test the callback path end to end.
- Test pull request generator branch matching against real pull requests in a non-production cluster before enabling it broadly.
How we hand over
- Document each repository secret, webhook setting and generator configuration, with the owner responsible for rotating credentials.
- Provide a runbook for failed webhook deliveries, stalled refreshes and credentials that expire or get revoked.
- Walk your platform and security teams through the configuration so they can change it without relying on us.
How we support
- Support is available as a retainer covering Argo CD version upgrades, Bitbucket configuration changes and periodic review.
- Confirm with your Atlassian contact which Bitbucket licensing and hosting model applies before the scope is signed.
- Ask any partner for a written quote that separates one-time build work from recurring support, so costs are comparable.
