Thirp Cloud for Support
Reach the service you cannot get to—with the customer's approval.
Thirp Cloud for Support lets a support engineer connect to one named private Service in a customer environment. The customer grants a bounded window, can end it immediately, and keeps an audit of who connected. No inbound port on the customer's network required. Thirp relays the session without storing or recording application payloads.
Request a pilot See how it works
Not ready for a pilot? Tell us about your support-access problem.
See the current pilot in action
In 96 seconds: one named private service, customer approval in the console, a live diagnostic connection, immediate revocation, and a filterable audit trail.
Pilot preview. Recorded on an internal test bench running the working pilot system. The terminal shot abbreviates the managed thirp connect command for clarity; the console request, approval, grant, revocation, and audit controls shown are the real pilot workflow.
-
A named Service
Publish
criticalservice.api, not the subnet. Knowing the name is not permission. -
A real approval
The customer controls the policy. They may approve each request, or expressly let the vendor approve bounded requests with audit they can revoke. Stop ends the live connection.
-
A durable record
Record who, which Service, when, and how long—not the session payloads.
The scene you already know
The ticket is real. The deployment is behind the customer's firewall. A VPN into the whole site is a non-starter, and screen sharing does not let the engineer use the tools that can diagnose the real service. You do not need the customer's network. You need one service, for a bounded time, with the customer holding the switch.
Example: a transaction service behind two DMZs
You ship software that talks to a transaction process on an application server in the customer's data center—sometimes a database listener on the same host, two DMZs in from the internet. Overnight the batch window slips. Your engineer needs the admin or query port on that one process. Not a desktop. Not the subnet.
Their rule is: submit a firewall ticket. You file it. They ask for your ingress address. You do not have a stable one, or you do and it still waits for tomorrow's change window. The ticket comes back "use the VPN," which is a non-starter because it will not route to that DMZ, or it comes back approved a day later for a jump host you cannot use with the tools that can actually see the service.
The Service is up. You still cannot get to it. Thirp can.
Four steps
- Enroll
thirp-agentin the customer Environment; it connects outbound. - Publish the named Service the vendor may support.
- Request access; the customer Approver grants a bounded window, or the vendor decides only under an express customer delegation.
- Connect with the Thirp CLI; expiry or revocation closes the connection.
Design partners
Thirp is inviting a small number of vendors who already support software or appliances in customer-controlled environments. Admission is selective. A request is a conversation, not a signup and not a purchase.
Request a pilot Read the pilot exchange
Not ready for a pilot? Tell us about your support-access problem.
Same Runtime. Managed Support workflow.
Thirp Runtime is the open-source relay, Agent, CLI, and embeddable SDK. Run it yourself with file-backed policy or incorporate it into your product.
Thirp Cloud for Support uses the same Runtime Agent and data plane, adding managed identity, customer approvals, bounded grants, audit, and hosted operation.