Snyk Bitbucket Integration: Setup, Limits, and Alternatives

The Snyk Bitbucket integration connects Snyk to your repositories for automatic import, PR security checks, and fix pull requests — but "Bitbucket" is really three different integrations (the recommended Bitbucket Cloud App, a legacy Cloud integration, and a separate Bitbucket Data Center/Server path), and picking the wrong one costs you features. Atlassian shops are used to being the second-class citizen in security tooling compared to GitHub, and the way to avoid that here is knowing exactly which variant you are configuring.

This post walks through each variant's setup, what you actually get on pull requests, the Snyk Broker requirement for self-hosted instances behind a firewall, and how to complement or replace the integration with pipeline-level scanning.

The three variants, and which to choose

Bitbucket Cloud App — the current, recommended path for bitbucket.org workspaces. It installs as an Atlassian app connected at the workspace level, and Snyk's own docs steer new setups here for long-term support. It provides continuous scanning across integrated repositories, PR checks, and repository import without managing credentials by hand.

Legacy Bitbucket Cloud integration — the older username/app-password wiring. It still functions in existing orgs, but it predates the app model, and new setups should not start here.

Bitbucket Data Center/Server — for self-hosted Atlassian instances. Configured with your instance URL plus a service account's credentials or personal access token. This variant has historically lagged the Cloud App on features (fix PR automation and check richness arrive on Cloud first), which is worth confirming against current docs for whatever capability you specifically need.

If you run Data Center behind a firewall — the normal case — add Snyk Broker to the architecture: a small proxy you deploy inside your network that establishes an outbound connection to Snyk, so the SaaS never needs inbound access to your SCM. It is deployed as a Docker container with a client ID and an allow-list of the API paths Snyk may call.

Setting up the Bitbucket Cloud App

Prerequisite: Admin permission on the Bitbucket workspace — not just the repositories. Then:

1. In Snyk, go to your Organization's Integrations page and select the Bitbucket Cloud App tile.
2. Click Connect; you are sent to Atlassian to authorize the app for a workspace you admin.
3. Grant the requested scopes and pick the workspace.
4. Back in Snyk, import repositories — individually or in bulk.

Import creates a Snyk Project per detected manifest: a repository with a package.json, a pom.xml, and a Dockerfile becomes three Projects, each scanned and re-tested on Snyk's schedule and on PR events. Two settings to visit immediately, because their defaults decide how intrusive the tool feels:

• PR checks — whether Snyk posts a pass/fail check on pull requests, and whether it fails only for newly introduced issues or for pre-existing ones too. Start with new-issues-only; failing every PR against the whole backlog of a legacy repo guarantees the checks get ignored.
• Automatic fix PRs — Snyk opening upgrade PRs when fixes exist. Useful, but calibrate frequency and grouping before enabling org-wide, or you will meet the Monday wall of forty dependency PRs.

Setting up Bitbucket Data Center/Server

1. Create a service account in Bitbucket with read access to target repositories (write access if you want fix PRs), rather than binding the integration to a human's account that will eventually be deactivated.
2. Generate a personal access token for that account. If your instance has Basic Auth disabled, configure the integration with the literal username x-access-token and the PAT as the password — that exact convention is in Snyk's docs and is easy to miss.
3. In Snyk's Integrations page, choose Bitbucket Server/Data Center, enter the instance URL and credentials.
4. If the instance is not internet-reachable, deploy Snyk Broker first and connect through it; direct connection attempts to a firewalled instance are the most common "integration fails silently" cause.

Token rotation discipline applies: PATs expire, and an expired integration token fails quietly — scans just stop being current. Put the rotation date in your ops calendar, and monitor for import staleness rather than trusting the green tile. This is standard SCM-integration hygiene regardless of vendor.

What you get on pull requests — and the metering

With either variant wired up, the day-to-day surface is the PR check: new dependency vulnerabilities and license issues introduced by the diff produce a failing check with details, and Snyk Code findings can ride along where enabled. Each automated scan consumes tests from your plan's quota, which is the operational catch for free-tier users: an active Bitbucket workspace with PR checks enabled burns through the free plan's monthly test caps (around 200 open source tests) in days, and when the quota is gone the checks stop telling you anything. Pricing mechanics are covered in our breakdown of Snyk's free tier; the short version is that SCM-integrated PR checks are effectively a paid-plan feature for any team with real traffic.

Pipelines-level scanning: complement or alternative

The SCM integration is event-driven and repo-centric. The other integration point Atlassian shops should know is Bitbucket Pipelines, where you run the scanner as a build step — Snyk ships an official pipe:

# bitbucket-pipelines.yml
pipelines:
  pull-requests:
    '**':
      - step:
          name: Security scan
          script:
            - pipe: snyk/snyk-scan:1.0.1
              variables:
                SNYK_TOKEN: $SNYK_TOKEN
                LANGUAGE: "npm"
                SEVERITY_THRESHOLD: "high"
                DONT_BREAK_BUILD: "false"

Pipeline scanning tests the resolved build (including private registries and build-time resolution the SCM-side scan cannot see) and gives you exit-code control for gating. SCM integration gives you always-on monitoring, recurring re-tests against new advisories, and fix PRs without touching every repo's YAML. Mature setups run both; if you must pick one, pipeline scanning is the more truthful signal because it scans what you actually ship. Command-level details are in our snyk test and snyk code test guide.

As for alternatives: every serious platform in the category integrates with Bitbucket now, though depth varies — Cloud App parity, Data Center support, and Broker-equivalent connectivity for firewalled instances are the three questions that separate marketing checkmarks from working integrations. Safeguard's SCM integrations cover Bitbucket alongside GitHub and GitLab, and our comparison with Snyk details where the integration models differ; open tooling (Trivy or OSV-Scanner in a Pipelines step) covers the gating use case with zero licensing, at the cost of assembling monitoring and fix workflows yourself.

FAQ

Does Snyk work with Bitbucket?

Yes — bitbucket.org workspaces via the Bitbucket Cloud App (recommended) or the legacy Cloud integration, and self-hosted Bitbucket Data Center/Server via a service-account integration, with Snyk Broker handling firewalled instances.

What permissions does the Snyk Bitbucket integration need?

Installing the Cloud App requires workspace Admin. For Data Center, the service account needs repository read for scanning and write for automatic fix PRs; use x-access-token as the username with a personal access token when Basic Auth is disabled.

Why are my Snyk PR checks not appearing on Bitbucket?

Usual causes, in order: PR checks disabled in the integration settings, the repository imported before checks were enabled (re-sync it), an expired service-account token on Data Center, Broker connectivity for firewalled instances, or an exhausted test quota on the free plan.

Is Bitbucket Data Center supported as well as Bitbucket Cloud?

Yes, but as a distinct integration with its own setup, and feature richness has historically arrived on the Cloud App first. Firewalled Data Center instances additionally require deploying Snyk Broker for connectivity.