Which open source helpdesk fits a small support team
For a team of two to five agents sharing one inbox, with email as the main channel and no dedicated IT staff for the tool, FreeScout or osTicket usually fit on a light stack. Zammad fits when the team also needs more channels, stronger search and reporting, or a clear path to a larger desk. The decision is less about today's ticket volume than about how the team will work in two to three years. A shared inbox that works for four agents on email may not work for the same team once chat, a customer portal or automation becomes a daily need. At this size the hosting burden is the first constraint. FreeScout is a PHP application licensed under AGPL-3.0 and osTicket is licensed under GPL-2.0, so either runs on a conventional web and database stack with few moving parts. Zammad stores its content in PostgreSQL 15 or newer, requires Redis 7 or newer for realtime communication, and strongly recommends Elasticsearch for search and attachment content. Each added service is something the team must patch, back up and monitor, usually without a platform engineer on call. Ask any implementation partner to list every service in the target design and who restores it after a failure.
Small teams still owe compliance evidence, even without a formal program. If the desk handles customer personal data, you need to know where conversations are stored, who can read them, how long they are kept and how a deletion request would be handled. Confirm with your own counsel which retention periods apply to your sector, and make sure the chosen tool can export or purge tickets on request. Access logs and admin change history matter for the same reason. Check the audit features of each candidate against that list before you choose, since the lighter tools may need more manual process to produce the same evidence. Finally, plan for the next two to three years of growth rather than the current inbox. Confirm whether the candidate can import your current data, whether it supports the single sign-on your company uses, and whether a paid support subscription is available if the team cannot absorb an outage. Zammad sells self-hosted support subscriptions, and the lighter tools rely more on community support and your own partner. Migrating later from a light tool to a larger platform is possible but carries cost, so make the switch decision explicit at the start.
Requirements a small team must still meet
This table lists the requirements that still apply when a team has only a few agents, and what each one asks of the build. Read the regulatory references as the test for whether a rule binds you, and the build column as what to configure regardless. Many small teams are not subject to SEC Rule 17a-4 or HIPAA, so the requirement often comes from your business or contract instead.
| Requirement | What it asks for in the build | Evidence to keep or confirm |
|---|---|---|
| Shared mailbox intake | Connect each shared address to one helpdesk group, and encrypt mail transport (TLS) on inbound and outbound connections. Confirm which mailboxes can be read by which agents before go-live. | Mailbox-to-group mapping, TLS settings on the mail server, and a list of who can read each shared address |
| Agent access control | Give agents the fewest roles needed, separate admins from agents, and enforce single sign-on where your identity provider supports it. Remove accounts when people leave. | Role matrix, admin account list, and leaver deprovisioning records |
| Retention of customer communications | Set how long tickets, attachments and mail copies are kept, and delete on schedule. If SEC Rule 17a-4(b)(4) applies to you, it requires at least three years for broker-dealer communications, so confirm storage and deletion settings with counsel. | Written retention schedule, configured purge jobs, and proof of retained copies for the required period |
| Audit record of ticket changes | Turn on history for ticket edits, status, owner and assignment changes, and keep application logs off the agent's own machine. For ePHI under HIPAA 164.312(b), audit controls must record and examine activity in systems containing ePHI. | Ticket history samples, log retention period, and a documented review routine |
| Transport encryption for ePHI | Under HIPAA 164.312(e)(1), guard ePHI sent over networks with encryption in transit. Use HTTPS for the agent and customer portal, and TLS for mail and database connections. | Certificate inventory, TLS configuration reports, and network diagrams showing encrypted paths |
| Backup and restore | Back up the database, attachment storage and configuration together, and test a full restore on a separate host. Search indexes can be rebuilt, so confirm that path too. | Backup schedule, last successful restore test record, and a recovery time you have agreed with the business |
| Data export | Confirm you can export tickets, users and attachments in a usable format, both for a move to another tool and for a customer or legal request. | Export test results and a sample exported dataset checked against the source |
| Security updates | Apply vendor security releases on a set schedule. Zammad, FreeScout and osTicket each publish security fixes, so subscribe to their release notices and record each patch. | Patch log with dates and versions, and a test install of each update before production |
How FreeScout, osTicket and Zammad compare for a small team
Three open-source helpdesks cover most small-team shared inbox needs, but they differ in license, data stack and how much operating effort they demand. The cards below set out the fit, footprint and open questions for each, so you can match the tool to your channels, volume and growth plans before you commit.
FreeScout for a shared mailbox
FreeScout is a PHP helpdesk licensed under AGPL-3.0, with version 1.8.248 published on October 17, 2026. It is built around a shared mailbox, so a team that already runs everything through one support address can move quickly. Check the current documentation for channel connectors beyond email, the depth of reporting, and how modules are installed and maintained, because a small team will carry that upkeep itself. Ask whether the module you need is maintained by the core project or a third party.
osTicket for ticket-centric queues
osTicket is licensed under GPL-2.0, and its latest release in the supplied sources is v1.18.4, published on June 17, 2026. It has a long track record and treats each request as a ticket with departments, help topics and staff roles, which suits teams that route by category. Confirm how it handles inbound email threading, attachment storage and reporting against your needs, and check whether the plugins you rely on are current with the core version you deploy.
Zammad for growing teams
Zammad is licensed under AGPL-3.0, and version 7.2.2 was released on October 8, 2026 as a security update. It needs PostgreSQL 15 or newer and Redis 7 or newer for realtime updates, and Elasticsearch is optional but strongly recommended for search and attachment content. Expect a larger footprint than the PHP tools, with more services to back up and patch. Confirm the channel connectors and reporting you need in the current admin documentation before you choose it.
Comparing the data stacks
FreeScout and osTicket run on PHP with a relational database, while Zammad adds Redis for realtime updates and an optional Elasticsearch cluster for search. The extra services add hosting cost, patch work and backup scope, which matters most for a team without a dedicated platform engineer. Ask any implementation partner to size the components for your mailbox volume and attachment history before you choose, and to show how each service is backed up and restored.
Support and patching responsibilities
Community editions of these tools are free to use, but support and fast security patching depend on who is accountable. Zammad sells self-hosted support subscriptions, while FreeScout and osTicket rely more on community channels and partner support. Confirm the security release cadence for the version you choose and who applies releases in your environment. A small team should agree on a patch window and an owner before go-live, not after the first advisory.
When a team outgrows the lighter tools
Signs that a shared inbox is no longer enough include multiple channels to unify, SLA tiers that need automation, search across large attachment archives, and more agents sharing queues across teams. Zammad is designed for these needs, but migrating later costs time, so check channel, reporting and integration requirements now. Ask a partner to document the migration path and data export options from whichever tool you pick, and to confirm what the current release supports.
PHP versus PostgreSQL: what the stack means for running it
The main difference between FreeScout or osTicket and Zammad is how many moving parts your team must patch, back up and watch after go-live. FreeScout and osTicket are PHP applications that sit on a web server and a database, so the recurring work centers on the web tier, the PHP runtime and the application's own updates. Zammad, by contrast, documents a stack in which PostgreSQL 15 or newer holds the content, Redis 7 or newer handles realtime websocket communication, and Elasticsearch is optional but strongly recommended for search and attachment content search. Each component has its own version lifecycle, its own backup and restore procedure and its own alerting. Before you choose, count those components and decide who owns each one.
Zammad's documented requirements also list Nginx or Apache as the reverse proxy in front of the application. Someone must own TLS certificates, proxy configuration and the security headers that sit on that layer, in addition to the application itself. Memcached is needed only for multi-instance deployments such as containers or cluster nodes. A single installation can use the file system cache, which removes one service from the estate. Confirm with your platform team whether you will run one instance or several before you commit to a topology, because a later move from single to multi-instance adds a component and changes the patch cycle.
Treat the database and cache as the core of your runbook. Ask the implementation partner to document how PostgreSQL backups are taken and tested, how Redis is restarted without losing sessions you care about, and what happens to search if the Elasticsearch index must be rebuilt. Decide who receives alerts for each service and who signs off security releases. Zammad published security releases on more than one line in the same period, so the team must be able to apply patches on a predictable cadence. Ask for a written inventory of components, versions and owners as a deliverable, because that inventory is what keeps a small team from discovering a gap during an incident.
How a small team rolls out a shared inbox helpdesk
This sequence takes a few agents from a loose set of shared mailboxes to a single helpdesk with defined channels, controlled access, imported or fresh tickets, and a routine for patches and backups that someone owns after go-live.
Scope channels, mailboxes and agent roles
The team lists every inbox that receives customer requests today, including shared addresses, web forms and any phone or chat intake, and decides which of them move into the helpdesk first. It also names the agents, the groups they work in and who approves changes to routing and automations. Done means a written list of mailboxes with an owner for each, a short set of agent roles, and an agreed first-phase channel list that a reviewer outside the support team has signed off.
Choose the platform and hosting model
The team compares FreeScout and osTicket against Zammad using its own ticket volume, reporting needs, search expectations and the number of agents it expects to add. It also decides where the server runs, such as a cloud account, a data center or an existing virtual host, and who carries the operating system and database administration. Zammad's documented requirements include PostgreSQL 15 or newer, Redis 7 or newer and optional Elasticsearch, so the hosting decision must account for those components. Done means a recorded platform decision and a hosting sheet listing every server and service the platform will need.
Install and harden the server
An administrator deploys the chosen application using the vendor's documented method, sets up the database, mail transport and reverse proxy, and restricts administrative access to named accounts. For Zammad, the installation path, documented Docker Compose option and Kubernetes option each carry different support boundaries, so the team confirms which one it will run before installing. Hardening covers TLS on every public endpoint, restricted administrative interfaces, and a tested restore of the default configuration. Done means a staging instance answers over HTTPS, admin accounts are personal rather than shared, and the security settings are recorded in the runbook.
Connect email channels and single sign-on
The team configures inbound and outbound mail for each shared address, confirms that replies carry the correct sender and signature, and tests bounce and auto-reply handling. Where the organization uses a central identity provider, the administrator enables third-party login. Zammad documents SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab among other providers, but the team should confirm which option its identity provider supports and whether small agent groups need local accounts as a fallback. Done means test messages from an outside address create tickets in the correct group, and each agent signs in with the intended method.
Migrate existing tickets or start clean
The team decides whether history is worth moving. Zammad includes documented migrators for Freshdesk, Kayako, OTRS and Zendesk. Other sources, such as a spreadsheet, a different helpdesk or a mailbox archive, need the Zammad API or custom development, which the team should scope and price with a partner before committing. Starting clean is often the lower-risk path for a small team, with the old system kept read-only for a defined period. Done means a migration decision, a sample import checked against source records for ticket counts, attachments and customer identities, and an agreed archive location for the retired tool.
Train agents and write the first knowledge base articles
Agents work through a short script covering queues, assignment, internal notes, macros and escalation, using the staging instance with test tickets. The team then writes the first knowledge base articles from the most frequent requests in the last few months of mail, with each article assigned an owner and a review date. Done means every agent has closed a test ticket end to end, and the first set of articles is published with approvers recorded.
Cut over and set up patch and backup routines
The team moves the chosen mailboxes to the helpdesk, watches the first queue for routing errors, and keeps the old inbox forwarding in place until the new flow is stable. A named administrator then owns a routine for applying vendor security releases, since Zammad published security updates for both its 6.5 and 7.x lines in October 2026 and the team must track the line it runs. Backups cover the database, attachments and configuration, and a restore is tested on a separate host. Done means a dated patch calendar, a backup job with a recorded successful restore test, and a sign-off from the person accountable for the helpdesk.
Evidence a small team can produce on request
This table maps the evidence a small support team should be able to produce to the component that generates it and the owner who keeps it. Read each row as a question an assessor or customer might ask, then check whether your own setup answers it without a rebuild. The main takeaway is that most evidence comes from the helpdesk, the database, the reverse proxy and a change record you maintain, so it needs to be designed in from the start.
| Evidence | Produced by | What to confirm |
|---|---|---|
| Agreed retention period for conversations | Written retention decision, plus helpdesk settings and database retention jobs | Confirm the period with your legal or compliance owner and that deletion actually runs on the chosen tool |
| Activity records of agent actions | Helpdesk application logs and ticket history showing changes, assignments and notes | Confirm which actions are logged, how long logs persist and where they are forwarded |
| Access list per mailbox or queue | Helpdesk admin export of agents, groups and inbound mailbox assignments | Export it on a schedule and compare it against your identity provider user list |
| Login and authentication records | Reverse proxy logs (Nginx or Apache) and identity provider logs for SSO sign-ins | Confirm log retention and time synchronization across the proxy, app and identity provider |
| Backup and restore test records | Database backups of PostgreSQL, file attachments backups, and a dated restore test log | Keep a record of each restore test, including who ran it and the result, not only the backup job status |
| Patch log for security releases | Change record kept by the team, matched against Zammad, FreeScout or osTicket release notes | Record the version before and after each update and the date it was applied |
| Configuration and change history | Version-controlled configuration files and a change record for mailbox, channel and automation changes | Confirm who approves changes and whether secrets are kept out of the repository |
| Search index and attachment storage location | Elasticsearch and file storage settings documented in the deployment record | Confirm where attachments are stored and that the storage location matches your data residency decision |
When a team outgrows the lighter tools
Move from FreeScout or osTicket to Zammad when the team needs something the lighter tools were not built to carry. The clearest signals are a second or third inbound channel such as live chat or phone, a need to search inside email attachments, reporting and SLA tracking that managers rely on for staffing decisions, and a deployment that must run as several application instances behind a load balancer. Zammad documents Elasticsearch as the search and reporting backbone, and it lists Memcached as required for multi-instance deployments such as containers or cluster nodes, where a single installation could use the file system cache. Identity federation is another signal: Zammad supports third-party login through SAML and OpenID Connect, so if your directory must control agent access, check that the lighter tool you run offers the same integration before you commit to it.
The migration cost comes from four sources: the target stack (PostgreSQL 15 or newer, Redis 7 or newer, and Elasticsearch if you want attachment search), the effort to map queues, roles, SLAs and automations, the data move itself, and the parallel run while agents learn the new interface. Self-hosted Zammad carries no license fee, so most of the one-time spend goes to people and infrastructure. Recurring costs are hosting, backups, security patching and an optional support subscription, which Zammad sells in Business, Enterprise and Corporation tiers (the company's pricing page lists 2,999, 5,999 and 9,999 EUR per year). Ask any implementation partner to quote the migration, the infrastructure and the patch cadence as separate line items.
The move is easier when your data is clean from the start. Keep attachments in a consistent storage location and size policy, avoid duplicate agent and customer accounts, and use one email address per person with a clear source of truth for identity. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through its API, so check early whether your current tool's export contains ticket history, attachments and user links in a usable form. Confirm the Zammad version and the required database and cache versions in the current software requirements before you size the target, because they change between releases.
Questions small teams ask before choosing a self-hosted helpdesk
How much does a self-hosted helpdesk cost for a small team?
The software itself has no license fee when you self-host Zammad, but the total cost is not zero. You pay for the servers or cloud capacity that run the application, PostgreSQL, Redis and, if you use it, Elasticsearch, plus the people who install, configure, patch and back up the system. Optional vendor support is priced per year: Zammad's pricing page lists Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, with response times of 6, 4 and 2 hours respectively. Ask any partner for a quote that separates one-time work (installation, channel setup, migration) from recurring work (hosting, patching, support, monitoring). Your largest cost drivers are usually migration volume and the number of channels you connect.
Can a small support team run a self-hosted helpdesk without outside help?
Yes, if one person has solid Linux, database and web server skills and can commit time to patching. A small team with a single technically strong administrator can run FreeScout or osTicket on a standard LAMP-style stack. Zammad needs more care because it depends on PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy such as Nginx or Apache, and Elasticsearch is strongly recommended for search. The risk is not the first install but the ongoing work: security releases, backups, mail channel configuration and restore tests. Many teams keep one internal owner and buy a partner for the initial build, documentation and a support plan.
How long does it take to set up a self-hosted helpdesk?
Setup time depends mainly on the number of mailboxes and channels, the volume and format of historical tickets you migrate, identity integration and how much of the stack you build from scratch. A shared inbox with one mailbox and a few agents is a much smaller job than a helpdesk with web forms, chat, phone and a migration from a SaaS tool. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart, so the install path itself is well defined. Any duration a partner offers should come from a written, fixed scope with named deliverables, not from a general estimate. Ask for the scope, the channel list and the migration assumptions before comparing timelines.
Should a small team choose FreeScout or osTicket to save effort?
FreeScout and osTicket are lighter to run, which can reduce the effort of setup and maintenance for a team that needs a shared inbox and basic ticket tracking. FreeScout is licensed under AGPL-3.0 and osTicket under GPL-2.0, so check the license against how you plan to modify or distribute the code. Choose based on the features you need, not only on setup effort: confirm channel support, search, reporting, API access, SSO options and the migration path from your current tool. If you expect to add channels, automation, SLA tiers or many agents, a heavier platform such as Zammad may cost less effort over time than moving data later. Test both with a sample of real tickets before deciding.
What support options exist for AGPL or GPL helpdesk software?
The AGPL-3.0 and GPL licenses govern the code and do not include vendor support. Support comes from three places: the vendor's paid subscriptions, a community of users and maintainers, and independent service providers. For Zammad, the vendor sells self-hosted support subscriptions at the Business, Enterprise and Corporation levels described on its pricing page. For FreeScout and osTicket, confirm directly with the project or with a provider what support is available and at what response times. Independent partners can cover installation, hardening, backups, upgrades and documentation under a written scope. Ask any provider which security release process they follow, such as how quickly they apply releases like Zammad's 7.2.2 security update.
Which security and compliance checks matter for a small helpdesk?
A small team still holds customer messages, personal data and attachments, so the basic controls matter. Keep the application and its database on your own infrastructure, restrict admin access, enable single sign-on where the tool supports it, and log administrative actions. Retention of customer communications can carry regulatory duties in some sectors. For example, the SEC's Rule 17a-4(b)(4) requires broker-dealers to keep copies of business communications for not less than three years, and the HIPAA Security Rule at 45 CFR 164.312 requires transmission security and audit controls for ePHI. These rules apply only if they cover your business, so confirm them with your counsel. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.
When does a small team outgrow FreeScout or osTicket?
A team usually outgrows a lighter helpdesk when it needs more of the following: multiple channels such as chat and phone, search across attachments, reporting for managers, role-based queues, automation rules, third-party logins and a clear route for security releases. Zammad is the option in this group that documents Elasticsearch for search and reporting, Redis for realtime communication, and SAML, OpenID Connect and other third-party login methods. Plan the move before the backlog grows, because migrating a large ticket history is one of the costlier steps. Ask any partner to test the migration with a copy of your data and to confirm how attachments and users are carried over.
Questions to ask an implementation partner
Start with the platform decision, because every other answer depends on it. Ask the partner which of FreeScout, osTicket or Zammad they recommend for your ticket volume, number of agents, channels and reporting needs, and ask them to explain what would make them change that recommendation. A credible answer names the trade-offs: FreeScout and osTicket keep the PHP footprint small, while Zammad's PostgreSQL 15 or newer, Redis 7 or newer and recommended Elasticsearch add components you will need to run, patch and back up. Ask for the hosting footprint in writing, including which services run on which hosts, how Memcached is used if you deploy in containers, and who owns the reverse proxy, TLS certificates and backups.
Ask how mailboxes and attachments will move, and where they will live afterward. The partner should describe how each shared inbox is connected, how historical threads are imported, whether attachments are kept in the database or on disk, and how duplicate contacts are merged. If you are leaving a US-hosted tool, ask whether the migration is a supported importer or custom work, because Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk and other sources typically need the API or custom development. Ask for a sample migration on a copy of your data before cutover, and ask who checks the imported tickets against the source.
Security patching needs a specific answer. Zammad published 7.2.1 on October 6, 2026, 7.2.2 on October 8, 2026 and 6.5.5 on October 15, 2026, so security fixes are arriving on two release lines at once. Ask the partner how they track both lines, how quickly they test and apply security releases, how they roll back a failed update, and whether patching is covered by the support plan or a separate retainer. For each option, ask which self-hosted support tier is included and what the response times are, since Zammad's own subscriptions are priced and timed differently from partner work. Finally, ask for the fixed-scope deliverables in writing: the installed components, the configured channels and roles, the migration report, the runbook, the backup test and the handover session, with acceptance criteria for each.
How DeployOpen scopes and supports a small helpdesk
This sequence turns a shared inbox requirement into a written, fixed-scope plan, a self-hosted helpdesk running in your infrastructure, and a support model your team can operate after handover.
Confirm the team's channels and volume
DeployOpen reviews which inboxes, web forms and phone or chat sources feed the helpdesk today, how many agents work each queue, and which tool, if any, is being replaced. The output is a short requirements note listing channels, agents, shared mailboxes and the systems tickets must connect to. You know this step is done when your team has signed off the list and the open questions are assigned to named owners.
Choose FreeScout, osTicket or Zammad
Based on the requirements note, DeployOpen compares the lighter tools with Zammad on the points that matter for your team: database and cache dependencies, search needs, channel handling, reporting and the support model you want. The recommendation names the platform and explains what would trigger a move to a larger deployment. You know this step is done when the choice is documented with the reasons and the rejected options are listed.
Confirm the target hosting and access model
DeployOpen works with your team to agree where the helpdesk runs (your cloud account, a data center or a private network), how administrators reach it, how agents sign in, and how attachments and backups are stored. Identity integration is confirmed against the login options of the chosen platform, not assumed. The output is a hosting and access design that your security team can review. You know this step is done when that design is approved in writing.
Agree a fixed-scope written statement of work
DeployOpen writes the scope, deliverables, responsibilities and acceptance criteria before any build starts, including data migration, channel setup, hardening, backup, documentation and training. Optional items such as security testing or compliance-readiness support are listed as separate lines so they can be accepted or declined. Quotes follow from this written scope and recurring costs are shown apart from one-time work. You know this step is done when both parties have signed the statement of work.
Build, connect and migrate in staging
DeployOpen installs the platform in a staging environment, configures mailboxes, queues, roles, SLA rules and any reverse proxy or search components the chosen tool needs, and migrates existing tickets and attachments where the source system allows it. Imported data is checked against counts and sample records agreed with your team. You know this step is done when a staging run has passed the agreed acceptance checks and migration gaps are documented.
Harden, back up and test recovery
DeployOpen applies the hardening baseline for the platform, restricts administrative access, sets up encrypted backups of the database and attachment storage, and runs a restore test to confirm that backups work. Results are recorded in the runbook. You know this step is done when a restore has been completed and the test record is in your evidence folder.
Cut over and train the team
DeployOpen moves mail routing and channel connections to production during an agreed window, watches the first working days for delivery and queue issues, and runs role-based training for agents, team leads and administrators. The output is a live helpdesk and a short list of known issues with owners. You know this step is done when every channel delivers tickets to the right queue and the agreed training sessions are complete.
Document, hand over and support ongoing operations
DeployOpen delivers the runbook, architecture notes, change log and access register, and records how security releases will be applied. Ongoing support, upgrades and continuous testing can be contracted as a retainer, and optional security testing or compliance-readiness work can be scoped separately. You know this step is done when your administrators can perform a routine upgrade and restore from the documentation alone.
