Most developer tools treat "GitHub support" and "everything else" as two different tiers of investment: GitHub gets the real integration, and GitLab, Bitbucket, Gitea, and Azure DevOps get a thinner version that shows up later, if at all. Influxx doesn't work that way. Pull request and merge request creation and lookup run through one shared, provider-agnostic interface inside the app, with adapters for GitHub, GitLab, Gitea, Bitbucket, and Azure DevOps all built against the same contract. The interesting part isn't that we support five hosts — it's the discipline required to know which parts of a code review are genuinely universal, and which parts, like GitHub's own issue-closing reasons, are deliberately not.
The Tiered-Support Trap
A lot of review tooling gets built in a predictable order: someone wires up GitHub first, because that's where the open-source ecosystem lives and where most side projects start, and GitLab, Bitbucket, Gitea, and Azure DevOps get added later as something close to an afterthought — a smaller feature set, a slower release cadence, code that reads like "the GitHub thing, plus some if-statements." That ordering makes sense as a matter of history. It makes much less sense as a matter of who's actually using these tools day to day.
GitLab, Bitbucket, Gitea, and Azure DevOps aren't legacy holdouts. Plenty of engineering organizations run self-managed GitLab because a compliance or data-residency requirement rules a SaaS host out entirely. Others are on Bitbucket because their whole issue-tracking and docs stack already runs on Atlassian. Gitea shows up wherever a team wants a lightweight, self-hosted git server without operating GitLab's footprint. Azure DevOps is still the default in a lot of .NET and enterprise shops. None of that is a preference we get to argue people out of — it's infrastructure that already exists, often for reasons outside any individual engineer's control.
We think about the git host the same way we think about the coding agent running underneath a session: it isn't a decision Influxx gets to make on a team's behalf. The whole premise of running Claude Code, Codex, Cursor, GitHub Copilot, Gemini, Grok, and dozens of other agent CLIs side by side, each in its own isolated worktree, is that we refuse to bet the product on any single vendor winning. Git hosting gets the same treatment. A review workflow that quietly assumes GitHub is exactly the kind of load-bearing assumption we try not to build.
What the Shared Interface Actually Covers
Instead of building a GitHub feature and retrofitting four more onto it, we started from a contract: a fixed, small set of operations every provider adapter has to support, regardless of which host is on the other end. Each provider then gets a thin adapter that implements that contract by wrapping the provider's own CLI or API client — so Influxx isn't reimplementing GitLab's REST API or Bitbucket's from scratch, it's driving the same official tooling a power user on that host would already reach for.
Four Operations, Every Host
- Resolving the repository: figuring out which repository — and which provider — a given worktree actually belongs to, before anything else can happen.
- Looking up a review by branch: checking whether the branch you're sitting on already has an open pull request or merge request, so Influxx can show its state instead of asking you to go find it yourself.
- Looking up a review by number: jumping straight to a specific pull or merge request once you already know which one you want.
- Creating a review, where the provider supports it: opening a new pull or merge request directly from the app instead of switching to a browser tab.
That list is deliberately narrow. It's the set of operations that really are the same idea everywhere — every one of these five hosts has some notion of "which repo," "is there already a review open for this branch," and "let me look up review number N." Anything that isn't genuinely shared across all five stays out of the common contract and gets handled inside individual adapters instead.
"We didn't want a codebase where 'the git provider' quietly meant GitHub and the other four were exception handling bolted on the side. If an operation isn't genuinely the same concept on GitHub, GitLab, Gitea, Bitbucket, and Azure DevOps, it doesn't belong in the shared interface — it belongs in one adapter, on purpose."
— Tobias Lindqvist, Staff Engineer, Platform at ETAPX
An Explicit Rule, Not an Accident
None of this is an accident of how the code happened to evolve. Source-control and review-related work is required to consider every supported provider, not only GitHub, before it ships — and reviewers are specifically watching for GitHub-only vocabulary creeping into what's supposed to be a generic, provider-neutral concept. Code that only makes sense if "PR" is the universal noun for a review, or a status display that only knows how to read GitHub's own terminology, gets sent back the same way a missing test would.
That policy is less about treating every provider identically and more about being explicit up front about which parts of a feature are supposed to behave the same everywhere, and which parts are allowed — even expected — to diverge because the underlying host genuinely works differently. Two recent, contrasting examples show what that looks like in practice, pulling in opposite directions.
When GitHub Deserves to Be Different: Closing Reasons
The first example runs toward GitHub-specific richness, on purpose. When you close out a task tracked through GitHub Issues, Influxx supports GitHub's own set of closing reasons: completed, not planned, or duplicate of a specific other issue. It would have been easy to flatten all of that down to one generic "closed" state and call it consistent. We didn't, because GitHub's closing reasons aren't decoration — they're a real part of how GitHub itself models an issue's lifecycle, and collapsing them would throw away information a team already relies on.
What we didn't do is generalize that same richness to GitLab, Linear, or Jira. Those tools don't have a "duplicate of this other issue" concept sitting in their own data model the way GitHub does — closing an item in GitLab or Linear is a flatter operation than that. Inventing GitHub-shaped closing reasons for tools that don't actually have them wouldn't have been provider parity; it would have been fiction dressed up as a feature, and it would have broken the moment someone tried to reconcile Influxx's view of an issue against what the provider's own interface actually shows.
"'Not planned' and 'duplicate of' are GitHub concepts before they're anything else — they live in GitHub's own issue schema. GitLab's closing model doesn't have a slot for them, and neither does Linear's. Bolting them on elsewhere wouldn't be feature parity, it'd be us inventing states that don't sync back to anything real. If a provider doesn't actually have the concept, we don't fake it just to look consistent."
— Tobias Lindqvist, Staff Engineer, Platform at ETAPX
When a GitHub Assumption Almost Became the Default: Push Recovery
The second example runs in the opposite direction: a place where a GitHub-shaped assumption had to be deliberately kept out. When a push fails, Influxx can bring in AI assistance to help figure out why and walk through fixing it. Building that recovery flow came with an explicit requirement: construct a safe, provider-neutral prompt for whatever assistant is helping, and don't assume GitHub-specific terminology or concepts anywhere inside it.
That requirement exists because a push doesn't fail for GitHub-shaped reasons only. It fails because a self-managed GitLab instance has a push rule blocking a force-push to a protected branch, because a Bitbucket repository has a branch permission scheme that doesn't map cleanly onto GitHub's branch-protection vocabulary, because a self-hosted Gitea server has a pre-receive hook rejecting the commit, or because Azure DevOps has its own build-validation policy sitting in front of the branch. A recovery prompt that quietly reached for GitHub's terms — talking about "status checks" or "branch protection" as if those phrases meant the same thing, in the same form, everywhere — would hand a developer on any other host a confident, wrong explanation. Getting it wrong there is worse than not helping at all, because it still looks like help.
"Our repos live in self-managed GitLab because of a data-residency requirement, full stop — that isn't changing for anyone's convenience. Most tools that add GitLab support after the fact still talk to me like I'm on GitHub with a different logo. When one of our push rules rejected a force-push, Influxx's assistant walked through GitLab's own rejection message instead of guessing at a GitHub explanation that didn't apply to me at all. That's the first review tool that didn't make me translate."
— Marisol Ibarra, Platform Engineer at a fintech running self-managed GitLab
The Same Instinct as the Rest of the Cockpit
This is the same instinct that shows up everywhere else in Influxx. We didn't build a Claude Code app with dozens of other agent CLIs squeezed in around the edges — Claude Code, Codex, Cursor, GitHub Copilot, Gemini, Grok, Droid, Amp, OpenCode, and the rest all sit behind the same session model, each one running in its own isolated git worktree, because we don't think a team should have to reorganize its workflow around whichever agent we personally happen to like best. Git hosting is the same argument applied one layer down. A cockpit built around your CLIs, your notes, and your agents in one place only holds together if it doesn't also quietly assume everyone pushes to the same host.
That's why the discipline here isn't "treat GitHub, GitLab, Gitea, Bitbucket, and Azure DevOps identically in every respect." It's narrower than that, and we think more honest: know exactly which parts of a review — resolving a repository, finding an open request for a branch, looking one up by number, creating a new one — are supposed to work the same way no matter the host, and keep those separate from the parts, like GitHub's closing reasons, that are genuinely specific to one provider's own model. Get that boundary right, and adding a sixth host later is an adapter, not a rewrite.
Frequently Asked Questions
Which git hosting providers does Influxx support for pull and merge requests?
GitHub, GitLab, Gitea, Bitbucket, and Azure DevOps are all supported through the same shared review interface: resolving the repository, looking up an existing review for your current branch, looking up a review by number, and creating a new review where the provider supports it.
Does self-managed GitLab, Bitbucket Server, or a private Gitea instance work the same way as the hosted versions?
Each adapter wraps that provider's own official CLI or API client rather than reimplementing its API from scratch, so self-hosted deployments that those official tools already support generally behave the same way their cloud counterparts do. We'd rather lean on a provider's own client than maintain a second, parallel implementation of its API surface that drifts out of sync over time.
Can I open a new pull request or merge request from inside Influxx, or only look up existing ones?
Both, where the provider supports it. The shared interface includes creating a new review directly from the app, not just finding one that already exists — though exactly how creation behaves can vary slightly by host, since it's built against each provider's own client rather than one hardcoded assumption about how a review gets opened.
Why does GitHub Issues get richer closing reasons than GitLab, Linear, or Jira do inside Influxx?
Because those closing reasons — completed, not planned, duplicate of a specific issue — are a real part of GitHub's own issue model, not a generic concept every tracker shares. GitLab, Linear, and Jira each close an item differently, and none of them has a matching slot for "duplicate of this other issue." We'd rather expose GitHub's richness honestly than fake an equivalent for tools that don't actually have one.
If a push fails, does Influxx's AI assistance assume I'm using GitHub?
No. The push-recovery flow was explicitly built around a provider-neutral prompt with no GitHub-specific terminology baked in, because a push can fail against any git host you've configured — a GitLab push rule, a Bitbucket branch permission scheme, a Gitea pre-receive hook, and an Azure DevOps build policy all produce different failures that deserve their own explanation, not a GitHub-shaped guess.
Does supporting five providers mean Influxx treats them all identically?
No, and that's deliberate. The parts of a review that are genuinely the same idea everywhere — finding it, looking it up, creating it — run through one shared interface. The parts that are genuinely specific to one provider, like GitHub's closing reasons, are built as provider-specific features on top of that shared core instead of being forced onto hosts that don't have the underlying concept.
None of this makes a multi-provider review workflow more impressive than a GitHub-only one — it makes it more honest about where the real differences sit. GitHub, GitLab, Gitea, Bitbucket, and Azure DevOps aren't equally popular, and we're not pretending otherwise. But the team next to yours might be running any one of them for reasons that have nothing to do with preference, and a cockpit that only works well on one host isn't one you can actually hand a whole engineering org.
