How does Bitbucket Cloud architecture differ from Bitbucket Data Center, and what drives the decision between them for enterprise deployments?

Think of Bitbucket Cloud versus Data Center like renting an apartment versus building your own house. The apartment (Cloud) is move-in ready with maintenance included, but you cannot knock down walls or install custom plumbing. The house (Data Center) gives you complete control over every room, but you hire the contractors, maintain the roof, and pay for everything from the foundation up.

Bitbucket Cloud runs on Atlassian's infrastructure as a multi-tenant SaaS application. All customers share the underlying platform, with logical isolation at the workspace level. Atlassian handles upgrades, scaling, security patching, and infrastructure management. Bitbucket Cloud includes Pipelines (CI/CD), Pipes (pre-built integrations), and the full workspace-project-repository hierarchy. The API is REST 2.0 at api.bitbucket.org. Bitbucket Data Center is a self-hosted Java application deployed on your own infrastructure (physical, VM, or Kubernetes). It supports active-active clustering with multiple application nodes behind a load balancer, sharing a common database (PostgreSQL or Oracle) and a shared filesystem (NFS or clustered storage) for repository data. Data Center does not include Bitbucket Pipelines; CI/CD requires integration with Bamboo, Jenkins, or another external tool.

Architecturally, Data Center uses a fundamentally different scaling model. Each application node runs an independent JVM process with its own in-memory caches, but they share Git repository storage and the relational database. Git operations (clone, push, fetch) are distributed across nodes via the load balancer, and the shared filesystem ensures all nodes see the same repository state. Data Center supports smart mirroring, where read-only mirror instances are deployed in remote geographic locations to reduce clone and fetch times for distributed teams. Mirrors synchronize with the primary cluster asynchronously and serve read traffic locally while routing write operations back to the primary. This architecture is critical for companies with teams spanning continents.

In production, the decision criteria revolve around five factors. Data sovereignty: regulated industries (finance, healthcare, government) often require data to reside in specific jurisdictions, making Data Center mandatory. Integration complexity: companies with existing on-premise tools (LDAP, internal CI systems, custom hooks) find Data Center easier to integrate because it runs in the same network. Scale: Data Center supports repositories larger than Cloud's limits (2 GB repo size limit on Cloud, effectively unlimited on Data Center). Performance: teams cloning large repositories across geographic regions benefit from Data Center's smart mirroring. Cost model: Cloud uses per-user subscription pricing, while Data Center uses annual license tiers. For organizations with hundreds of developers, the total cost of ownership calculation must include Data Center's infrastructure, administration, and upgrade costs versus Cloud's per-seat fees.

A gotcha that derails migration projects: Bitbucket Cloud and Data Center have diverging feature sets that grow further apart over time. Cloud has Pipelines, Pipes, and workspace-level features that Data Center lacks. Data Center has smart mirroring, hook scripts, and deeper LDAP/SAML integration that Cloud handles differently. Migrating from one to the other is not a simple lift-and-shift; it requires re-architecting CI/CD pipelines, reconfiguring authentication, and potentially rewriting API integrations. Atlassian provides migration tools, but they handle repository content only, not the surrounding automation and configuration. Teams that assume feature parity between Cloud and Data Center discover gaps late in migration projects, causing timeline overruns.