Modern ticketing, with source code available
Legal tells the team that ticket data cannot sit in a US cloud. Every help desk product on the shortlist is SaaS-only. So the queue ends up in a shared inbox with a spreadsheet beside it, and the record of who approved what is whatever somebody remembered to write down.
If you are comparing open source ticketing systems, Latch gives you the control those teams are usually seeking: inspectable source, direct access to your data, and a complete product you can deploy in your environment. The interface stays fast and focused while tickets, models, identity, and operator feedback stay inside your boundary.
The queue and everything filed against it live in a Postgres database your team administers, on storage your team owns.
Triage, routing, and summarisation run against inference inside your network. No ticket text is sent to a vendor endpoint.
Authentication runs over OIDC against your own identity provider. Latch never becomes a second copy of your user directory.
Every approval, denied attempt, and plugin result is written locally and exported by your team, on your schedule.
Nothing, by default. Your team pulls release artifacts when it chooses to upgrade.
A shared inbox is not a queue
Teams under residency rules rarely choose the mailbox. They arrive at it because the products that do ticket routing, SLA management, and escalation policy properly are all hosted somewhere they are not allowed to send data. The same gap shows up in ITSM and issue tracking, where the credible options are cloud-only by design.
- Two people answer the same message because nothing marks a ticket as owned.
- Priority lives in a spreadsheet column that is accurate on Monday and stale by Wednesday.
- Approval for a sensitive change happens in a forwarded email, so the control exists only as a habit.
- SLA management is a person scanning timestamps by eye and hoping the breach has not happened yet.
- When an auditor asks who approved a vendor bank-detail change in March, the answer is rebuilt from three mailboxes and a memory.
Source available, with a clear licence
People searching for open source ticketing usually want three things: code they can inspect, software they can extend, and a product they can run in their own environment. Latch provides those controls on Enterprise.
Inspect what runs
Source code is available to Enterprise customers. Security and platform teams can review the code that handles tickets, permissions, plugins, and audit evidence.
Extend the workflow
Build plugins in TypeScript or Go, connect internal systems, and adapt the deployment without waiting for a hosted vendor to add the integration.
Keep operational control
Run the application, database, attachments, workers, identity, and model endpoint in your environment. You choose the region, release schedule, backup policy, and network boundary.
Source code is available on Enterprise. Teams can inspect and extend the product they run, keep direct access to their data, and build integrations against documented APIs and SDKs.
If your team describes this requirement by deployment model, see self-hosted ticketing for the operating boundary and responsibilities.
Three shapes, one build
The same release runs in all three. Triage, ticket routing, workflow automation, approvals, and the audit trail behave identically whether the host has full internet access or none.
Your infrastructure, your rules
Run the containers on infrastructure you control, under Kubernetes or Docker, against the Postgres service your team already operates. The product does not depend on a public cloud being reachable.
Your account, your region
The same containers in your AWS, Azure, or GCP account, inside your VPC, with your KMS keys and your backup policy. Data residency is decided by which region you deploy into, not by a vendor roadmap.
No outbound network at all
Container images, model weights, and release notes arrive as signed artifacts your team imports through whatever transfer process you already use. The running system makes no outbound calls.
Residency is a deployment decision, not a support ticket
With hosted help desk software, data residency is whatever regions the vendor has opened, and moving between them is a migration project you do not control. Here it is the address of the machine you installed on.
The same applies to retention and deletion. Backups, legal hold, and destruction run under your existing policy, against a database your team can query. The security and deployment model covers identity scoping, environment separation, and how the boundary is enforced.
The queue sharpens on your tickets, on your hardware
Most systems that learn from your data require you to hand over your data first. This one does not. When an operator reassigns a misrouted ticket, overrides a suggested priority, or rejects a proposed action, that correction is training signal written to your database.
Suggestions improve because your operators corrected them, not because a vendor shipped a model update. The system learns which escalations your team actually raises and stops surfacing the ones they never do. Unified triage is where that shows up first.
OIDC against the directory you already run
Latch authenticates over OIDC against your identity provider, including one with no public endpoint. Group membership maps to roles, so a leaver loses queue access and approval rights the moment the directory says so.
There is no separate password store to inherit, and no shared service account standing between an operator and a sensitive action. The person who approved a change is a real identity from your directory, recorded on the ticket.
You decide when the version changes
Releases are versioned container images with forward migrations. Your team promotes a release through staging, runs the migration, and rolls back to the previous image if the change misbehaves. Nothing upgrades itself overnight.
That control has a cost, and it is worth naming: staying current is now your operational responsibility. Teams that skip six releases pay for it at the seventh.
When deploying in your environment is worth it
A six-person support team with no one who administers Postgres should not run its own help desk. Deploying in your environment hands you the backups, certificate renewals, capacity planning, and the 2am page when queue workers stop. A managed service absorbs that work, and for many teams that trade is correct.
Customer-controlled deployment earns its cost when something forces the boundary: a residency rule, a sector regulator, a classified network, a customer contract that names where data may sit, or an internal policy that keeps ticket content away from third-party models. If none of those apply to you, the boundary is overhead.
If they do apply, the next question is usually cost and shape. Pricing is not per agent, so putting the whole queue in one place does not get more expensive as the team grows, and the operations path shows what the day looks like once the queue moves out of the mailbox.
Follow the control path from intake to evidence
These pages work together: intake shapes the ticket, approvals gate sensitive actions, maker-checker enforces independence, security controls the deployment boundary, and auditability preserves the proof. The claims use case shows the controls assembled end to end.
Enforce separation between the person preparing an action and the person approving it.
Route sensitive actions through role checks and approval gates before they run.
Plan a review route that considers the request and wider exposure against a configured limit.
Keep decisions, blocked attempts, approvals, and action results on the same record.
Deploy where ticket data, identity, and the AI models you choose stay inside your environment.
Bring email, forms, alerts, and system events into one ticket queue before actions begin.
See the controls assembled for claims work: checklist-driven file reviews, maker-checker, and upstream execution proof.
Questions infrastructure and security teams ask first
What buyers under residency, air-gap, or model-governance rules want answered before a deployment conversation starts.
Is Latch open source?
Source code is available to Enterprise customers. Teams can inspect and extend what runs, build plugins, and deploy the complete product in their environment.
Can the complete product run in our environment?
Yes. Latch ships as container images and database migrations that your team runs on infrastructure it controls. There is no vendor-held database and no vendor access to the environment unless you grant it for a support session.
Does the AI work with no internet access?
Yes. Triage suggestions, routing, and summarisation run against inference inside your network, using open-weight models you host or an inference endpoint you already operate. In a disconnected-network deployment, model weights are imported as artifacts alongside the release. If you would rather point at a commercial model API, that is a configuration choice, not a requirement.
What has to leave the network?
Nothing for the system to run. Your team pulls release artifacts, and outbound email or webhook delivery goes wherever you configure it. Licence checks do not require a callback, so a disconnected-network deployment keeps working when it cannot reach anything.
How does identity work if we cannot use a cloud IdP?
Latch authenticates over OIDC against whichever identity provider you run, including an internal Keycloak or ADFS with no public endpoint. Group membership maps to roles, so joiners and leavers are handled where you already handle them, and approval permissions follow the same directory.
What does the learning loop do with our tickets?
Every triage decision, approval, reject, and correction an operator makes is training signal, and it is written to your database. The models that suggest routing and next steps are fitted on that signal inside your environment. The improvement stays with you, and it does not travel back to improve a shared vendor model.
Who should not deploy Latch themselves?
A small team with no one on call for Postgres, backups, and TLS certificates. Running Latch in your environment makes upgrades, restores, capacity, and incident response your responsibility. If no residency or disconnected-network rule requires that control, a managed help desk may be the cheaper answer.
See a ticket move end to end inside a closed boundary
Walk through intake, triage, approval, and the audit trail on a deployment where nothing leaves the network. Bring one queue you are not allowed to put in a cloud.