Migrate from GitHub Copilot to Tabby

Migrate from GitHub Copilot to Tabby: what moves and what needs rework

A team that wants to stop sending code completions to a hosted service can move to a self-hosted Tabby server, but the migration is really three workstreams: a GPU rollout, identity integration and plugin deployment, run as a parallel pilot before anyone switches off Copilot. Platform or IT engineering usually owns the work, with a security lead signing off on where source code, prompts and logs are stored and who can reach the server. Tabby's core is available under the Apache 2.0 license, while content in its ee/ directory falls under a separate license, so the team should confirm which features it needs sit in the core and which, such as certain admin and group management controls, belong to the enterprise tier. The effort is mostly in sizing GPUs for the completion and chat models and in network and identity setup, not in the editor plugins themselves. The main risk is an under-sized server that makes completions slow enough that developers quietly stop using it.

Start by inventorying what Copilot is used for today: inline completions, chat, and any agent or pull request features. Only the first two have a direct Tabby equivalent, so teams that depend on agent workflows need to plan separately for those. For the GPU rollout, the Tabby README's Docker example uses the StarCoder-1B model for completion and Qwen2-1.5B-Instruct for chat with --gpus all and --device cuda. Those are starting points for a pilot, not sizing advice for a full developer population, so the team should benchmark latency at its real concurrency. Identity needs the same care: LDAP sign-in arrived in v0.24.0 and GitLab SSO in v0.12.0, so confirm the version you deploy supports your directory. Plugins for VS Code, Vim and IntelliJ should be rolled out to a pilot group first, with a written rule for who keeps Copilot licenses during the overlap period.

Run the pilot with both tools live and measure what matters: completion acceptance, latency, and the number of developers who still open Copilot. Keep Copilot seats until the Tabby pilot group has worked through a full release cycle without a blocking gap, then remove seats in stages. Confirm the Tabby release you plan to standardize on against the Tabby GitHub releases page, since the latest stable version and pre-release builds change often, and pin the version in your deployment. Ask your team to document which settings and model choices they changed, so the configuration can be reproduced after the pilot. Finally, decide how indexing of repositories for context will be scoped and who approves which repositories are indexed, because that decision determines what the assistant can see and therefore what your security review must cover.

Which GitHub Copilot capabilities map to Tabby

This table maps the main GitHub Copilot capabilities a development team relies on to their Tabby equivalents, marking each as clean, needs rework or gap. Read the status column first, then confirm each plan-specific item against Tabby's pricing page and your own IDE versions before committing to a rollout date.

Capability	Tabby equivalent	Status
Inline code completion	Tabby completion model served from your own GPUs, with the StarCoder-1B example in the README as a starting point	Clean
Chat in the editor	Tabby chat model (the README example uses Qwen2-1.5B-Instruct); test answer quality on your own codebase before choosing a larger model	Needs rework
VS Code, JetBrains and Vim plugins	Editor plugins for VS Code, Vim and IntelliJ; JetBrains Marketplace listing exists, so confirm your exact IDE and plugin version pairing	Needs rework
Repository context and indexing	Repository indexing for context retrieval; confirm which Git hosts and branches are supported and how often indexes refresh	Needs rework
Sign-in with corporate identity	LDAP authentication arrived in v0.24.0 and GitLab SSO in v0.12.0; confirm which sign-in method your plan includes	Needs rework
Admin controls and group management	Enhanced security and group management are listed for Enterprise; Community and Team plans have different limits, so check the pricing page	Needs rework
Copilot agent and cloud features	No confirmed direct equivalent in the sources reviewed; treat agent workflows and hosted cloud features as a gap to validate with a pilot	Gap
Seat-based user limits	Community covers up to 5 users and Team up to 50 per Tabby's pricing page; confirm current limits before sizing	Needs rework

Migration sequence from inventory to decommission

This sequence moves developers from GitHub Copilot to a self-hosted Tabby server in controlled stages, so each stage has a clear owner, a written output and a rollback path before Copilot access is removed. Teams keep Copilot running until the pilot and parallel phases show that Tabby meets their needs.

Inventory users, IDEs, repositories and identity sources
The platform team lists every developer group that uses Copilot, the IDEs and versions they run (VS Code, JetBrains IDEs or Vim), the repositories they work in and the identity source behind their accounts, such as Microsoft Entra ID, LDAP or GitLab. Security and the engineering managers confirm which repositories hold code that must stay on your own servers. The output is a signed inventory that shows which sign-in method Tabby will need to support, and which teams are candidates for the pilot.
Size GPUs and select the models
Engineering selects the completion and chat models that Tabby will serve and matches them to GPU hardware. The Tabby README's Docker example uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat, and the README notes support for consumer-grade GPUs, but larger models need more memory and throughput. Load test with realistic concurrency from the inventory before buying hardware. The output is an approved model list and a GPU sizing note that states peak concurrent users, expected latency and the hardware each model runs on.
Deploy the Tabby server and configure sign-in
The infrastructure team installs Tabby on the chosen GPU hosts, places it behind TLS, and configures authentication. LDAP sign-in arrived in v0.24.0 and GitLab SSO in v0.12.0, so confirm which release your environment will run against the current stable build on the Tabby releases page. Test sign-in with a set of pilot accounts and confirm that a user who leaves the directory loses access. The output is a working LDAP or GitLab sign-in, a documented server address and a backup of the Tabby configuration.
Index repositories and run the pilot on one IDE
Connect the repositories approved in the inventory so Tabby can use them as context, and start with the pilot group on one plugin, either VS Code or a JetBrains IDE from the JetBrains Marketplace. Ask pilot developers to record completion quality, slow responses and any code they could not get suggestions for, and compare results against their Copilot experience on the same tasks. The output is a pilot report with accepted suggestion rates, latency observations and a list of repositories or languages that need changes before wider rollout.
Run Tabby and Copilot in parallel
Keep Copilot licenses active while the pilot group and then wider teams use Tabby in the same IDEs. Developers switch between the two tools, and the platform team watches GPU utilization, queue depth and error rates through the Tabby server and monitoring, while security confirms that no source code leaves the approved hosts. Confirm the Copilot seat count and any AI credit usage with the account owner so cost comparisons use real figures. The output is a go or no-go decision for each team, recorded with the metrics behind it.
Cut over teams and set the rollback plan
Move teams in waves, starting with the groups that passed the parallel phase. Each wave gets written instructions for installing the Tabby plugin, signing in and reporting problems, and the rollback plan states how a team returns to Copilot if the Tabby server fails, including who can re-enable the seats and how long that takes according to the Copilot admin settings. The output is a signed cutover record for each wave and a rollback runbook that the on-call team has tested.
Decommission Copilot and retain evidence
After the last wave is stable, remove Copilot seats and disable the Copilot policy in the organization settings, and revoke any tokens or plugin configurations that still point to Copilot. Export the records the compliance team needs, such as the inventory, sign-in configuration, access reviews and change records, and store them with the Tabby backup. The output is a closed Copilot subscription, a decommission record and an updated access review that lists who can reach the Tabby server.

How to size GPUs for completion and chat models

Start from the Tabby README's Docker example, which runs the server with --gpus all and --device cuda and uses StarCoder-1B for code completion and Qwen2-1.5B-Instruct for chat. Those are small models chosen to get a working server quickly, and they show the shape of the deployment, not the capacity you need. Completion and chat load differently: completion requests are frequent and short, with latency that developers feel on every keystroke, while chat requests are fewer but generate longer answers. Larger models need more GPU memory for weights and for the context each request holds, so moving from a 1B or 1.5B model to a bigger one can change the hardware class, not just the card count. Confirm the exact model names, memory figures and GPU requirements against the Tabby documentation for the release you deploy, since this page does not supply them.

Concurrency decides how many developers one GPU can serve well. If you front the models with vLLM, its OpenAI-compatible server exposes Prometheus metrics at /metrics, covering request counts, token throughput, latency histograms and KV cache use, so you can see whether requests queue before developers complain. If you use Ollama as the serving layer, check its documented settings: OLLAMA_NUM_PARALLEL defaults to 1 parallel request per model, OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE control how many models stay loaded and how many requests wait. Raising these values trades memory for throughput, so change one at a time and measure. Ask your hardware vendor or cloud provider to confirm which GPU classes your chosen serving engine supports before you order anything.

Benchmark before buying. Replay real traffic from your own repositories, with the number of developers who will actually use the pilot, and record completion latency, chat response time, GPU memory use and queue depth at peak hours. Use the Tabby plugin logs and your serving layer's metrics together. Then price options from those measurements: the GPU servers or cloud GPUs, the hours they run, and the engineering time to operate them are the recurring costs, while the initial benchmark and setup are one-time. Ask any vendor quoting hardware for the memory footprint per model at your context length and for the number of concurrent users they assume, so you can check their figures against your own results.

Identity, repositories and plugins to move or rebuild

Moving from GitHub Copilot to Tabby is less a data migration than a rebuild of access and context. Copilot has no export of your developers' usage to replicate, so the work is recreating who can sign in, which repositories Tabby indexes and how each developer connects their editor. Each item below is a decision you make before the pilot starts.

LDAP sign-in for developers

Tabby added LDAP authentication in v0.24.0, released February 5, 2025, so developers can sign in with the directory accounts your organization already manages. Before the pilot, confirm the bind account, the user search base and how group membership maps to Tabby access. Test a disabled account and a leaver to confirm that removing directory access also removes Tabby access. Plan who owns the service account credentials and how they rotate.

GitLab SSO for GitLab shops

If your source code lives in GitLab, Tabby's GitLab SSO, added in v0.12.0 on June 6, 2024, lets developers use their existing GitLab identity. Check that your GitLab instance is reachable from the Tabby server and that the OAuth application is registered with the redirect URL your Tabby host uses. Decide whether GitLab group membership or a manual invite list controls access, since that choice determines who can reach the server after a team change.

Repository indexing for context

Tabby can index repositories so completions and chat draw on your own code, which is the closest replacement for the context Copilot gathers from open files. Start with a short list of active repositories, confirm which branches are indexed, and decide how sensitive directories are excluded. Indexing is where source code is stored on your server, so the access rules on the Tabby instance matter as much as the index itself. Re-index after large refactors and check that results respect repository visibility.

OpenAPI for IDE and cloud IDE integration

Tabby exposes an OpenAPI interface so that tools beyond the standard plugins, including cloud IDEs, can request completions from your server. This matters if your developers work in browser-based environments that the VS Code, JetBrains or Vim plugins do not cover. Ask your platform team to define which internal clients may call the API, how tokens are issued and where requests are logged, and test that the endpoint is reachable only from approved networks.

Per-developer plugin installation

Each developer must install and point the VS Code, JetBrains or Vim plugin at your Tabby URL, and this step does not carry over from Copilot automatically. Prepare a short install guide with the server address, the sign-in method and how to disable the Copilot extension to avoid duplicate suggestions. Track which developers have completed setup during the pilot so that teams running both tools understand which suggestions come from which assistant.

How the migration changes by team size and starting point

Tabby's pricing page lists the Community plan as free and open source for up to 5 users. It fits a small group of developers who want to test completions on their own GPU before committing to a wider rollout. At this size, most of the work is standing up one server, choosing models that fit the available GPU memory and installing the VS Code, JetBrains or Vim plugin on each developer machine.

Single server: One Docker host with a GPU can serve the whole pilot group, following the pattern in the Tabby README.
Model choice: Start with the completion and chat models in the README example, then test larger models only if your GPU has the headroom.
Plugin setup: Each developer connects their editor plugin to the server endpoint, so document the URL and access token process.
Parallel running: Keep Copilot licenses active during the pilot so developers can compare suggestions side by side.
Sign-in: Confirm with Tabby whether the Community plan includes the sign-in methods you need, because LDAP and GitLab SSO features are tied to specific releases.

Before you commit, confirm with Tabby which admin and authentication features are included on the Community plan.

What drives cost and duration in this migration

This table lists the main cost and effort drivers when moving developers from GitHub Copilot to a self-hosted Tabby server, with why each one moves cost and how to keep it down. Use it to frame the questions you bring to a written scope and to decide which drivers your own environment will push hardest.

Driver	Why it moves cost or effort	How to keep it down
GPU capacity and ownership	Completion and chat models need GPU memory and throughput sized to peak developer activity. Owned hardware adds purchase, power, cooling and refresh costs, while rented cloud GPUs recur monthly and grow with usage.	Size against measured peak concurrency in a pilot, start with the small models shown in Tabby's Docker example, and compare owned and rented capacity over the expected life of the hardware.
Model serving and concurrency	Ollama defaults to one parallel request per model and vLLM needs tuning for tensor parallelism across GPUs. More concurrent developers or larger models require more GPUs or more replicas.	Load test with realistic completion rates, tune parallelism settings, and use vLLM metrics at /metrics or Ollama queue limits to see when capacity is short before adding hardware.
Identity integration	LDAP sign-in (added in Tabby v0.24.0) and GitLab SSO (added in v0.12.0) need directory access, service accounts, and testing against your identity provider. Mismatched group mapping adds rework.	Confirm the directory schema and group model early, use existing identity infrastructure, and keep the integration scope to the sign-in paths your teams actually use.
Number of IDEs and plugins	Each editor (VS Code, JetBrains, Vim) needs its own plugin install, version checks and developer guidance. Support tickets rise with the number of IDE versions in use.	Standardize on the one or two IDEs most teams use, publish a pinned plugin version, and roll out in waves rather than all at once.
Repositories indexed for context	Indexing more repositories increases index build time, storage and the work needed to keep indexes fresh. Access rules for private code must be reviewed for each repository added.	Start with the repositories in the pilot group, confirm how Tabby handles repository access, and add repositories in batches after reviewing permissions.
Tabby plan choice	Tabby Community is free for up to 5 users. Team is listed at $19 per seat per month for up to 50 users, and Enterprise is custom priced with unlimited users, per Tabby's pricing page. Seat count and admin needs decide the plan.	Count active users rather than licensed headcount, check which admin and group features you need, and ask Tabby for a written quote for the exact seat count.
Engineering time to operate	Someone must patch the server, rotate models, monitor GPUs, handle upgrades and answer developer questions. vLLM and Ollama have no paid edition, so their cost is hardware and the people who operate them.	Assign a named owner and a runbook, automate deployment, and decide early whether internal staff or a support retainer will cover upgrades and incidents.

What usually goes wrong and how to prevent it

Most failed Copilot-to-Tabby pilots fail for operational reasons, not model quality. The four risks below cover hardware, identity, client versions and reversibility, and each one needs a named owner before developers are moved.

Underprovisioned GPUs slow completions

Inline completions are latency-sensitive, so a GPU that is shared with chat traffic or sized only for a single developer will feel slow within the first day of use. Size the completion model and the chat model separately, load test with the number of developers expected to be active at the same time, and watch queue depth and latency during the pilot. The infrastructure owner, usually platform engineering, should confirm GPU memory headroom for both models and the Tabby Docker example's --gpus all and --device cuda settings on the actual host before any developer is onboarded.

Identity mapping errors at cutover

When developers sign in through LDAP or GitLab SSO, a mismatch between directory usernames, email addresses and GitLab accounts can lock out users or attach their usage to the wrong identity. Export the list of pilot users, compare the attribute Tabby uses for matching against the directory, and test sign-in with a disabled, a renamed and a new account before cutover. The identity owner, usually the team that runs the directory, signs off on the mapping and on who can remove a user when they leave.

Plugin version drift across IDEs

The VS Code, JetBrains and Vim plugins are released on their own schedules, so developers can end up with a server version and plugin versions that do not match. Pin a supported combination in the rollout guide, distribute it through your standard IDE management channel, and report the plugin and server version of each pilot user at the start of each week. The developer experience lead owns the pinned matrix, and the server operator owns upgrade windows so that a server change never lands ahead of the approved client build.

Pilot without a rollback path

Running Tabby alongside Copilot only protects the pilot if developers can return to Copilot in minutes and no team has been told that the old seat is gone. Keep Copilot licenses active until the pilot exit criteria are met, document the steps to disable the Tabby plugin and restore Copilot in each IDE, and agree a review date with finance and procurement. The engineering manager sponsoring the pilot owns the rollback decision, and the procurement lead should confirm the Copilot renewal terms before any seat is removed.

Questions teams ask before moving off GitHub Copilot

What drives the total cost of moving off GitHub Copilot to Tabby?

The total is driven by four components: the Tabby plan, GPU servers or cloud GPUs, model serving and operations, and the engineering time to run and support it. Tabby's pricing page lists Community as free and open source for up to 5 users, Team at $19 per seat per month for up to 50 users, and Enterprise at custom pricing with unlimited users. GPU hardware or cloud GPU rental recurs, while installation and rollout are largely one-time. Ask Tabby for a written quote that separates license fees, support scope and any Enterprise security features from your hardware and staffing costs. Compare that with your current Copilot seats and AI credit usage. See the Tabby pricing page for current plan terms.

How long does a migration from GitHub Copilot to Tabby take?

The timeline depends on GPU procurement, identity integration, repository indexing and how many developers join the pilot. No fixed duration applies to every team, so treat any single figure with caution. Hardware lead time is often the longest step if you need to buy servers. Connecting LDAP or GitLab sign-in requires an identity administrator to approve service accounts and group mappings. Repository indexing time scales with codebase size. Confirm a phased plan with Tabby or DeployOpen in a written scope before work starts, including pilot exit criteria and the cutover date for each team.

What must our team provide before a Tabby rollout starts?

Your team needs to provide three things: GPU capacity, identity administration and repository access. For GPUs, Tabby's README example runs on NVIDIA hardware with --gpus all and --device cuda, using StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat, and the README notes support for consumer-grade GPUs. Confirm with Tabby which model sizes your hardware can serve at acceptable latency. Identity administrators must set up LDAP or GitLab sign-in. Repository owners must grant read access so indexing can run. Also name an owner for the server, the plugin distribution to VS Code, JetBrains and Vim, and the upgrade path.

Can our own engineers run a self-hosted Tabby server without outside help?

Yes, many teams can, provided they have someone comfortable with Docker, GPU drivers, reverse proxies and identity configuration. Tabby is self-contained and does not require a separate database or cloud service, according to its README, which lowers the number of moving parts. The harder work is ongoing: patching the server, updating models, monitoring GPU load and supporting developers during the first weeks. Decide which parts you will own, and whether you want a retainer for upgrades, testing or after-hours support. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your environment under a fixed scope or a retainer.

Should we run GitHub Copilot and Tabby in parallel during the pilot?

Running both during a pilot is the lower-risk approach for most teams. It lets developers compare completion quality on your own code and gives you a fallback if the GPU server is unavailable. The cost is double licensing for the overlap period, so limit the pilot to a defined group and an end date. Track acceptance rates, latency, developer feedback and any data-handling questions from security. Stop Copilot seats only after the pilot criteria are met and the rollback path is tested. Confirm with Tabby how its Community limit of 5 users applies to your pilot group before you start.

Which Tabby security features do we need to confirm before rollout?

Confirm the authentication and access controls that match your policy before developers connect. Tabby's README notes LDAP authentication arrived in v0.24.0 (February 5, 2025) and GitLab SSO in v0.12.0 (June 6, 2024). Its pricing page describes enhanced security and group management on the Enterprise plan, so ask Tabby which controls are included at your user count. Check the Apache-2.0 license scope with Tabby's LICENSE file, because content in the ee directory uses a separate license. Ask about network exposure, logging and how model files are stored and updated. The latest stable release listed on Tabby's releases page is v0.32.0, so confirm your target version.

How does Tabby get repository context, and what should engineers check?

Tabby uses indexed repository content to add context to completions and chat, so the indexing configuration determines answer quality. Engineers should check which repositories are indexed, whether private branches are included and whether sensitive directories are excluded. Confirm with Tabby which repository connectors and sync options apply to your Git host, including GitLab. Test completions on representative files in each language your teams use. Record any cases where suggestions are stale after a merge, and set a re-index schedule that matches how often your main branches change.

Running Copilot and Tabby in parallel during the pilot

Run the pilot as a controlled comparison in which every developer keeps one working assistant at all times and no Copilot seat is removed until the exit criteria below have been met. Split the engineering population into cohorts by team and by workload, such as one cohort on backend services, one on front-end code and one on infrastructure repositories, so that results are not skewed by a single codebase or language. Keep the Copilot licenses active for the full pilot period, including for the cohort that moves to Tabby first. Your procurement and license owner should confirm the notice period and any true-down rules in the current GitHub Copilot agreement before the pilot starts, because changing seat counts mid-pilot can complicate the decommission date. Measure both tools with the same definitions. For acceptance, record how often developers accept inline completions in each editor, and decide in advance whether you will count only accepted tokens or accepted suggestions. For latency, measure the time from keystroke to first suggestion at the workstation, not only server-side response time, because network path and editor plugin behavior both affect what developers feel. On the Tabby side, the server's metrics and logs and the health of the GPU host give you the server view, and the vLLM or Ollama layer is worth tracking separately if you serve models through them. Collect developer feedback through short, structured surveys at fixed points rather than informal reports, and record who is in each cohort so the data can be reviewed later. Define the exit criteria before the first cohort moves. A reasonable set covers acceptance and latency thresholds agreed with the engineering leads, zero unresolved access or sign-in incidents for LDAP or GitLab SSO, successful repository indexing for every in-scope repository, and a support model that the operations team has run for at least one full cycle. Quality is the hardest criterion to set, so agree on a reviewed sample of suggestions per cohort instead of a numeric claim. Decommission Copilot only when those criteria are signed off in writing by the security, engineering and procurement owners, and when the retained audit records you need for your own governance have been exported.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Tabby rollout runs on your GPUs and your network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory which Copilot seats, languages, IDEs and repositories the migration must cover
Agree in writing which Tabby plan, GPU servers and sign-in method are in scope
Define pilot groups, exit criteria and the period in which Copilot and Tabby run side by side

How we build

Size completion and chat model hosting on your GPUs and test response latency with your code
Set up Tabby with LDAP or GitLab sign-in and configure repository indexing for context
Roll out the VS Code, JetBrains and Vim plugins and test them against your developer workstations

How we hand over

Document server configuration, model versions, plugin deployment steps and sign-in settings
Provide runbooks for updating models and Tabby releases through your change process
Walk administrators and developer champions through usage reporting and access administration

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Review Tabby release notes and plan upgrades in a staging environment before production
Confirm with your team which Copilot licenses to cancel once the pilot criteria are met

Migrate from GitHub Copilot to Tabby