DEV Community

Cover image for What actually leaves your server when you connect an analytics tool to Jira
yaniv zalevas
yaniv zalevas

Posted on

What actually leaves your server when you connect an analytics tool to Jira

A few years ago a client's data protection officer asked me one question before she'd sign off on an engineering-analytics tool: "If we connect this, where does the data live?"

The honest answer was: not here. Nobody in the room had thought about it, because the dashboard looked nice.

That conversation changed how I buy tooling, and later how I built it.

The inventory nobody does

Start with what these integrations actually ingest. It's not aggregate metrics. It's every ticket title and comment. Every commit message, with author identities and timestamps. Review threads — including the heated ones. Branch names. Deployment events.

A git history is the most honest document your company owns. Every mistake, every argument, every 2 a.m. hotfix, with names attached. That is not a thing you ship to a stranger's cloud by clicking OAuth consent — and yet that's the standard onboarding flow for most analytics tools, because the dashboard looks nice.

"We're SOC 2" doesn't answer the question

Security compliance and data ownership are different questions. A vendor can be perfectly secure and the data still isn't yours — it sits in their cloud, under their jurisdiction, and it outlives your contract with them. When the vendor is acquired, your development history is an asset in someone else's deal.

Even "self-hosted vs SaaS" isn't the real axis — several vendors now offer dedicated deployments on your infra but still operate them. The four questions that actually matter:

  1. Does anything leave your infrastructure? (Not "is it encrypted in transit" — does a copy exist anywhere else?)
  2. Who operates the deployment — you, or the vendor with the keys?
  3. Can you read the source, so an exit isn't a migration project?
  4. What does it cost — including the cost of leaving?

Most vendor pages answer exactly none of these. Ask them in the sales call and watch the answers arrive one at a time.

Why this shaped how we built our own

When we built Deckgauge — the engineering-intelligence board my fractional-CTO company uses to understand client departments in days — these questions were the spec, not an afterthought. One docker compose up on your own infrastructure. Four trackers — Jira, GitHub, GitLab, Azure DevOps — connected strictly read-only. The warehouse lives where you live. Source-available (FSL-1.1, converts to Apache-2.0 in September 2028), so reading the code is a right, not a negotiation.

That's the whole pitch and I'll leave it there, because the point of this post isn't us — it's the question.

The question to ask any vendor

Not "are you secure." Ask: who can be compelled to hand this over — by a court, by a government, by an acquirer? And if we walk away tomorrow, do we leave with the data or just the invoices?

Your development history is the most candid record your company will ever produce. Treat it like one.


I'm Yaniv — fractional CTO, building Deckgauge in public. Repo: https://github.com/Codpal-Limited/deckgauge. Live demo with a fictional org: https://demo.deckgauge.com

Top comments (0)