Deploy a Self-Hosted Help Desk
Deploy osTicket with Docker and configure a full MSP help desk environment.
Introduction
30 Second Summary
Every time you contact a company's support team, your request enters a ticketing system that tracks, prioritizes, and routes it to the right person. These systems are the backbone of IT support operations.
In this project, you will deploy osTicket, a professional help desk ticketing system, on your local machine using Docker. You'll configure departments, agents, and SLA plans, then practice the complete ticket lifecycle from creation to resolution.
What You'll Build
A containerized osTicket help desk system with a MariaDB database backend, deployed and orchestrated using Docker Compose.
By the end of this project, you'll have:
- A running osTicket instance deployed via Docker Compose with a MariaDB database container.
- Configured departments, agents, and SLA plans that mirror a real managed service provider environment.
- Sample tickets demonstrating proper triage, escalation, and resolution documentation.
- Secret Mission: Configure email integration so osTicket receives tickets via email and auto-routes them based on help topic.
Are there any prerequisites?
You should have basic comfort with the Windows command line, like opening Terminal and running commands. No Docker experience is required.
Install Docker Desktop and Enable WSL 2
To run osTicket locally, you need a way to package and run applications in isolated environments called containers. Docker is the tool that makes this possible.
Docker needs a Linux environment to run its containers. On Windows, that Linux environment is provided by WSL 2 (Windows Subsystem for Linux). In this step, you will enable WSL 2, install Docker Desktop, and confirm everything works.
In this step, get ready to:
- Enable WSL 2 on your Windows machine.
- Install Docker Desktop with the per-user installation.
- Verify Docker is ready by running version checks.
Enable WSL 2 on Windows
WSL 2 lets Windows run a lightweight Linux kernel alongside your regular Windows environment. Docker Desktop uses this Linux kernel to run containers.
- Right-click the Start button in your taskbar.
- Select Terminal (Admin).
- Click Yes when the User Account Control prompt appears.
Why Terminal (Admin)?
The wsl --install command needs administrator privileges because it enables system-level features (the Virtual Machine Platform and WSL components). This is a one-time requirement.
- Install WSL 2 by running this command:
wsl --install
What does this command do?
This single command does four things:
- Enables the WSL and Virtual Machine Platform components.
- Downloads and installs the latest Linux kernel.
- Sets WSL 2 as the default version.
- Installs the Ubuntu Linux distribution.
- Wait for the installation to complete. You will see progress messages in the terminal.
- Restart your computer when prompted. The installation requires a reboot to finish enabling the system features.
What happens after the restart?
The first time WSL launches after a reboot, a console window may appear briefly to decompress Linux files. This is normal and only happens once. You can close it when it finishes.
Seeing the WSL help text instead of an installation?
If wsl --install shows help text instead of starting an installation, it means a partial WSL installation already exists on your machine. Run wsl --install -d Ubuntu instead to install the Ubuntu distribution explicitly.
help me troubleshoot WSL installation issues on Windows 11
Download and install Docker Desktop
With WSL 2 ready, you can now install Docker Desktop which provides both the Docker engine and a graphical dashboard for managing containers.
- Open your web browser and navigate to the Docker Desktop download page:
- https://www.docker.com/products/docker-desktop
- Click the Download for Windows button to download Docker Desktop Installer.exe.
- Double-click Docker Desktop Installer.exe to run the installer.
- When the installer asks which installation mode you prefer, choose per-user.
- Ensure the Use WSL 2 instead of Hyper-V option is selected on the Configuration page.
- Follow the remaining prompts and click Close when the installation finishes.
- Start Docker Desktop. Press the Windows key, type Docker Desktop, and press Enter.
Why per-user installation?
The per-user installation does not require administrator privileges to install or update. It uses the WSL 2 backend exclusively, which is exactly what Windows 11 Home supports.
Docker Desktop is free for personal and educational use. A paid subscription is only required for commercial use in larger enterprises (more than 250 employees or more than $10 million in annual revenue).
- Wait for Docker Desktop to finish starting. You will see the Docker whale icon appear in your system tray (bottom-right corner of your taskbar) once it is ready.
Docker Desktop stuck on starting?
Give it 1-2 minutes on first launch. Docker Desktop needs to initialize the WSL 2 integration. If it stays stuck beyond 3 minutes, restart Docker Desktop from the system tray icon (right-click the whale, select Restart).
help me fix Docker Desktop stuck on starting with WSL 2 on Windows 11
Verify Docker is working
- Open Windows Terminal. Press the Windows key, type Terminal, and press Enter.
- Check that Docker is available by running this command:
docker --version
- Check that Docker Compose is available by running:
docker compose version
✔️ I see version numbers for both commands
Docker is installed and running correctly. You are ready to move on to deploying osTicket.
ⓧ Command not found or an error appeared
If docker is not recognized, Docker Desktop may not have finished starting. Try these fixes:
- Confirm the Docker whale icon is visible in your system tray (bottom-right of the taskbar). If it is not there, start Docker Desktop again.
- Close your current terminal window and open a new one. The terminal session needs to reload its PATH after Docker Desktop starts.
- If docker compose version fails but docker --version works, make sure Docker Desktop is fully up to date. Docker Compose is bundled with modern Docker Desktop installations.
help me troubleshoot Docker commands not being recognized in Windows Terminal
Your development environment is ready. Next up, you will write a Docker Compose file to deploy osTicket and its database with a single command.
Deploy osTicket with Docker Compose
With Docker Desktop running, you now have a container engine ready to host your help desk system.
In this step, you will define two containers in a single configuration file and launch them together. One container runs the osTicket web application. The other runs MariaDB, the database that stores all your tickets, users, and settings.
In this step, get ready to:
- Create a project folder and write a docker-compose.yml file defining your two services.
- Start both containers and verify they are running.
- Log into the osTicket Staff Control Panel and change the default admin password.
Create the project folder and Docker Compose file
Docker Compose lets you define multiple containers in a single YAML file and start them all with one command. You will create a project folder to keep everything organized.
- Switch back to Windows Terminal and move to your Desktop by running this command:
cd ~/Desktop
- Create your project folder and move into it by running these commands:
mkdir osticket-helpdesk
cd osticket-helpdesk
- Create the Docker Compose configuration file by running:
New-Item docker-compose.yml
- Confirm the file was created by running:
ls
You should see docker-compose.yml listed in the output.
- Open the file in Notepad by running:
notepad docker-compose.yml
Notepad opens with your empty docker-compose.yml file.
- Copy the following YAML configuration and paste it into Notepad:
services:
osticket:
image: osticket/osticket
container_name: osticket-app
depends_on:
- mariadb
ports:
- "8080:80"
environment:
- MYSQL_HOST=mariadb
- MYSQL_DATABASE=osticket
- MYSQL_USER=osticket
- MYSQL_PASSWORD=osticket-secret-pw
volumes:
- osticket-data:/var/www/html
restart: unless-stopped
mariadb:
image: mariadb:10.11
container_name: osticket-db
environment:
- MYSQL_ROOT_PASSWORD=root-secret-pw
- MYSQL_DATABASE=osticket
- MYSQL_USER=osticket
- MYSQL_PASSWORD=osticket-secret-pw
volumes:
- mariadb-data:/var/lib/mysql
restart: unless-stopped
volumes:
osticket-data:
mariadb-data:
What does this configuration do?
This file defines two services that Docker will run as separate containers:
- osticket uses the official osticket/osticket image. It maps port 8080 on your machine to port 80 inside the container so you can access the web interface from your browser.
- mariadb uses the mariadb:10.11 image. It stores all osTicket data (tickets, users, settings) in a persistent volume so nothing is lost when you restart.
- The depends_on field ensures the database starts before osTicket tries to connect to it.
- The volumes section at the bottom creates named storage that persists even when containers are removed.
- Save the file by pressing Ctrl+S in Notepad, then close Notepad.
Don't see docker-compose.yml?
Make sure you saved the file from Notepad (Ctrl+S). If Notepad saved it as docker-compose.yml.txt, rename it by running:
Rename-Item docker-compose.yml.txt docker-compose.yml
Help me find my docker-compose.yml file
✔️ Awesome, I've got everything!
Great. Make sure the file is saved and you are back in your terminal inside the osticket-helpdesk folder.
ⓧ I'd like to double check the full code
Your docker-compose.yml should look exactly like this:
services:
osticket:
image: osticket/osticket
container_name: osticket-app
depends_on:
- mariadb
ports:
- "8080:80"
environment:
- MYSQL_HOST=mariadb
- MYSQL_DATABASE=osticket
- MYSQL_USER=osticket
- MYSQL_PASSWORD=osticket-secret-pw
volumes:
- osticket-data:/var/www/html
restart: unless-stopped
mariadb:
image: mariadb:10.11
container_name: osticket-db
environment:
- MYSQL_ROOT_PASSWORD=root-secret-pw
- MYSQL_DATABASE=osticket
- MYSQL_USER=osticket
- MYSQL_PASSWORD=osticket-secret-pw
volumes:
- mariadb-data:/var/lib/mysql
restart: unless-stopped
volumes:
osticket-data:
mariadb-data:
Start the containers
With your configuration file ready, one command will download the required images and start both containers in the background.
- Launch both containers by running this command:
docker compose up -d
What does this command do?
- docker compose up reads your docker-compose.yml and creates the containers defined inside it.
- The -d flag runs them in detached mode, meaning they run in the background and give you your terminal back.
The first run downloads the container images, which may take 2-3 minutes depending on your internet speed. You will see progress bars for each layer being pulled.
Wait 2-3 minutes after the command finishes. The database needs time to initialize its schema before osTicket can connect.
- Verify both containers are running by running:
docker compose ps
You should see two entries: osticket-app and osticket-db. Both should show a status of Up in the output table.
Containers not showing as Up?
- If you see no containers listed, make sure you are inside the osticket-helpdesk folder where your docker-compose.yml lives.
- If a container shows a status of Restarting, wait another minute for the database to finish initializing. The osTicket container will restart automatically once MariaDB is ready.
- If port 8080 is already in use on your machine, change "8080:80" in your docker-compose.yml to "8081:80" and run docker compose up -d again.
Help me troubleshoot my Docker containers
Log into the Staff Control Panel
osTicket is now running on your machine. The Staff Control Panel is where administrators and agents manage tickets, configure departments, and set up routing rules.
- Open your web browser (Edge or Chrome).
- Type http://localhost:8080/scp into the address bar and press Enter.
The osTicket login page appears. This is the Staff Control Panel where agents and admins sign in.
- Enter ostadmin in the Username field.
- Enter Admin1 in the Password field.
- Click Log In.
You are now inside the osTicket Staff Control Panel dashboard.
Why change the default password?
The default credentials (ostadmin / Admin1) are publicly documented. Anyone who knows the image can guess them. Changing the password immediately is a basic security practice, even on a local system.
- Click your name (Admin) in the top right corner of the dashboard.
- Click Profile.
- Scroll down to the Password section.
- Enter a new password of your choice in both the New Password and Confirm Password fields.
- Click Save Changes.
Your admin password is now updated. Remember this password for future logins.
Seeing a connection error in the browser?
- Make sure Docker Desktop is still running. Check the system tray for the Docker whale icon.
- If you just started the containers, wait a full 2-3 minutes. The database schema needs to initialize before the web interface responds.
- Try refreshing the page. The osTicket container may still be waiting for MariaDB to become ready.
Help me access the osTicket login page
Your help desk system is live. Next up, you will configure departments, create agent accounts, and build out the team structure that mirrors a real managed IT environment.
Configure Departments, Agents, and Teams
Your osTicket instance is running and you can access the admin panel. Now it is time to build the organizational structure that makes a help desk actually work.
In a real managed service provider (MSP) environment, tickets flow through departments, get assigned to specific technicians, and follow escalation paths between support tiers. You are going to replicate that structure inside osTicket so you can practice the exact workflows used at companies like Next Perimeter.
In this step, get ready to:
- Create three departments that mirror an MSP structure.
- Add agent accounts representing a small support team.
- Set up cross-department teams for ticket routing.
Create departments that mirror an MSP structure
Departments control how tickets are categorized and who can see them. Every ticket flows through a department, and agents are assigned to departments to determine their access level.
- In your browser, make sure you are on the osTicket Staff Control Panel at http://localhost:8080/scp.
- Click Admin Panel in the top navigation bar to switch to the Admin Panel.
- Click the Agents tab in the top menu.
- Click Departments.
You should see a list of existing departments. osTicket ships with a default department already created. You will now add your own departments.
- Click Add New Department.
- In the Name field, type IT Support.
- Leave the Type as Public so users can see tickets routed here.
- Leave all other settings at their defaults and click Create Dept at the bottom of the page.
Repeat the process to create the remaining two departments.
- Click Add New Department again.
- Enter Networking in the Name field and click Create Dept.
- Click Add New Department one more time.
- Enter Security in the Name field and click Create Dept.
Now set IT Support as the default department so unassigned tickets land there automatically.
- Click the Settings tab in the top menu of the Admin Panel.
- Click System.
- Find the Default Department dropdown.
- Select IT Support from the dropdown.
- Scroll to the bottom of the page and click Save Changes.
What is a default department?
The default department receives any ticket that is not routed to a specific department by a help topic, email rule, or ticket filter. Setting IT Support as the default means unassigned tickets go to your general support queue first, where they can be triaged and escalated if needed.
Don't see your new departments listed?
Make sure you are in the Admin Panel (not the Agent Panel). The top navigation bar should say Agent Panel as the toggle link, which means you are currently in the Admin Panel view.
If you accidentally navigated away, go back to the Agents tab and click Departments to see your full list.
Help me find my departments in the admin panel.
Create agent accounts for your support team
Agents are the staff members who respond to and resolve tickets. Each agent gets assigned to a primary department and a role that controls their permissions. You will create two agents to simulate a tiered support team.
- In the Admin Panel, click the Agents tab.
- Click Agents in the submenu (not Departments or Teams).
- Click Add New Agent.
Create your first agent to represent yourself as a Tier 1 technician.
- Enter your first name and last name in the Name fields.
- Enter an email address in the Email Address field. This can be any email since you are running locally.
- Enter a username in the Username field (e.g. tier1tech).
- Click Set Password and uncheck the box that says to send a password reset email.
- Type a password you will remember and click Update.
Now assign this agent to the IT Support department with appropriate permissions.
- Click the Access tab on the agent's profile page.
- Under Primary Department, select IT Support.
- For the Primary Role, select a role that allows basic ticket operations (the built-in roles will work here).
- Click Save Changes.
Create a second agent to represent a Tier 2 engineer.
- Return to Agents and click Add New Agent again.
- Enter a fictional name (e.g. Alex Rivera) in the Name fields.
- Enter a fictional email address and username (e.g. tier2eng).
- Set a password the same way you did for the first agent.
- Click the Access tab.
- Set Networking as the Primary Department.
- Select a role with elevated permissions (such as one that includes Assign, Close, and Transfer abilities).
- Click Save Changes.
Why two different departments?
In a real MSP, Tier 1 technicians handle general IT issues (password resets, basic troubleshooting). Tier 2 engineers focus on specialized areas like networking or security. Assigning agents to different primary departments means tickets automatically appear in the correct queue for each skill level.
You can also grant Extended Access to additional departments via the Access tab if an agent needs visibility across multiple areas.
Agent not appearing in the list?
Make sure you clicked Save Changes after filling out the agent's profile. If the password pop-up is still open, close it first, then save the full agent profile.
Help me troubleshoot creating agents in osTicket.
Create teams that span departments
Teams let you group agents from different departments together. This is how MSPs coordinate across specialties. A Level 1 team handles initial triage regardless of department, while a Level 2 team handles escalated issues.
- In the Admin Panel, click the Agents tab.
- Click Teams.
- Click Add New Team on the right side.
- Enter Level 1 Support as the team name.
- Click the Members tab within the team creation page.
- Add your Tier 1 agent to this team by selecting them from the agent dropdown and clicking Add.
- Click Create Team.
Now create the second team for escalations.
- Click Add New Team again.
- Enter Level 2 Support as the team name.
- Click the Members tab and add your Tier 2 agent.
- Click Create Team.
How do teams differ from departments?
Departments control which tickets an agent can see and respond to. Teams are an overlay that pulls agents from any department into a cross-functional group.
When a ticket is assigned to a team, it supersedes the agent's normal department rules. This is how you route a critical network outage to your best engineers regardless of which department they sit in.
You should now see both Level 1 Support and Level 2 Support listed on the Teams page.
Team members not showing up?
You need to add members from the Members tab of the team, not from the agent's profile. Return to the team, click its name, go to the Members tab, and select the agent from the dropdown.
Help me add agents to a team in osTicket.
Your help desk now has a realistic organizational structure. Tickets can flow between departments, agents have clear roles, and teams enable cross-functional collaboration. Next up, you will configure the SLA plans and help topics that drive ticket prioritization and routing.
Set Up SLA Plans and Help Topics
Your team structure is in place. Departments, agents, and teams are ready to receive and work on tickets.
But without response-time commitments and organized intake categories, tickets pile up without accountability. In this step, you'll create SLA plans that enforce deadlines and help topics that route incoming requests to the right department automatically.
In this step, get ready to:
- Create SLA plans with escalating response times.
- Set up help topics for common support requests.
- Configure auto-routing rules for incoming tickets.
Create SLA plans with real-world response times
An SLA (Service Level Agreement) defines how quickly a ticket must be resolved before it becomes overdue. MSPs commit to specific response windows in their client contracts. You'll create three severity tiers that mirror those real-world commitments.
- In the osTicket Admin Panel, click the Manage tab in the top navigation.
- Click SLA Plans in the left sidebar.
- Click Add New SLA Plan in the top right corner of the table.
Fill in the first SLA plan with these settings:
- In the Name field, enter SEV-A.
- Set the Grace Period to 1 (this is measured in hours).
- Leave Schedule set to the 24/7 option (tickets can become overdue at any time, not just business hours).
- Set Status to Active.
- Click Add Plan.
Repeat the process to create two more SLA plans:
- Click Add New SLA Plan again.
- Create SEV-B with a grace period of 4 hours and a 24/7 schedule. Set status to Active and click Add Plan.
- Create SEV-C with a grace period of 8 hours. For the schedule, select the business hours option (Monday to Friday, standard hours). Set status to Active and click Add Plan.
You should now see all three SLA plans listed in the table: SEV-A, SEV-B, and SEV-C.
What is a grace period?
The grace period is the number of hours before a ticket becomes overdue. A 1-hour grace period on SEV-A means that if a critical ticket is not closed within 1 hour, it gets flagged as overdue and triggers alerts.
The schedule determines when those hours count. A 24/7 schedule means the clock ticks around the clock, including weekends. A business-hours schedule only counts time during work hours, so an 8-hour SEV-C ticket submitted on Friday at 4pm would not become overdue until Monday.
Why three severity levels?
MSPs typically structure SLAs into tiers that match the impact of an issue. SEV-A covers emergencies like a server outage affecting an entire office. SEV-B handles urgent but non-critical issues like email being down for one user. SEV-C covers routine requests like password resets that can wait a few hours.
Create help topics for common support requests
Help topics are the categories that end users choose when submitting a ticket. Behind the scenes, each help topic can route the ticket to a specific department and assign an SLA automatically.
- In the Admin Panel, click the Manage tab.
- Click Help Topics in the left sidebar.
- Click Add New Help Topic.
Create the first help topic with these settings:
- In the Help Topic Information tab, enter Password Reset in the Topic field.
- Set Status to Active.
- Click the New Ticket Options tab.
- Set Department to IT Support.
- Set SLA Plan to SEV-C.
- Click Add Topic.
Repeat to create four more help topics using the same process:
- Email Issues with department IT Support and SLA SEV-B.
- Hardware Problem with department IT Support and SLA SEV-B.
- Software Installation with department IT Support and SLA SEV-C.
- Network Connectivity with department Networking and SLA SEV-B.
You should now see all five help topics listed in the Help Topics table.
Why do help topics matter?
Help topics let you route tickets without exposing your internal department structure to end users. A user just picks "Network Connectivity" from a dropdown. They don't need to know that it goes to the Networking department with a 4-hour SLA attached.
This is exactly how enterprise ticketing systems work at MSPs. The intake form handles triage automatically, so agents spend time solving problems instead of sorting tickets.
Don't see the SLA Plan dropdown in New Ticket Options?
Make sure you click the New Ticket Options tab at the top of the help topic form. The SLA Plan and Department fields are not on the first tab (Help Topic Information). They live on the second tab.
If the SLA dropdown is empty, return to Manage > SLA Plans and confirm all three plans have their status set to Active.
help me troubleshoot why my SLA plans are not appearing in the help topic configuration
Configure auto-routing for Network Connectivity tickets
You already set the department on each help topic in the previous substep. The "Network Connectivity" topic routes to the Networking department because you set that in the New Ticket Options tab. Now verify that this auto-routing is working correctly.
- In the Help Topics list, click on Network Connectivity to open it.
- Click the New Ticket Options tab.
- Confirm that Department is set to Networking.
- Confirm that SLA Plan is set to SEV-B.
Any ticket submitted with the "Network Connectivity" help topic will now automatically land in the Networking department with a 4-hour SLA timer. No manual triage needed.
What is auto-routing?
Auto-routing means tickets are assigned to a department and SLA the moment they are created, based on the help topic the user selects. Without it, someone has to manually read each ticket and move it to the right team.
In a busy MSP, manual triage wastes valuable minutes on every ticket. Auto-routing ensures the right team sees the ticket immediately, and the SLA clock starts counting from the correct moment.
Department still showing as IT Support?
If you see IT Support instead of Networking for the Network Connectivity topic, click the Department dropdown and select Networking. Click Save Changes at the bottom of the page.
help me fix my help topic department routing configuration in osTicket
Your ticketing system now has real structure. Tickets are automatically categorized, routed to the right team, and held to response-time commitments. Next up, you'll put this system to the test by creating tickets and walking through the full support lifecycle.
Practice the Ticket Lifecycle
Your help desk is fully configured with departments, agents, SLA plans, and routing rules. Now it's time to put it all to the test by simulating real support work.
In this step, you'll switch between two roles. First, you'll act as end users submitting tickets through the customer portal. Then you'll switch to the agent panel to triage, escalate, and resolve those tickets. This is the exact daily workflow you'd follow at a managed IT provider.
In this step, get ready to:
- Submit test tickets through the customer portal as different end users.
- Process tickets through the full lifecycle as an agent.
- Review SLA timers and the ticket dashboard.
Submit test tickets as end users
Before you can practice agent workflows, you need tickets in the system. You'll create these by visiting the customer-facing portal and pretending to be different employees reporting issues.
- Open a new browser tab and navigate to http://localhost:8080 to access the customer portal.
- Click Open a New Ticket.
- Fill in the Email Address field with a fictional email like john.smith@company.com.
- Enter a Full Name such as John Smith.
- Select Password Reset from the Help Topic dropdown.
- Type Can't log into email account in the Issue Summary field.
- Add detail in the message body, such as: "I've been locked out of my email since this morning. I've tried resetting through the portal but keep getting an error."
- Click Create Ticket.
You should see a confirmation page with a ticket number. Note this number down for later.
Why use fictional user details?
In a real help desk, tickets come from employees or customers with their own accounts. By using different fictional emails each time, you simulate multiple users contacting IT support. Each unique email creates a separate user in osTicket's system.
Now create two more tickets using different personas and help topics to give yourself a realistic queue to work through.
- Click Open a New Ticket again from the customer portal.
- Use email sarah.jones@company.com and name Sarah Jones.
- Select Network Connectivity as the help topic.
- Type Cannot connect to VPN from home in the Issue Summary.
- Add body text explaining the issue, then click Create Ticket.
- Create a third ticket using email mike.chen@company.com and name Mike Chen.
- Select Email Issues as the help topic.
- Type Outlook keeps crashing every 10 minutes in the Issue Summary.
- Add body text, then click Create Ticket.
What should I see?
Each ticket submission shows a confirmation page with a unique ticket number. You now have three tickets in the system with different help topics. The Network Connectivity ticket should have automatically routed to the Networking department based on the auto-routing rule you configured in the previous step.
Not seeing your help topics in the dropdown?
Make sure each help topic's status is set to Active in the Admin Panel. Private help topics only appear when agents create tickets internally, not on the customer portal.
Help me troubleshoot why my help topics aren't showing in the customer portal.
Work tickets as an agent
Now switch hats. You're no longer the end user reporting problems. You're the IT support technician who needs to triage, investigate, and resolve these tickets.
- Navigate to http://localhost:8080/scp to return to the Staff Control Panel.
- Click the Tickets tab at the top of the Agent Panel.
- You should see your three new tickets listed in the Open queue.
Start by claiming and working the first ticket (the password reset from John Smith).
- Click the ticket number or subject line for the password reset ticket to open it.
- Click the Claim button at the top of the ticket to assign it to yourself.
- Click the Post Internal Note tab at the bottom of the ticket.
- Type a troubleshooting note such as: "Checked Active Directory - account is locked due to 5 failed login attempts. Unlocked account and reset password. Sending new credentials to user via secure channel."
- Click Post Note.
What are internal notes?
Internal notes appear with a yellow banner in the ticket thread and are only visible to agents. They are invisible to the end user. Use them to document your troubleshooting process, leave handoff notes for other technicians, or record decisions made about the ticket.
This documentation habit is critical in IT support. If your shift ends or you escalate to another team, the next person sees exactly what you already tried.
Now send a reply back to the "user" to let them know the issue is resolved.
- Click the Post Reply tab at the bottom of the ticket.
- Type a professional response such as: "Hi John, I've unlocked your account and reset your password. Please check your phone for the new temporary password. Let me know if you have any further issues."
- Change the Ticket Status dropdown to Resolved (or Closed).
- Click Post Reply.
Your first ticket is now resolved with a documented trail showing the internal troubleshooting and the user-facing communication.
Next, escalate the Network Connectivity ticket to Tier 2 to practice cross-team handoff.
- Return to the Tickets tab and open the Network Connectivity ticket from Sarah Jones.
- Click Claim to take ownership of the ticket.
- Click the Post Internal Note tab.
- Type a note such as: "Attempted basic VPN troubleshooting - user has restarted client and cleared cache. Issue persists. Escalating to Level 2 Support for deeper network diagnostics."
- Click Post Note.
- Click the Assign button at the top of the ticket.
- In the assignment dialog, select Level 2 Support from the Team dropdown.
- Click Save to complete the escalation.
Why document before escalating?
Always post an internal note before escalating. The Tier 2 engineer receiving the ticket needs to know what you already tried. Without this, they waste time repeating the same steps you already completed.
In a real MSP environment, undocumented escalations are one of the biggest time-wasters and frustration sources for support teams.
Finally, resolve the third ticket (Outlook crashing from Mike Chen) using the same workflow.
- Open the Email Issues ticket from Mike Chen.
- Click Claim.
- Post an internal note documenting your troubleshooting steps.
- Post a reply to the user with a resolution message.
- Set the ticket status to Resolved and click Post Reply.
Don't see the Assign or Claim buttons?
Your agent account may not have the correct role permissions. Switch to the Admin Panel, go to Agents then Roles, and verify that the role assigned to your agent includes Assign, Post Reply, Close, and Transfer permissions.
Help me fix my agent permissions so I can claim and assign tickets.
Review the ticket dashboard and SLA timers
A key part of help desk work is monitoring your queue and understanding which tickets need attention first. The SLA timers you configured earlier are now actively counting down on your open tickets.
- Click the Dashboard tab in the Agent Panel.
- Review the ticket statistics showing open, assigned, overdue, and closed ticket counts.
- Return to the Tickets tab and look at the Open queue.
- Notice the SLA due date column on the escalated Network Connectivity ticket. Since this ticket has the SEV-B SLA (4-hour grace period, 24/7 schedule), the due date reflects that 4-hour window from when the ticket was created.
- Check the Overdue queue. If any tickets have exceeded their SLA grace period, they appear here highlighted in red.
How do SLA timers work in practice?
Each SLA plan defines a grace period and a schedule. SEV-A gives agents 1 hour to respond (counting 24/7). SEV-B gives 4 hours (24/7). SEV-C gives 8 hours but only counts during business hours.
When a ticket exceeds its grace period without a response, it moves to the Overdue queue. In a real MSP, overdue tickets trigger alerts to managers and can impact your team's performance metrics.
Practice prioritization
When you have multiple tickets open, always work them in SLA order. A SEV-A ticket with 20 minutes remaining takes priority over a SEV-C ticket with 6 hours left. This is how professional help desk teams avoid SLA breaches.
You've now experienced the complete ticket lifecycle. You created tickets as end users, claimed and triaged them as an agent, documented your troubleshooting internally, communicated with users, escalated when needed, and monitored SLA compliance. Next up, you'll document this entire deployment as a portfolio piece.
Document Your Deployment
You've practiced the full ticket lifecycle, from creating tickets as end users to resolving them as a support agent. Now it's time to turn that hands-on work into something you can show to employers.
Documentation is what separates a lab exercise from a portfolio piece. In this step, you'll create a README that captures your deployment architecture, configuration decisions, and lessons learned.
In this step, get ready to:
- Create a README.md documenting your system architecture and usage instructions.
- Take screenshots of your configured system for portfolio evidence.
- Add a Lessons Learned section showing you think beyond the lab.
Create your README.md file
A good README answers the questions any future reader will have: what is this, how do I run it, and what did you configure. This is the file hiring managers and teammates look at first when they open your project.
- In Windows Terminal, make sure you're inside your project folder (the one containing docker-compose.yml).
- Create the README.md file by running this command:
New-Item -Path "README.md" -ItemType "File"
- Open README.md in your text editor (Notepad, VS Code, or whichever editor you prefer).
- Paste the following content into the file:
# osTicket Help Desk - Docker Deployment
## Overview
Self-hosted help desk ticketing system deployed using Docker Compose. This project demonstrates IT infrastructure deployment, ticketing system administration, and documentation skills.
## Architecture
- **osTicket** (osticket/osticket) - Help desk application
- **MariaDB 10.11** - Database backend
- **Docker Compose** - Container orchestration
## Quick Start
### Prerequisites
- Docker Desktop for Windows with WSL 2 enabled (works on Windows 11 Home)
### Start the system
```bash
docker compose up -d
```
### Access
- Staff Panel: http://localhost:8080/scp
- Customer Portal: http://localhost:8080
- Default login: ostadmin / Admin1 (change immediately)
### Stop the system
```bash
docker compose stop
```
### Remove everything
```bash
docker compose down -v
```
## Configuration
- **Departments**: IT Support, Networking, Security
- **SLA Plans**: SEV-A (1hr), SEV-B (4hr), SEV-C (8hr)
- **Help Topics**: Password Reset, Email Issues, Hardware Problem, Software Installation, Network Connectivity
What does this README cover?
- Overview tells a reader what this project is in one sentence.
- Architecture lists the two containers and the orchestration tool, so anyone can understand the stack at a glance.
- Quick Start gives copy-paste commands to launch, access, stop, and destroy the system.
- Configuration summarizes the departments, SLA plans, and help topics you set up, proving your admin work.
- Save README.md.
- Confirm the file exists by running:
ls
You should see both docker-compose.yml and README.md listed in the output.
Don't see README.md in the list?
- Make sure you saved the file before running ls. Some editors don't auto-save.
- Check that your terminal is in the same folder as docker-compose.yml. Run ls and look for docker-compose.yml to confirm you're in the right place.
Why isn't my README.md showing up in my project folder?
Take screenshots for your portfolio
Screenshots give visual proof of your configured system. They show employers you actually built and configured this, not just followed along.
- Switch back to your browser with the osTicket Staff Control Panel at http://localhost:8080/scp.
- Navigate to Admin Panel then Agents then Departments.
- Take a screenshot showing your three departments (IT Support, Networking, Security).
- Navigate to Admin Panel then Manage then SLA Plans.
- Take a screenshot showing your three SLA plans (SEV-A, SEV-B, SEV-C).
- Navigate to Agent Panel then Tickets.
- Open one of your resolved tickets that has internal notes.
- Take a screenshot showing the resolved ticket with its internal notes visible.
Capture the full thread
When screenshotting the resolved ticket, scroll so that both the internal notes and the resolution reply are visible. This proves you practiced proper documentation during the support workflow.
- Save all three screenshots in your project folder alongside docker-compose.yml and README.md.
Add a Lessons Learned section
A Lessons Learned section shows you think beyond the lab environment. It tells employers you understand what production deployments actually require.
- Open README.md in your text editor again.
- Add the following section at the very bottom of the file:
## Lessons Learned
- In production: add HTTPS via reverse proxy, configure external SMTP, schedule database backups
- osTicket email fetching requires a dedicated mailbox
- SLA plans should align with client service agreements
- Internal notes are critical for knowledge transfer between shifts
Why do these points matter?
Each bullet addresses a real production concern. HTTPS protects login credentials in transit. External SMTP enables email-to-ticket workflows. Database backups prevent data loss.
The last two bullets show you understand how ticketing systems fit into team operations. SLA alignment keeps clients happy, and internal notes ensure the next shift can pick up where you left off.
- Save README.md.
- Confirm the file is complete by running:
Get-Content README.md
You should see the full README printed in your terminal, ending with the Lessons Learned bullets.
Only see part of the file?
- Make sure you added the Lessons Learned section below the Configuration section, not inside it.
- Check that you saved after adding the new section.
My README.md is missing the Lessons Learned section when I print it.
✔️ Awesome, I've got everything!
Great. Double check you've saved README.md and that all six sections are present (Overview, Architecture, Quick Start, Configuration, Lessons Learned).
ⓧ I'd like to double check the full code
Here's the complete README.md file for comparison:
# osTicket Help Desk - Docker Deployment
## Overview
Self-hosted help desk ticketing system deployed using Docker Compose. This project demonstrates IT infrastructure deployment, ticketing system administration, and documentation skills.
## Architecture
- **osTicket** (osticket/osticket) - Help desk application
- **MariaDB 10.11** - Database backend
- **Docker Compose** - Container orchestration
## Quick Start
### Prerequisites
- Docker Desktop for Windows with WSL 2 enabled (works on Windows 11 Home)
### Start the system
```bash
docker compose up -d
```
### Access
- Staff Panel: http://localhost:8080/scp
- Customer Portal: http://localhost:8080
- Default login: ostadmin / Admin1 (change immediately)
### Stop the system
```bash
docker compose stop
```
### Remove everything
```bash
docker compose down -v
```
## Configuration
- **Departments**: IT Support, Networking, Security
- **SLA Plans**: SEV-A (1hr), SEV-B (4hr), SEV-C (8hr)
- **Help Topics**: Password Reset, Email Issues, Hardware Problem, Software Installation, Network Connectivity
## Lessons Learned
- In production: add HTTPS via reverse proxy, configure external SMTP, schedule database backups
- osTicket email fetching requires a dedicated mailbox
- SLA plans should align with client service agreements
- Internal notes are critical for knowledge transfer between shifts
Secret mission
Email Integration and Auto-Routing
Real help desks don't rely on users visiting a web portal. They accept support requests via email and automatically route them to the right team. In this secret mission, you'll configure osTicket to receive emails, create tickets from them automatically, and apply smart routing rules based on the email subject line.
Clean Up Your Resources
Clean Up Your Resources
This project runs entirely locally using Docker containers, so there are no ongoing cloud costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.
Resources you used:
- Two Docker containers (osticket-app and osticket-db).
- Two Docker volumes (osticket-data and mariadb-data).
- Project folder with docker-compose.yml and README.md.
- Docker Desktop application installed on your machine.
- Gmail app password created for email integration (Secret Mission).
Keep everything running
No action needed. Choose this if you're still actively building or want to keep practicing with osTicket.
- Leave Docker Desktop running. The containers restart automatically thanks to the restart: unless-stopped policy in your Compose file.
- Your tickets, agents, departments, SLA plans, and all configuration persist in Docker volumes.
- The two containers use under 500MB RAM total while running.
- Your Gmail app password remains active. You can continue receiving tickets via email.
Pause - I'll come back to this later
Shut down running containers to free up memory without losing any data. Your tickets, configuration, and volumes are preserved.
- Open Windows Terminal and navigate to your project folder.
- Stop the containers by running:
docker compose stop
- When you're ready to resume, start them back up by running:
docker compose start
- You can also quit Docker Desktop entirely from the system tray to free all Docker-related memory.
- Your Gmail app password stays active. Revoke it from your Google Account if you do not want email integration running while paused.
Delete - I don't want to use this again
Remove all project containers, volumes, data, and files. This is irreversible. All tickets, configuration, agents, and SLA plans will be gone.
- Open Windows Terminal and navigate to your project folder.
- Remove all containers and volumes (this deletes all osTicket data permanently) by running:
docker compose down -v
- Delete your project folder by running:
cd ~\Desktop
Remove-Item -Recurse -Force osticket-helpdesk
- Revoke your Gmail app password. Go to myaccount.google.com, select Security, find App passwords, and click the trash icon next to the password you created for osTicket.
- Uninstall Docker Desktop. Open Settings, select Apps, then Apps & features. Find Docker Desktop in the list, select it, and click Uninstall.
What about WSL 2?
Uninstalling Docker Desktop does not remove WSL 2 itself. WSL 2 is a Windows feature that other tools may use. If you want to remove it entirely, open PowerShell as Administrator and run wsl --unregister docker-desktop to remove Docker's WSL distribution. Leave WSL enabled if you plan to use Linux tools in the future.
Nice Work!
Nice Work!
You just deployed and configured a professional help desk system from scratch. You now have a fully containerized osTicket instance running locally that mirrors the exact ticketing workflows used by managed IT providers every day.
You've learned how to:
- Deploy a multi-container application using Docker Compose, orchestrating an app server and database together.
- Configure a ticketing system with departments, agents, SLA plans, and automated routing rules that reflect real MSP environments.
- Practice the complete ticket lifecycle from creation through triage, escalation, and resolution with proper documentation.
- Configured email-to-ticket integration with automated routing rules that assign priority and department based on incoming message content.
Ready to quiz yourself?