Choose GitHub Copilot or self-hosted Tabby: when each fits
If your team is facing a GitHub Copilot renewal, a rule that source code may not leave your environment, or a plan to stop paying per seat, the choice turns on four questions. Where may source code and prompts travel? GitHub Copilot is a hosted service, so code context is sent to it, while Tabby runs on servers you control. Who will operate the GPUs? With Copilot, GitHub runs the service; with Tabby, your platform team owns the hardware, model serving, upgrades and uptime. Which model quality does the team need? Tabby's documented Docker example uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat, which are small models, so confirm that they meet your developers' expectations before you commit. Which admin and SSO features are required? Check them against the plan you need.
Copilot fits well when source code can reach a hosted service under your existing agreements, when you want vendor-managed operations and the broadest set of AI features that GitHub ships, and when per-seat pricing is easier to budget than GPU capacity. Tabby fits when code residency is a hard requirement, when you already run GPU infrastructure or accept operating it, and when you want the completion and chat models to stay under your control. Ask GitHub to confirm in writing how Copilot handles code context, retention and telemetry for your plan, and ask your own security team to confirm the data classification that applies to your repositories.
On the Tabby side, confirm the license split before you plan. Tabby's LICENSE file places everything outside the ee/ directory under Apache 2.0, and content in ee/ falls under its own license, so check which features your edition needs and whether your admin and SSO requirements depend on ee/ code. Tabby's pricing page lists Community as free for up to 5 users, Team at $19 per seat per month for up to 50 users, and Enterprise at custom pricing. LDAP sign-in arrived in v0.24.0 and GitLab SSO in v0.12.0, so verify that your identity setup is covered by the release you intend to run. Tabby's latest stable release is v0.32.0 on its releases page, and you should pin a version and test upgrades in a pilot first.
Which option fits each buying scenario
This table matches common buying situations to the option that usually fits better, with the reason tied to hosting, plan limits and operating effort. Read each row against your own constraints, and treat the reasons as the questions to confirm with vendors before you decide.
| Scenario | Better fit | Why |
|---|---|---|
| Source code must stay inside our network | Tabby | Tabby runs on servers you control, so completions and prompts do not need to leave your environment. GitHub Copilot is a hosted service, so you must confirm its data handling terms against your residency rule. |
| No one on the team operates GPUs | GitHub Copilot | Copilot needs no model serving or GPU capacity from your staff. Tabby shifts GPU provisioning, model updates and uptime work onto your platform team. |
| Developers sign in through GitLab or LDAP | Tabby, confirm plan | Tabby documents GitLab SSO and LDAP authentication, added in v0.12.0 and v0.24.0 respectively. Check which of these your chosen Tabby plan includes before you rely on them. |
| Pilot with a team of five or fewer | Tabby Community | Tabby's pricing page lists Community as free and open source for up to 5 users. Confirm current limits on the pricing page before the pilot starts. |
| Large developer population | Confirm both options with a quote | Tabby's Team plan covers up to 50 users, and Enterprise is priced for unlimited users with custom pricing. Ask both vendors for a written quote based on seat count, GPU capacity and support terms. |
| Isolated or air-gapped network | Tabby | Copilot depends on a hosted service that isolated networks cannot reach. Tabby can run with locally stored models on isolated GPU servers, with updates moved in through a controlled path. |
What the Apache-2.0 core and the ee directory mean for licensing
The Tabby LICENSE file splits the repository in two. Content in the ee/ directory falls under its own license, found in ee/LICENSE. Third-party components keep the licenses their authors chose. Everything else is available under the Apache 2.0 license. Before you deploy, treat that split as the first thing to verify, because the boundary is set by the files in the repository and the terms that ship with them, not by the marketing name of a plan.
When you review the repository, list every feature your rollout depends on and trace each one to a path. Check whether it lives in ee/ or in the Apache 2.0 portion. Pay particular attention to authentication, group management and admin functions, since the Tabby pricing page ties enhanced security and group management to its Enterprise plan. Then read ee/LICENSE in full and confirm what it permits for internal use, modification and redistribution. Also review the license of each bundled third-party component, including the models you intend to serve, since model terms are separate from the server license.
Ask counsel to answer specific questions rather than to review Tabby in general. Does your intended use of ee/ code fall within the grant in ee/LICENSE? Do your engineers modify or redistribute Tabby, for example in a forked container image? Are any plugin or model licenses incompatible with your internal policies? Record the answers alongside the version you tested, because the ee/ contents and terms can change between releases. Pin a release for the pilot, and repeat the review before each upgrade. If a dependency turns out to sit in ee/ and your counsel does not accept its terms, the cost of that finding is a plan or architecture decision, so raise it before you size hardware or sign any commercial agreement.
Keep the licensing review separate from the question of whether a feature is worth paying for. A feature in ee/ may be available under a commercial agreement, while a feature in the Apache 2.0 core can be used under the open terms. Your decision should rest on the written license for each component, not on the plan label. Confirm with Tabby which terms apply to your deployment before you rely on any ee/ capability in production.
How GitHub Copilot and Tabby compare capability by capability
This table compares GitHub Copilot with self-hosted Tabby across hosting, data flow, model choice, IDE coverage, integration, GPU needs, sign-in options and licensing. Read the Tabby column as supplied facts and the Copilot column as areas to confirm with GitHub, since its coverage changes over time. Gaps are marked as gaps, not hidden.
| Capability | GitHub Copilot | Tabby (self-hosted) |
|---|---|---|
| Hosting model | Hosted by GitHub as a per-user service with usage-based AI credits for agent and chat use | Self-hosted server you run on your own GPUs, self-contained with no DBMS or cloud service required |
| Where code and prompts are processed | On GitHub's hosted service; confirm current data handling terms and retention in GitHub's documentation | On servers you control, so code and prompts stay inside your network if you deploy it that way |
| Model choice | Models selected by GitHub; confirm which models and providers are offered for your plan | Choose your models; the README example uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat |
| IDE plugins | Broad IDE coverage; confirm the current list for your editors on GitHub's documentation | Plugins for VS Code, Vim and IntelliJ, and a JetBrains Marketplace listing |
| OpenAPI integration | Not a documented self-hosting integration point; confirm with GitHub | OpenAPI interface for connecting to existing infrastructure such as Cloud IDEs |
| GPU support | Not applicable to the customer; GitHub runs the inference | Supports consumer-grade GPUs; the Docker example uses --gpus all and --device cuda |
| SSO and directory sign-in | Enterprise identity features depend on the GitHub plan; confirm the supported providers | LDAP authentication added in v0.24.0 (February 5, 2025); GitLab SSO added in v0.12.0 (June 6, 2024) |
| Licensing | Proprietary, subscription-based service | Apache 2.0 for the core; content in the ee/ directory is under its own license in ee/LICENSE |
Where code, prompts and logs live under each option
A hosted coding assistant and a self-hosted Tabby server answer the same question in different places: who receives the code, who stores the prompts, and who keeps the logs. The cards below separate what the vendor documents from what your own environment must provide, so you can check each claim against your own build.
Where code leaves your network
With GitHub Copilot, completion requests and chat context are sent to GitHub's hosted service, so the code in a suggestion request leaves your devices and network. With Tabby, requests go to a Tabby server you run, and the code stays inside your network if you deploy it there. Confirm the exact data flow for your Copilot plan and IDE with GitHub, and confirm that your Tabby clients point only at internal addresses.
Who holds the model and its logs
A hosted assistant's model, request handling and retention settings belong to the vendor, and you rely on its documented controls. With Tabby, you choose the model, such as the StarCoder-1B and Qwen2-1.5B-Instruct defaults shown in its Docker example, and you decide where the server logs go, how long they are kept and who can read them. Those choices are yours to write down and enforce.
Prompt and retention controls
Ask GitHub Copilot's vendor for written retention terms covering prompts, suggestions and telemetry for your plan, and for the admin controls available to you. Tabby keeps no retention policy for you by default, so the retention of its logs, indexed repositories and chat history depends on how you configure the server and its storage. Document that setting before the pilot starts.
Identity integration and access
Copilot access is tied to GitHub organization and seat management. Tabby can connect to your directory: its README notes LDAP authentication from v0.24.0 and GitLab SSO from v0.12.0, while SSO and group management depend on the Tabby plan you choose. Check which sign-in methods your plan includes, and confirm that offboarding removes a user's access to the server.
Audit and compliance evidence
Certifications and audit reports belong to the service that is audited. Ask GitHub for its current audit reports and scope documents for Copilot. For Tabby, your evidence is what your environment produces: access records, server configuration, backup and change logs. DeployOpen prepares these controls and evidence for assessment, but independent auditors and certification bodies issue any audit report or certification.
Network isolation and offline operation
A hosted assistant needs outbound connectivity to its service, so isolation is limited to what the vendor allows. A self-hosted Tabby server can run on an internal network with locally stored models and no outbound dependency, but only if you design the update path for models and plugins. Test the server with outbound traffic blocked before you rely on that claim.
Which Tabby plan gives admins the SSO and group controls they need
The Community plan is listed on Tabby's pricing page as free and open source for up to 5 users. It suits a small pilot team that wants to test code completion and chat on its own GPUs before any procurement decision. The core server is available under the Apache 2.0 license, so teams can review the code and run it without a license fee. Sign-in options available at this tier are the first thing to confirm, because the README records LDAP authentication arriving in v0.24.0 (February 5, 2025) and GitLab SSO in v0.12.0 (June 6, 2024).
- User ceiling: The free tier applies only up to 5 users, so a wider rollout will need a paid plan.
- Sign-in methods: Confirm on the pricing page whether LDAP and GitLab SSO are included at this tier.
- Group management: Check whether group-based access controls are part of this plan or reserved for higher tiers.
- Support: Community use relies on public documentation and repository channels unless a support agreement is added.
- Operations: Your team still runs the GPU servers, updates and backups.
Before relying on this tier, confirm the current feature list and user limit on the pricing page and in the release notes for the version you plan to deploy.
The Team plan is listed at $19 per seat per month for up to 50 users. It is the tier most likely to fit a single engineering group that needs a shared server, more users than the free tier allows and predictable per-seat billing. Because the price is per seat, cost scales with headcount, and a mid-sized group can compare that recurring figure directly against Copilot seats. The plan is priced for a bounded group, so admins should verify which identity and access features it includes before committing.
- Seat pricing: The listed rate is $19 per seat per month, billed for up to 50 users.
- Seat growth: Each added developer adds a recurring charge, so the total grows linearly with headcount.
- Identity features: Confirm whether LDAP and GitLab sign-in are included at this tier.
- Hardware cost: The subscription does not cover GPU servers, power or model hosting, which remain your costs.
- Renewal terms: Ask the vendor how seats are counted when users join or leave during a term.
If your group is near the 50-user boundary, ask Tabby how seat changes are handled mid-term and whether a move to Enterprise is prorated.
The Enterprise plan uses custom pricing with unlimited users and includes enhanced security and group management, according to the pricing page. It is the tier to evaluate when admins need controls across many teams, formal security review and a contract that covers the full organization. Pricing is quoted case by case, so the commercial conversation should start from your user count, deployment shape and required features. Ask for the feature list in writing, because the public page describes these controls only in general terms.
- Scale: Enterprise is described with unlimited users, which matters for organization-wide rollouts.
- Security controls: Ask for a written description of the enhanced security features included.
- Group management: Confirm how groups map to repositories, permissions and usage reporting.
- Contract terms: Request support levels, update policy and data handling terms in the agreement.
- Deployment: Confirm whether the Enterprise license covers air-gapped or offline installs.
Before signing, request a written feature matrix that maps each SSO, LDAP, audit and group control to the plan that includes it, and confirm it against the current pricing page.
What drives the cost of each option over time
Copilot and Tabby cost different things and charge them to different budgets. Copilot is a recurring per-user and usage charge, while a self-hosted Tabby stack moves cost into plan fees, GPUs, staff time and support, some one-time and some recurring.
Copilot seats and AI credits
Copilot is sold per user, and agent and chat work draws on usage-based AI credits on top of the seat. This is a recurring cost that grows with headcount and with how heavily developers use chat and agent features. Ask the vendor which Copilot plan your developers would need, how credits are metered, and whether credit consumption is capped or billed as overage. Model the cost against your actual usage, not the seat price alone.
Tabby plan fees by seat band
Tabby's public pricing lists Community as free 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. The fee recurs and steps up as your seat count crosses a band, so the seat count you forecast for the next two years matters more than today's headcount. Confirm which features, including LDAP and GitLab sign-in, sit in each plan before you choose a tier.
GPU servers or cloud GPUs
Tabby runs on hardware you provide, so GPU capacity is the largest infrastructure line. You can buy on-premises servers, which is mostly a one-time capital cost plus recurring power and cooling, or rent cloud GPUs, which recur monthly. Utilization drives the economics: idle GPUs are paid for whether or not developers use them. Ask your hardware or cloud vendor for sizing that matches your completion and chat model choices and your peak concurrent users.
Model serving and updates
Model hosting is a recurring operations task. You choose and download completion and chat models, test them against your code, and update them as better models appear, and each change needs regression checks in your environment. The Tabby README's example uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat, but larger models change the GPU bill. Budget engineering time for evaluation and rollouts, not only for the first install.
Operating staff and on-call coverage
Someone in your organization owns uptime, GPU driver and container updates, access reviews, and incident response for the Tabby server. This is a recurring labor cost that Copilot avoids because GitHub runs the service. Estimate it as a share of existing platform or DevOps roles, and check who covers evenings and weekends if developers depend on completions during working hours. Ask whether your team has GPU operations experience or will need training.
Setup, pilot and support retainers
Setup, the pilot, sign-in integration and repository indexing are mostly one-time costs, though a pilot can run alongside Copilot and add to the bill for a period. Ongoing support, upgrades and testing can be bought as a retainer, which recurs. Request a fixed-scope quote listing deliverables, the environments covered, and what happens after go-live, so you can compare it with the internal effort it replaces.
What moving developers from Copilot to Tabby involves
The sequence moves developers from a hosted assistant to a Tabby server on your own GPUs in phases, so each decision about hardware, identity and rollout is made before any seat is retired.
Inventory IDEs and developer groups
Start by listing which editors and versions developers use, such as VS Code, JetBrains IDEs and Vim, and which teams depend on Copilot for completion, chat or agent work. Map each group to the Tabby plugin it needs and note any group whose workflow relies on features Tabby may not match. The owner is the platform or developer productivity lead, working with engineering managers. The step is done when every group has a named editor, a named use case and a named contact for the pilot.
Size GPUs for completion and chat
Decide where Tabby will run and what hardware it needs for code completion and for the chat model, since these workloads have different demands. The Tabby README example uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat, but your production models and concurrency will drive the final sizing. Ask your infrastructure team to confirm GPU type, memory, redundancy and where the servers sit relative to your source code. The step is done when you have a written hardware plan that has been reviewed by security and operations. Detailed sizing belongs in the migration guide.
Deploy Tabby on your infrastructure
Install the Tabby server using the Docker approach shown in its README, which runs the server with GPU access and loads the completion and chat models. Keep the server inside your network, confirm that models are stored locally, and check that outbound traffic from the server is limited to what your policy allows. The owner is the platform team. The step is done when the server responds to test requests from a workstation on the target network and the model files are recorded in your configuration management system.
Connect identity and sign-in
Connect Tabby to your directory before wider rollout so access follows the same joiner and leaver process as other internal tools. The Tabby README lists LDAP authentication and GitLab SSO as available options, and your plan level determines which admin and SSO features you receive. Confirm the exact features of your chosen plan with Tabby before you design the integration. The step is done when test accounts sign in, a removed test account loses access, and the group mapping matches your existing directory structure.
Roll out editor plugins to a pilot group
Install the VS Code, JetBrains or Vim plugin on a small set of developer machines, then point each plugin at your internal Tabby endpoint. Collect feedback on suggestion latency, acceptance rate and any editor-specific issues, and document the configuration steps that work for your standard desktop image. Your developer tooling team owns this step with pilot volunteers. The step is done when pilot developers can complete their normal daily work with Tabby and the install steps are written down for the wider rollout.
Index repositories for context
Connect the repositories that Tabby should use for context so suggestions reflect your internal code and conventions. Decide which repositories are in scope, who approves access, and how removed or archived repositories are excluded from the index. Confirm with Tabby how indexing handles access controls, since code visibility should match what each developer is already allowed to read. The step is done when the agreed repositories are indexed, a sample of suggestions has been reviewed, and the access decision is recorded.
Run Tabby and Copilot side by side
During the pilot, keep Copilot seats active for the pilot group while developers use Tabby for their day-to-day work. Compare suggestion quality, responsiveness and workflow fit against the criteria agreed in the inventory step, and log cases where one tool clearly does better. Your engineering leadership and security team review the results together. The step is done when the pilot results are written up and the go or no-go decision is recorded with the people who approved it.
Retire Copilot seats in phases
After the pilot is approved, move remaining developer groups to Tabby in batches and remove their Copilot seats only after each batch has signed off. Check that no team still depends on a Copilot-only feature, and confirm with your procurement team the notice terms and billing changes that apply to your Copilot subscription. The step is done when all planned groups run on Tabby, Copilot seats are removed from your organization, and the operations runbook covers upgrades, model changes and support contacts.
Questions buyers ask before switching from Copilot to Tabby
What does switching from Copilot to Tabby cost, and what drives the effort?
The switch has two cost groups: the subscription or license you stop paying for, and the infrastructure and people you start paying for. On the Copilot side, you pay per user and for any AI credits used by chat and agent features. On the Tabby side, the software is Apache-2.0 for the core, with Community, Team and Enterprise plans for the ee directory features, so you need to check which plan covers your needs. The larger items are GPU servers or cloud GPUs, model serving, staff time to deploy and maintain the stack, and support. Effort rises with the number of developers, IDEs in use, identity integration, and how much repository context you want indexed. Ask for a written quote that separates one-time setup from recurring infrastructure and support. Confirm current plan terms on the Tabby pricing page.
How long does a Copilot to Tabby pilot usually run?
The pilot length depends on scope, so no fixed duration applies to every team. The main drivers are the number of developers in the pilot, whether GPU hardware already exists, how many IDEs need plugins, whether LDAP or GitLab sign-in must be connected, and how much repository indexing is required. Running Copilot and Tabby side by side during the pilot is common, because it lets engineers compare suggestions on their own code before anyone's license changes. Ask for the pilot duration, exit criteria and the milestones in a written scope before work starts. Fixed-scope engagements from DeployOpen are agreed in writing, so the timeline should appear there rather than in a general estimate.
What does the work need from our own staff?
Expect involvement from several groups. Platform or infrastructure staff provision the GPU hosts or cloud GPU instances, container runtime and networking. Identity staff connect LDAP or GitLab sign-in, which Tabby's README lists as available in v0.24.0 (February 5, 2025) for LDAP and v0.12.0 (June 6, 2024) for GitLab SSO. Security staff review where code, prompts and logs are stored and who can access them. Engineering leads choose the completion and chat models and roll out the VS Code, Vim or IntelliJ plugins. Someone also needs to own upgrades, since Tabby's latest stable release is listed on its releases page as v0.32.0. Agree on named owners for each group before the pilot begins.
Can an internal team switch to Tabby without outside help?
An internal team can do it if it already runs containers, GPU servers and an identity provider, and has time to test models and plugins. Tabby is self-contained and its README describes an OpenAPI interface and Docker-based setup, which keeps the first deployment small. The harder work is operational: sizing GPUs for completion and chat models, keeping models and plugins current, monitoring the service, and handling developer support. If those skills or hours are not available, an implementation partner can take on part of the scope under a written, fixed-scope agreement, or a retainer can cover ongoing upgrades and support. Be clear about which parts your team keeps.
Does Tabby need a database to run?
Tabby's README describes it as self-contained with no need for a DBMS or cloud service, so a separate database server is not a standard prerequisite. Engineers should still confirm the current deployment requirements in the repository, including storage for indexes, logs and downloaded models, and any optional components used by enterprise features. Plan disk capacity for model files and repository indexes, and back up the data directory that Tabby writes to. Check the Tabby repository for the current configuration and storage layout before you size the host.
Can Tabby run on an isolated network with no internet access?
Tabby is designed to be self-hosted and self-contained, so it can run on infrastructure you control, but air-gapped operation needs checking before you commit. The core question is how models and plugin updates reach the isolated servers. Plan a controlled path to move model files, container images and editor plugin packages in, and confirm which features still call external services. Enterprise-only features under the ee directory are governed by a separate license, so verify their behavior and terms with the vendor. Validate the design in a test environment before depending on it for restricted source code.
How does Tabby's code quality compare to Copilot on our own hardware?
Quality depends on the model you choose, the GPU it runs on, and your codebase, so no general claim is reliable. Tabby's README example uses StarCoder-1B for code completion and Qwen2-1.5B-Instruct for chat, which are small models chosen to run on consumer-grade GPUs. Larger models usually need more GPU memory and produce different results. Copilot runs on a hosted model that you do not select or host. Run a blind comparison on representative tasks from your own repositories, measure acceptance rate and latency on your hardware, and test several model sizes. Record the results in writing before you decide.
How DeployOpen helps evaluate, implement or migrate Tabby
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For GitHub Copilot vs Tabby, we start with a written scope that fits your GPUs, identity setup and developer tooling, so the decision rests on your own environment rather than a generic comparison.
How we scope
- Inventory which repositories, IDEs and developer groups would use the assistant during the evaluation.
- Map where source code and prompts would be processed, and confirm the hosting boundary with your security team.
- Confirm which Tabby plan and identity options match your user count and sign-in requirements.
- Agree deliverables, timelines and acceptance criteria in writing before any work begins.
How we build
- Size and install a Tabby server on your GPUs or cloud GPU accounts, with models chosen and tested against your code.
- Configure the VS Code, JetBrains and Vim plugins and connect LDAP or GitLab sign-in where your plan supports it.
- Run a side-by-side pilot with Copilot so completion quality and latency are measured on your own projects.
- Harden the server, network access and logging, and document the configuration as it is built.
How we hand over
- Deliver runbooks for installing, upgrading and rolling back the Tabby server and its model files.
- Document the admin, access and retention settings, plus the evidence an assessor would ask to see.
- Train your platform and engineering staff to operate the server, plugins and GPU capacity.
- Provide a cost model listing licenses, hardware, hosting and staff time as separate line items.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- Review each Tabby release before rollout, including plugin compatibility and model changes.
- Track GPU utilization and capacity so you know when to add hardware or change models.
- Keep the written scope current when your developer count, plan or identity setup changes.
