GitLab is rebuilding Service Desk. Here's what it means for your team.

GitLab Service Desk has been one of GitLab’s most quietly useful features for years. The concept is simple: a unique email address per project, customer emails become confidential issues, your team replies from inside GitLab, and customers never need to create an account. It is the kind of feature that, once you have it, you wonder how you worked without it. Recently, GitLab added a notice to the Service Desk documentation that has raised questions: the feature is “not under active development.” This post explains what that actually means, what GitLab’s plan is, and what teams on GitHub — where no equivalent exists natively — can do today.

What GitLab Service Desk does

Every GitLab project can be given a unique, auto-generated email address. When a customer emails that address, GitLab creates a confidential issue from the message — visible only to project members, not the wider issue tracker. Your team replies from inside GitLab, either through the issue itself or by email, and the customer only ever sees email. They never need a GitLab account, never see the issue tracker, and never know their message became an issue. It has been available on GitLab Free, Premium, and Ultimate since GitLab 9.1.

What “not under active development” actually means

GitLab added a notice to the Service Desk documentation stating the feature is deprioritized so the team can focus on the work item framework — a broader rebuild of how GitLab handles all work items (issues, epics, tasks, and more).

A few things worth being precise about:

• This is not a removal. Service Desk still works today. Community contributions are still accepted, even while the core team isn’t actively adding features.
• GitLab’s plan is documented in Epic 10772 (“Service Desk: Migration to Work Items”). The goal is to migrate Service Desk tickets into a new Ticket work item type inside the work item framework.
• Progress has already been made. GitLab 17.6 shipped external participants via quick actions. GitLab 17.7 added the Requestor widget. GitLab 17.8 is scheduled to migrate existing Service Desk issues to the new Ticket type.
• The broader work item framework migration timeline runs through early 2026.

Bottom line: Service Desk is being rebuilt, not killed. But it’s in an extended transition where new features are paused, known bugs may go unresolved for longer than usual, and the interface itself is going to change as tickets move onto the new Ticket type.

What this means in practice

If you’re actively using GitLab Service Desk today, it continues to work — there’s no need to migrate anything right now. But the transition period creates real friction: bugs may take longer to fix, the feature set is effectively frozen, and the upcoming migration to Ticket work items will change how the feature behaves and looks.

Teams evaluating GitLab for a new project should treat Service Desk as a feature in flux rather than a stable foundation to build a support process on.

For teams already on GitHub, this is a good reminder that GitHub has never had an equivalent feature. A GitHub community discussion asking for something like Service Desk has sat unanswered for years. If your team uses GitHub and needs email-based customer support that integrates natively, you have to look outside GitHub itself.

What GitHub teams can use instead

For GitHub users who want the Service Desk pattern — email in, issue created, reply by email, no customer accounts required — Scitor is a GitHub App built specifically for this. It adds what GitHub doesn’t have: a unique support email address, email-to-Issue creation, AI triage labels, and /send for replying. Where GitLab Service Desk is the basic mechanic, Scitor adds SLA tracking, CSAT, a knowledge base built from Markdown docs, and an optional web dashboard. There’s a free plan, and it installs in under 5 minutes.

GitLab’s work item framework is a meaningful architectural improvement that will eventually make Service Desk better. The current deprioritization is a side effect of doing foundational work correctly rather than patching on top of aging infrastructure. For teams on GitLab, patience is the right call. For teams on GitHub, the gap has always been there — and the options to fill it are getting more mature.