Self-hosted ticketing that runs on your infrastructure
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.
Latch Workflow installs inside your own boundary: on-prem, in your private cloud, or air-gapped. Tickets, attachments, the models that suggest routing, and identity all stay there. So does the training signal your operators generate every day.
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.
What self-hosted means here
The word has been stretched far enough that it needs a definition before it means anything. Three things are commonly sold as self-hosted and are not.
A hosted trial behind a VPN
A private network path into a vendor cloud is still a vendor cloud. The ticket data sits in a database the vendor owns, under whichever jurisdiction the vendor operates in, and the VPN changes only who can reach it.
Single-tenant SaaS relabelled as private
A dedicated instance in the vendor account is an isolation claim, not a residency claim. The vendor still holds the keys, the backups, and the subpoena exposure.
An on-prem app that calls out for the AI
Plenty of products install locally and then post ticket text to a hosted model endpoint for triage. That is the exact data flow a residency rule exists to prevent.
Every part of the system runs on hardware you control: the application, the database, object storage for attachments, the background workers that process the queue, and the inference that produces suggestions. A ticket, or a case if you work in a regulated function, is created, worked, approved, and closed without a packet crossing your perimeter.
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 servers, your racks
Containers on your own hosts, under Kubernetes or Docker, against a Postgres instance your DBAs already run. An on-premise install assumes nothing about 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.
Who should not self-host
A six-person support team with no one who administers Postgres should not run their own help desk. Self-hosting hands you the backups, the certificate renewals, the capacity planning, and the 2am page when the queue workers stop. A cloud service desk absorbs all of that, and for most teams that trade is correct.
Self-hosting 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.
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.
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.
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 this actually self-hosted, or a private instance you operate for us?
Actually self-hosted. Latch ships as container images and database migrations that your team runs on your infrastructure. There is no control plane phoning home, 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 an air-gapped install, 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 an air-gapped install 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 self-host this?
A small team with no one on call for Postgres, backups, and TLS certificates. Self-hosting moves real operational work onto your side: upgrades, restores, capacity, and incident response for the ticketing system itself. If no residency or air-gap rule forces the boundary, a cloud help desk is the cheaper answer and you should take it.
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.