Get AI summaries of any video or article — Sign up free
host your own HelpDesk thumbnail

host your own HelpDesk

NetworkChuck·
4 min read

Based on NetworkChuck's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Turn informal IT requests into structured tickets so issues have owners, urgency, and a history of actions.

Briefing

A simple rule—“Do you have a ticket?”—is the starting point for building a self-hosted help desk for family, friends, or a small team. The core idea is to turn everyday IT requests (a printer that won’t print, Netflix not loading, a phone acting up) into trackable tickets with clear ownership, status updates, and an audit trail. That structure matters because it replaces ad-hoc troubleshooting with a repeatable workflow, which is exactly what help desk jobs depend on.

The setup is fully Docker-based, with two hosting paths: run it on hardware at home (a server, NAS, or spare laptop) or run it in the cloud. For the cloud route, the transcript uses Linode (a cloud computing platform from Akamai) and walks through creating a small virtual machine plan, selecting a region close to the user (Dallas in the example), and deploying the ticketing app via Linode’s one-click marketplace. The first ticketing system is Peppermint, chosen from the marketplace and deployed on an Ubuntu image. After creation, the Linode console is used to confirm the Docker container is running (via Docker ps) and to identify the port where the web interface will be reachable.

Once Peppermint is live, the workflow inside the app mirrors a real help desk. There’s a dashboard with ticket history and a “create ticket” button. Admins can add users (for example, adding “Michael” as a user), then assign tickets to an engineer, set urgency, and create an internal view for the assignee. The assignee can update the ticket with notes or activity, transfer it back to admin if needed, and mark it complete once the issue is resolved. The overall emphasis is on keeping the system approachable—enough structure to manage requests without the complexity of enterprise platforms.

The transcript then shows how to deploy Peppermint locally using Docker Compose: install Docker and Docker Compose, create a directory, add a docker-compose.yml file, start the stack with docker-compose up -d, and verify containers with docker ps before accessing the web UI by IP and port. Default login details are provided for first access (admin/admin.com and password 1,2,3,4), followed by immediate use of the ticketing and user-management features.

Finally, a second option is introduced: UVdesk. It’s also deployed with Docker Compose, but it includes more feature depth, including a knowledge base. The knowledge base angle is practical: recurring issues solved once can be documented so new admins or team members can search and resolve similar problems faster. After confirming the containers and ports, the UVdesk installer prompts for database connection details (MySQL) and creation of a super admin account. The result is a pair of self-hosted help desk systems—Peppermint for a simpler ticket workflow and UVdesk for tickets plus knowledge management—both run on Linode in the example.

Cornell Notes

Self-hosted help desk ticketing is presented as a practical way to manage IT requests for family, friends, or a small team. The walkthrough uses Docker-based deployments, first on Linode via a one-click marketplace install of Peppermint, then locally using Docker Compose. Peppermint’s interface supports creating tickets, assigning engineers, tracking history, transferring tickets, and marking them complete, with admin tools for adding users. A second system, UVdesk, is deployed with Docker Compose and adds a knowledge base for capturing repeat solutions. Together, the two options show how to replace informal troubleshooting with a structured, resume-worthy workflow.

Why insist that every request becomes a ticket, even for personal IT problems?

The transcript frames tickets as the mechanism that turns random requests into a trackable workflow. Instead of “fix it when you can,” each issue gets logged with details, an assignee, urgency, and a history of actions. That structure mirrors real help desk operations and makes troubleshooting repeatable—whether the request comes from a coworker, a friend, or family (printer, phone, or streaming problems).

How does the Peppermint deployment on Linode work at a high level?

After creating a Linode instance (Ubuntu image, region near the user, and a small shared CPU plan), Peppermint is installed from the Linode marketplace. The setup then confirms Docker is running using Docker ps, checks which port the web app uses (the transcript references port 5,001 during testing), and opens the reverse DNS name plus the port in a browser to reach the ticketing UI.

What does the Peppermint workflow look like once users and tickets exist?

An admin adds users (the example adds “Michael”), then creates a ticket and assigns it to an engineer with a chosen urgency. When Michael logs in, his dashboard shows open tickets and lets him add notes/activity, edit the ticket, transfer it back to admin, and mark it complete. Admins also manage settings like creating clients and users.

How is Peppermint installed locally using Docker Compose?

The transcript instructs installing Docker and Docker Compose, creating a directory (peppermint), writing a docker-compose.yml file, and starting the stack with docker-compose up -d. Afterward, Docker ps verifies the containers are running and the web UI is accessed via the machine’s IP address and the exposed port.

What extra capability does UVdesk add compared with Peppermint?

UVdesk is positioned as more feature-rich, specifically highlighting a knowledge base. The idea is to store solutions to recurring issues so new admins or team members can search and resolve common problems without starting from scratch each time.

Review Questions

  1. What steps are needed to confirm a Docker-based ticketing app is actually running and reachable after deployment?
  2. Compare the roles of admin and engineer in the Peppermint ticket workflow described in the transcript.
  3. How does adding a knowledge base change how a help desk handles repeat issues?

Key Points

  1. 1

    Turn informal IT requests into structured tickets so issues have owners, urgency, and a history of actions.

  2. 2

    Use Docker-based deployments to run ticketing software either on local hardware (server/NAS/laptop) or in the cloud.

  3. 3

    Deploy Peppermint on Linode via the marketplace, then verify the Docker container and identify the correct web port before testing in a browser.

  4. 4

    Use Peppermint’s admin tools to add users and assign tickets, and use the engineer view to update, transfer, and complete tickets.

  5. 5

    Install ticketing software locally with Docker Compose by creating a docker-compose.yml file, starting the stack with docker-compose up -d, and validating with docker ps.

  6. 6

    Deploy UVdesk with Docker Compose and use its knowledge base to capture repeat solutions for faster onboarding and resolution.

Highlights

Peppermint’s help desk workflow includes ticket creation, assignment to an engineer, internal notes/activity, ticket transfer, and completion—enough structure for a small team or personal support.
Linode’s marketplace one-click app approach makes Docker-based ticketing setup fast: create an instance, install Peppermint, confirm Docker ps, then open the reverse DNS URL on the exposed port.
UVdesk adds a knowledge base angle—turning solved tickets into searchable documentation for recurring problems.

Topics

Mentioned