Multiple GitHub & GitLab Accounts for Client Work: What's Allowed (2026)

Contract for three clients and sooner or later you'll ask whether you need multiple GitHub and GitLab accounts — one set per client.

Most of the time you don't. And the version of the question that circulates on antidetect forums ("how do I stop GitHub linking my accounts?") is the wrong question for anyone doing honest client work. We'll come back to why.

This post covers what the platforms expect, the few cases where a second account really is the right call, and the boring setup (SSH, git config, the CLI, browser profiles) that stops you pushing to the wrong org at 11pm on a Friday. We'll also be blunt about where an antidetect browser like JustBrowser helps a developer and where it doesn't.

Start with what GitHub actually wants

GitHub's model is one person, one personal account, joined to as many organizations as you work with. Its docs say this directly: the page on merging personal accounts recommends using a single account for both personal and professional repositories. And at the time of writing, the Terms of Service limit a person to one free personal account, with a carve-out for a machine account that only runs automation.

Read the current terms before you act on that. They decide, not a blog post.

What irritates me is how scattered the answer is. The terms, the merging-accounts page and the managing-multiple-accounts page each hold about a third of it, and you have to read all three to work out which one applies to you.

So for the typical contractor:

You keep your one account.
Each client adds you to their organization, or as an outside collaborator on specific repos.
When the engagement ends, they remove you. Your history stays yours and their code stays theirs.

That's it. No second login, nothing to keep apart. Honestly, this covers most freelance setups, and people overcomplicate it because "one account per client" looks tidier on paper than it works in practice.

One account per client is a filing system, not a security measure. It mostly buys you more logins to lose.

GitLab follows a similar idea: one account with membership in many groups and projects (check GitLab's own terms for the details on GitLab.com). The bigger difference is that plenty of clients run self-managed GitLab on their own servers. An account on gitlab.client-a.com is a separate account on a separate system by definition. There's no linking question at all. You just have one more login, the same way you have one for each client's Jira.

When multiple GitHub or GitLab accounts are legitimate

A few situations do call for more than one account.

Your employer or client uses Enterprise Managed Users. With EMU, the company's identity provider creates and controls the account. The username carries the enterprise's suffix (something like jdoe_acme) and the account is restricted to that enterprise's resources. You couldn't use your personal account there even if you wanted to. GitHub's "managing multiple accounts" documentation exists largely for this case.

A client's contract requires a client-owned identity. Some security teams want every contributor on an account tied to a company email they can deprovision on the last day. Their call, and it should be written into the contract.

Self-managed instances. Separate server, separate account. Covered above.

Automation. CI jobs, dependency bots and deploy scripts shouldn't run on your personal token. A GitHub App installed on the client's org, or a machine account the client owns, keeps the automation accountable to the client rather than to you.

If I had to name the worst habit in contract development work, it's that last one. Everybody does it. Usually because wiring up a GitHub App on day one feels like a detour when the client wants the pipeline green by lunchtime, and then the token sits there for two years.

What's not on this list: a spare account in case your main one gets suspended, extra accounts to star or fork your own projects, or a fresh account after a ban. Those are exactly what GitHub's abuse systems exist to catch, and they're terms violations rather than workflow choices.

Why platforms correlate accounts (and why you shouldn't fight it)

GitHub doesn't publish how its abuse detection works, and you shouldn't trust anyone who claims to know the full list. The reason it exists is easy enough to see, though: spam account clusters, fake-star networks, malware pushed through throwaway repos, and people coming back after a suspension. Linking accounts run by the same operator lets a platform clean that up in one pass instead of one account at a time.

Browser fingerprinting is one signal sites use in general. We've written about the audio, font and hardware signals people tend to overlook, and about TLS fingerprinting if you want the mechanics. For a developer, though, the obvious connections sit elsewhere: the same email address, the same SSH or signing key, the same payment card, a personal access token running inside a client's pipeline.

Here's the part people don't like hearing. If both accounts are legitimately yours, GitHub knowing they're both yours costs you nothing.

Trying to make two accounts look like two strangers on two machines doesn't protect a legitimate setup. It makes that setup look exactly like the thing the detection is built for. And if one of your accounts is ever suspended, keeping another running so you can carry on working is ban evasion, whatever caused the original flag. That's a fast route to losing both.

When a client's project gets your account flagged

Picture it. A client's CI job runs a scraper or a dependency bot using a token you generated, it misbehaves, and the flag lands on your personal account. No browser was involved anywhere. The token was yours, so the consequences were too.

The fix comes in two parts.

Right now: use the appeal route. A flagged or suspended GitHub account can contact GitHub Support, and the suspension notice and GitHub's docs point you to the right form. Explain which project was involved, what happened and what you've changed since. Be specific, be patient, and don't open a new account while you wait.

Afterwards: move that automation onto a GitHub App or machine account the client owns, so a misbehaving bot is the client's problem to sort out with GitHub, not a mark against your name. That's the real lesson. Not "use a different device".

The setup: keeping legitimate identities straight

Once you have more than one account for a good reason, the risk isn't detection. It's you. Pushing client code under your personal email, approving an OAuth app with the wrong account, pasting a client's token into the wrong terminal. This is plain hygiene, and most of it is free.

SSH: one key per identity

Host github-clienta
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_clienta
  IdentitiesOnly yes

Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal
  IdentitiesOnly yes

Clone Client A's repos with git clone git@github-clienta:org/repo.git and that remote always uses the right key. IdentitiesOnly yes stops ssh-agent offering every key it holds, which is behind the classic "permission denied" or "wrong account" error.

Separate keys aren't about hiding anything. GitHub won't accept the same public key on two accounts anyway, and a key per identity means you can revoke one client's access without touching the rest.

Git config: switch identity by folder

Setting user.email repo by repo works until the one time you forget. Let git pick by directory instead:

# ~/.gitconfig
[user]
  name = Your Name
  email = [email protected]

[includeIf "gitdir:~/work/clienta/"]
  path = ~/.gitconfig-clienta

# ~/.gitconfig-clienta
[user]
  email = [email protected]
  signingkey = ABC123DEF456

Anything cloned under ~/work/clienta/ now commits as your client identity. Run git config user.email inside the repo before the first push, just once, to confirm. GitHub attributes a commit to whichever account has that email verified, so this also decides whose contribution graph the work lands on.

Skip that check once and you can end up with commits on a client's branch under your personal address, and if anyone has already pulled them, fixing the authorship can take an afternoon. Thirty seconds of git config prevents it.

GitHub CLI, the web UI and your IDE

gh auth login can hold more than one account for the same host, and gh auth switch changes the active one. On the web, GitHub has an account switcher in the avatar menu for moving between signed-in accounts without logging out (check GitHub's docs for its current limits).

IDEs are the sneaky one. VS Code and JetBrains both keep their own GitHub sign-in, and Settings Sync will cheerfully pull your personal extensions and snippets into a client workspace. Turn sync off there, or use a separate editor profile.

Browser: separate sessions per client

For the web side (PR reviews, org settings, CI dashboards, OAuth consent screens) what you need apart is cookies, saved passwords and extensions. Chrome profiles and Firefox containers do that well and cost nothing. We compared the options in antidetect vs incognito vs separate profiles. For a solo developer with two accounts, a regular browser profile is very likely all you need.

A quick check that it's working: open the Client A profile, load github.com, look at the avatar. Do the same in your personal profile. If both show the same account, you're opening a tab in one profile rather than launching the other one. It's an easy mistake to make.

Where an antidetect browser actually earns its place

Don't buy JustBrowser to run two GitHub accounts. You don't need it for that, and pretending otherwise would be selling you something.

It earns a place in a dev shop or agency for other reasons.

Team access to shared profiles. An agency testing a client's web app can keep one profile per client environment, with the staging URLs, the test logins for the client's own app and the right extensions, and share it with whoever's on the project. Shares carry view-only or launch permission, roles run owner, admin, member and viewer, and team seats are free. One caveat that matters on GitHub specifically: a personal account belongs to one person. Don't pass a logged-in GitHub session around a team. Each teammate gets their own seat in the client's org.

QA across locales and devices. Each profile carries its own timezone, language and screen settings, part of 40+ identity parameters set in the engine rather than by an extension. That's handy when checking your client's own product. Does the dashboard show the right dates for a user in Europe/Berlin? Does the layout hold on a smaller laptop screen? That's testing software you're paid to build, not dressing up an account.

Automation. The local REST API (bound to 127.0.0.1, documented at justbrowser.app/docs) starts a profile and returns a CDP URL for Playwright, Puppeteer or Selenium. Profiles start headless unless the request body says {"headless": false}, so if your screenshots come back blank or oddly sized, check that first. Useful for screenshot runs against each client's staging site from your own machine.

The platform caveat: JustBrowser runs on Windows x64 and macOS (Apple Silicon). There's no Linux build, so if you develop on Linux, stick with browser profiles or containers. More team-specific questions are answered in our teams and agencies FAQ.

What browser separation doesn't do

It doesn't change who you are to GitHub. Nor should it.

Commit authorship comes from your git config. Billing ties to a payment method. Tokens tie to the account that created them. And your obligations to each client (NDAs, access policies, offboarding when the contract ends) are contract matters that no tool handles for you.

Next steps

Check whether you need a second account at all. Org membership or outside-collaborator access comes first.
If you do, write the mapping down. Which email, SSH key, signing key and browser profile belongs to which client. A plain markdown table is fine.
Move client automation off personal tokens. GitHub Apps or client-owned machine accounts.
If an account gets flagged, appeal and wait. Don't spin up another one.

If you build sites for clients, JustAnalytics keeps each client's analytics in its own property. For bot and invalid-click filtering on client traffic, ClickzProtect scores and filters suspicious clicks. And if the per-client mapping above needs a real address on your own domain rather than another Gmail alias, JustEmails does custom-domain mailboxes with one inbox across all of them. All of these are built by Velocity Digital Labs, the same studio as JustBrowser.

Frequently Asked Questions

Is it against GitHub's terms to have more than one account?

At the time of writing, GitHub's Terms of Service limit a person to one free personal account, with an exception for a machine account used only to run automation, and GitHub's docs recommend one personal account for both personal and work repositories. Accounts your employer or client creates for you, such as Enterprise Managed Users accounts, are a separate case that GitHub documents. Read the current terms before relying on any summary, including this one.

Do I need a separate GitHub account for each client?

Usually not. The intended setup is your one personal account, added to each client's organization or as an outside collaborator on specific repositories, and removed when the engagement ends. You end up with separate accounts when a client uses Enterprise Managed Users, when a contract requires a client-owned identity, or when the client runs a self-managed GitLab instance.

Should I stop GitHub from linking my accounts?

No. Platforms correlate accounts to catch spam clusters, fake-star networks and people returning after a suspension. If both accounts are legitimately yours, GitHub knowing that costs you nothing, and disguising them makes a legitimate setup look like the abuse the detection exists for. Keeping one account running to carry on after another is suspended is ban evasion.

My account was flagged because of a client's project. What should I do?

Appeal through GitHub Support, using the route given in the suspension notice and GitHub's docs. Say which project was involved, what happened and what you've changed. Don't open a new account while you wait. Afterwards, move the client's automation onto a GitHub App or machine account the client owns so it no longer runs on your personal token.

Are regular Chrome profiles enough, or do I need an antidetect browser?

For a solo developer with two or three accounts, regular browser profiles or Firefox containers are enough: they keep cookies, saved passwords and extensions apart. An antidetect browser like JustBrowser is useful for other reasons, such as sharing client QA profiles with a team, testing an app across timezones and screen sizes, or driving profiles from Playwright through a local API.

Do separate SSH and GPG keys per account matter?

Yes, but for housekeeping rather than concealment. GitHub won't accept the same public SSH key on two accounts, and a key per identity lets you revoke one client's access without touching the others. Commit attribution comes from the email in your git config, so set it per client folder.

Try JustBrowser

Native Chromium antidetect browser, not extension-based: a custom Chromium engine, always current with upstream. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer. Local REST API + CDP for Playwright, Puppeteer and Selenium. Windows x64 and macOS (Apple Silicon). $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles, unlimited cloud sync, unlimited team seats.

Get started → · How it differs from Multilogin / GoLogin / AdsPower