osTicket vs FreeScout: which to choose

osTicket or FreeScout: which helpdesk fits a small support team

For a small support team, osTicket fits when work arrives as form submissions and email ticket queues that agents assign and close one by one, and FreeScout fits when the team works a shared inbox across several mailboxes. osTicket is the stronger choice when identity controls matter most, because its core plugins cover LDAP, CAS, OAuth2, two-factor authentication and password policy from the osTicket-plugins repository. It needs Apache or Microsoft IIS, PHP 8.2 to 8.4 with the mysqli extension and MySQL 5.5 or greater, and the README recommends PHP 8.4. FreeScout is the better fit when agents reply to customers from shared addresses and need to see who is handling a thread. Its README lists unlimited agents, tickets and mailboxes in the free download, with OAuth for Microsoft 365 and Google Workspace, and it runs on PHP 7.4 to 8.x with MySQL, MariaDB or PostgreSQL.

Identity requirements are the first driver. If your directory is LDAP and your mail sits in Microsoft 365 or Google Workspace, check which sign-in path each platform supports for your agents before you pick one. Confirm whether the FreeScout SAML SSO module, which is a paid module on its modules page, is worth buying for your SSO tier, and whether the LDAP Integration module is needed as well. Second, decide whether a shared inbox matches how your mail is actually worked. Third, ask who will run upgrades and backups. osTicket upgrades are documented from 1.6-rc1 onward with a recommendation to back up attachments, the database and the codebase first, and FreeScout releases arrive roughly weekly. A small team without a sysadmin should price that maintenance time before choosing the free option.

Which helpdesk fits which support scenario

This table maps common support scenarios to the platform that usually fits better and the condition that decides it. Read each row against your own mailbox model, identity requirements and database standard, since the better fit can flip when one condition changes.

Scenario	Better fit	Condition that drives the choice
Shared support mailbox worked by a small team	FreeScout	FreeScout is built around a shared inbox with collision detection, and its README lists unlimited mailboxes over SMTP, IMAP and POP3. Choose osTicket instead if requests should arrive mainly through web forms and phone-logged tickets.
Web form intake with assignment to agents	osTicket	osTicket's README describes tickets created from email, phone and web forms and assigned to agents in a multi-user interface. Confirm that your intake volume and routing rules fit its ticket model before committing.
Team that needs SAML single sign-on	FreeScout (paid module) or osTicket (confirm plugin)	FreeScout's SAML SSO is a paid module sold as a lifetime license for one instance. osTicket's core plugins list LDAP, CAS, OAuth2 and passthrough, not SAML, so confirm SAML availability with the plugin maintainers or your integrator.
Team that wants knowledge base content	FreeScout (paid module)	FreeScout lists a Knowledge Base module as paid. osTicket's supplied plugin facts do not cover a knowledge base, so confirm what its current release provides before choosing it for self-service articles.
Team that requires PostgreSQL as the database standard	FreeScout	FreeScout supports MySQL, MariaDB or PostgreSQL. osTicket's README requires MySQL 5.5 or greater with the mysqli extension, so it fits only where MySQL is acceptable.
Team that needs LDAP or directory-based sign-in	Either, confirm the plugin path	osTicket offers LDAP as a core plugin. FreeScout lists LDAP Integration as a paid module. Compare the total licensing cost and confirm that the module version matches your directory setup.
Team with limited hosting and minimal server resources	FreeScout	FreeScout's README states no minimum CPU or RAM requirements and says it can run on shared hosting. osTicket requires PHP 8.2 to 8.4 with mysqli and a web server such as Apache or IIS, so plan a dedicated stack.
Team that wants a hosted option with published per-agent pricing	osTicket	osTicket publishes a cloud edition starting at $12 per agent per month on its editions page. FreeScout's supplied facts cover managed hosts and one-click installs but no per-agent hosted price, so ask those vendors for a quote.

How the ticket and inbox models differ in daily work

osTicket treats every inbound inquiry as a ticket. Email, phone and web forms all create tickets that are saved in one multi-user web interface and assigned to agents, so the working unit is a record with an owner. For a team that already runs requests through a queue, this matches the way work moves: an agent picks up a ticket, it has a single assignee, and its history stays on that record. Before you commit, map each of your intake channels to osTicket's form, email and phone handling, then confirm with a test installation how assignment and transfer between agents behave in the version you plan to deploy. Authentication plugins such as LDAP or two-factor authentication add controls around agents but do not change the ticket model itself. See the osTicket README for the intake description.

FreeScout starts from a shared inbox. Conversations arrive from connected mailboxes over SMTP, IMAP or POP3, and the FreeScout README also lists WhatsApp, Telegram, Facebook, Slack and live chat as channels that can be centralized. Its collision detection is the control that matters most in daily use: it helps agents see when a colleague is already working on a conversation, which reduces duplicate replies when several people share one address during a busy period. The daily question shifts from who owns a ticket to who is answering this conversation right now. Routing depends on how you structure your mailboxes, and rule-based automation sits in the paid Workflows module listed on the FreeScout modules page, so price that module into any comparison.

Choose by how requests already arrive. If most demand comes as email to a few shared addresses and the team answers as a group, the shared-inbox pattern fits. If requests come through forms and phone calls and each one needs a named owner with a clear hand-off, the ticket pattern fits better. To test this, run a sample of one week of actual requests through both models (illustrative): count conversations with more than one responder, count transfers between agents, and list the reports your team leads need. Reporting and routing detail differ by version and edition, so confirm them against the current documentation and a running instance before you decide.

How each helpdesk is built and what that means for operations

Both products are lightweight PHP helpdesks, but they ask for different web stacks and deploy differently. The cards below cover the server stack, the deployment method, the sizing question and the upgrade habits each one assumes, so your operations team can estimate the work before choosing.

osTicket web and database stack

osTicket runs on Apache or Microsoft IIS with PHP 8.2 to 8.4, where 8.4 is recommended, and needs the mysqli extension plus MySQL 5.5 or greater. If your standard platform is PostgreSQL or you run PHP outside the 8.2 to 8.4 range, that is a gap to close before the first install. Confirm the supported combination against the current README and your own patching cycle.

osTicket deployment from a clone

The README describes deploying from a clone of the public repository with php manage.php deploy and pulling later updates with git pull before redeploying. Operations teams should treat the checkout as the system of record, which means pinning the release tag, keeping local changes out of the tree, and scripting the redeploy step. Ask who owns that process after go-live.

FreeScout on Nginx, Apache or IIS

FreeScout runs on Nginx, Apache or IIS with PHP 7.4 to 8.x and MySQL 5.0 or later, MariaDB 5.0 or later, or PostgreSQL. The wider PHP range makes it easier to fit an existing web host, but it also means your PHP version policy will decide which FreeScout release line you can run. Confirm that policy before you pick the database.

FreeScout install options

FreeScout offers a Docker image and one-click installs through Softaculous, Cloudron and managed hosts. A container image suits teams that already run Docker and want a repeatable rebuild, while one-click installs suit a single small instance. Whichever route you take, decide who maintains the image or host and how upgrades reach it, since the two projects publish releases on different cadences.

Sizing for your mail volume

The FreeScout README says there are no minimum CPU or RAM requirements and that it can run on shared hosting. That statement does not tell you how the instance will behave under your inbound mail volume, attachment sizes or mailbox count. Load test with a realistic copy of your mailboxes, and confirm sizing for osTicket too, since its ticket volume and attachment storage drive the database and disk footprint.

Upgrade and backup routine

The osTicket README recommends backing up attachment files, the database and the codebase before any upgrade, and it lists the versions that can be upgraded from. Budget a rehearsal on a staging copy before each upgrade in production. Ask FreeScout's maintainers or your host how their release process handles migrations, since its releases arrive roughly weekly.

Capabilities compared: authentication, extensibility and integrations

This table compares how osTicket and FreeScout handle licensing, authentication, storage, APIs, automation and mobile access, so you can see which capabilities come with the free download and which depend on a plugin or paid module. Read each row against your own identity provider, storage policy and automation needs, and treat any cell marked to confirm as an open question for the vendor or your own test install.

Capability	osTicket	FreeScout
License	GPL2 for the free download; cloud and virtual appliance editions are sold separately	AGPL-3.0 open-source core; paid modules sold as lifetime licenses for one instance
Directory and LDAP sign-in	LDAP available as a core plugin from the osTicket-plugins repository	LDAP Integration is a paid module; confirm current pricing on the modules page
SAML or OIDC single sign-on	CAS and OAuth2 plugins are listed; confirm which OAuth2 providers are supported	SAML SSO is a paid module; OAuth is built in for Microsoft 365 and Google Workspace mailboxes
Two-factor and password policy	Two-factor authentication and password policy are core plugins	Not listed in the README or modules page; confirm before relying on it
Attachment storage	Filesystem or S3 storage through the attachment storage plugin	S3 Storage module is free; confirm storage options beyond S3 in the docs
API and automation	Confirm API coverage and endpoints in the osTicket documentation	Built-in API, plus Zapier and Make integrations; API and Webhooks is a paid module
Knowledge base and reporting	Confirm available modules for knowledge base features in your edition	Knowledge Base and Satisfaction Ratings are paid modules
Mobile apps	Confirm whether an official mobile client exists before planning field use	Android and iOS apps offer the same functionality and modules as the web version

What is free and what is paid in each helpdesk

osTicket is released under the GPL2 license, so the core download is free to use, modify and run on your own servers. The free route comes with community support only, which means you rely on public forums and documentation rather than a contracted response commitment. osTicket also sells two paid routes: a cloud-hosted edition, which the editions page lists starting at $12 per agent per month, and a virtual appliance edition with custom pricing that you must quote directly.

Free download: the GPL2 codebase is free, and the core plugins for LDAP, CAS, OAuth2, two-factor authentication, password policy, audit and S3 or filesystem attachment storage are also free to use.
Cloud edition: a per-agent monthly price starting at $12, hosted and maintained by osTicket.
Virtual appliance: priced on request, so ask for a written quote that states what is included and what updates cost.
Community support: the free route has no contracted support, so budget for your own staff time or an outside partner.
Recurring costs: self-hosting still costs infrastructure, PHP and MySQL administration, backups and upgrades, none of which the license covers.

Before committing, confirm each plugin's license and terms in the osTicket-plugins repository, since core plugins may differ from third-party plugins in support and licensing, and confirm what the virtual appliance quote includes.

What drives running cost for osTicket and FreeScout

Both platforms are free to download, so the running cost comes from the work around them: hosting, PHP and database administration, mail integration, plugins or paid modules, and upgrades. Each card below separates a one-time setup cost from a recurring one and names what to request in a written scope.

Hosting and infrastructure footprint

FreeScout's README states there are no minimum CPU or RAM requirements and it can run on shared hosting, which keeps a small deployment cheap to start. osTicket runs on Apache or IIS with PHP 8.2 to 8.4 and MySQL 5.5 or greater, so it needs a stack that someone must keep patched. Ask the partner for the server count, backup storage and whether the quote includes monitoring for each environment.

PHP and database administration labor

Both helpdesks are PHP applications, so the recurring cost is someone who can manage PHP versions, extensions such as mysqli, and the database engine. FreeScout also accepts PostgreSQL, which may suit a team that already runs it. Confirm who owns PHP security updates, who tunes the database, and whether that work is billed monthly, per incident or inside a retainer.

Paid modules and cloud edition spend

osTicket's cloud edition starts at $12 per agent per month, which recurs with headcount. FreeScout's modules are sold as lifetime licenses for a single instance with lifetime updates, so the cost is largely one-time per module. Compare the modules you need, such as LDAP Integration or SAML SSO, against the per-agent cloud price over the expected life of the team.

Plugin and module maintenance

osTicket's core plugins for LDAP, CAS, OAuth2, two-factor authentication and S3 storage come from a separate repository and must be re-tested after each core upgrade. FreeScout modules are versioned separately from the core, so a core update can require a module update. Ask who tests plugin compatibility, how long that takes per release and whether module licenses are included in the quote.

Backup and upgrade labor

osTicket's README recommends backing up attachment files, the database and the codebase before every upgrade, and it asks for a deliberate deploy step after each git pull. FreeScout releases arrive roughly weekly, so the same backup and test cycle repeats more often. Ask for the frequency of backups, the restore test schedule, the upgrade window and the rollback method in the written scope.

Mail server integration effort

Both products depend on mailboxes, and osTicket's value rests on turning inbound email into tickets, so mail routing, SPF, DKIM and IMAP or POP3 connectivity drive setup time. FreeScout connects over SMTP, IMAP and POP3 and offers OAuth for Microsoft 365 and Google Workspace, which can reduce password handling but adds app registration work. Confirm who configures the mail flow, who owns the registration and whether testing covers bounces and threading.

Moving between osTicket and FreeScout without losing history

This sequence moves mailboxes, users, departments, ticket history and attachments from one helpdesk to the other, with a tested cutover so that customers keep getting answers in the same thread.

Inventory mailboxes, users, departments and attachments
Start by listing every inbound and outbound mailbox, every agent and their role, every department or team, and where attachments are stored today (database or filesystem). Your osTicket admins own this list, and the output is a signed-off inventory spreadsheet that maps each source object to a target object in FreeScout. Note any custom fields, canned responses and auto-response templates, because these rarely move by themselves and must be recreated or exported. Confirm that the inventory covers every address that customers actually write to, including forwarding aliases, since missing one is the most common reason for lost mail after cutover.
Confirm the FreeScout migration path with the vendor
Before you write any export script, ask FreeScout whether its migration service supports an osTicket source, what it imports (conversations, threads, customers, attachments, agents), and what it does not. The FreeScout README links a migration service and an API, but you should confirm in writing which of these covers osTicket specifically and whether it runs against your database or against an export. Ask for the supported FreeScout and osTicket versions. The output is a short written answer that tells you whether you need a custom export and import, or whether the vendor path is viable.
Export tickets and map them to conversations
Export tickets from osTicket with their threads, status, assignee, department, timestamps and attachments, using the database or the admin tools available in your release. Map each osTicket concept to its FreeScout equivalent: tickets become conversations, thread entries become threads, and departments usually map to mailboxes or folders, which is a design decision rather than a one-to-one copy. Write the mapping down, including how internal notes and status values translate. The output is a mapping document and a sample export file that a second person has reviewed.
Import and verify a sample set
Load a representative sample into a non-production FreeScout instance. Choose tickets that cover edge cases: long threads, multiple attachments, closed and reopened tickets, tickets with CC recipients, and tickets from every department. Check that message order, timestamps, sender identity, attachment integrity and assignee are correct, and that customer records are not duplicated. Record every mismatch and decide whether it is fixed in the script or accepted and documented. The check is complete when the sample passes a written checklist that the support lead signs.
Rebuild users, roles and automation
Some items are rebuilt rather than carried over. Recreate agent accounts and their permissions in FreeScout, and decide how authentication will work, since osTicket plugins for LDAP, CAS or OAuth2 do not transfer to FreeScout automatically and FreeScout's LDAP and SAML modules are paid. Rebuild canned responses, auto-replies, SLA-like routing and any webhook or scripted automation. Confirm the cost and licensing of any FreeScout module you need with the vendor before you rely on it. The output is a rebuild list with an owner for each item.
Cut over mail routing and run both systems briefly
Change MX, forwarding or alias rules so that new inbound mail reaches FreeScout, while osTicket remains reachable for replies on existing threads. Keep osTicket read-only or running for a defined overlap period agreed by your team. Watch for mail that still arrives at the old address, and confirm outbound messages carry correct reply headers so customer replies land in the right conversation. The check is that a set of test messages from each mailbox arrives, threads correctly, and sends a reply that the customer can respond to.
Retire osTicket with a verified backup
Once cutover is confirmed and the overlap period closes, take a final backup of the osTicket database, attachment files and codebase, following the backup guidance in the osTicket README. Store it under your retention policy, then disable the old mailboxes, remove scheduled jobs and revoke agent access. Record the date and the location of the archive so that anyone who needs historical tickets knows where to look. The closing check is an archive that restores to a test environment, which proves the history is recoverable even after the live system is gone.

Upgrade paths and the backup work you keep

Plan the upgrade process before you choose between these two helpdesks, because the backup and change-control work you carry is the part that recurs. The osTicket README says upgrades are supported from 1.6-rc1 and later, and it recommends that you back up attachment files, the database and the codebase before every upgrade. Treat those three items as a single restore set. A database backup without the matching attachments leaves tickets that load but show broken files, and a codebase copy from a different point in time can fail against a restored schema. Confirm the exact restore order against the osTicket README for your version, and rehearse it once before you need it.

FreeScout ships much more often. The FreeScout releases page showed 1.8.248 on October 17, 2026, and the project publishes releases roughly weekly. That cadence is useful if you want fixes quickly, but it means you will face an update decision many times a year, not once. Each update needs a short test pass on your own mailboxes, modules and integrations, because a module built for one release may need checking after another. Decide in advance who approves updates, how long a version can lag behind, and which modules are considered business critical. Ask your team whether they can absorb that rhythm without a dedicated owner.

Whichever platform you choose, run a staging environment that mirrors production: the same PHP and database versions, a copy of the attachment store, and the same mail routing and authentication settings, with outbound mail redirected so test traffic never reaches customers. Apply the update there first, then send a test ticket through each inbound channel and confirm that assignment, notifications and login still work. Keep the pre-change backup until the staging result is signed off. Staging is the control that makes a weekly release cadence or a rare major upgrade equally manageable.

Questions buyers ask before choosing osTicket or FreeScout

Is osTicket or FreeScout cheaper to run?

Both products are free to download under open-source licenses, so the difference comes from what you pay around the core software. osTicket's free download comes with community support only, its cloud edition starts at $12 per agent per month, and its virtual appliance edition is custom priced. FreeScout's core has no per-agent fee, but its LDAP and SAML SSO modules are paid lifetime licenses for a single instance. Your recurring costs depend on hosting, staff time for upgrades and backups, module licenses and any support contract. Ask for a written quote that lists each of these items separately, including the number of FreeScout instances you will license.

What does SSO cost in FreeScout?

SAML SSO is a paid FreeScout module, sold as a lifetime license for one FreeScout instance with lifetime updates. OAuth sign-in for Microsoft 365 and Google Workspace is listed in the FreeScout README, so confirm with the vendor whether your identity setup falls under that option before you buy a module. Check the FreeScout modules page for current module pricing, because no price is supplied here. The cost grows with the number of instances you run, whether you need SAML or only OAuth, and the configuration work on your identity provider. Ask for the module price, the license scope, and the expected configuration effort in writing.

Does osTicket need a paid edition for LDAP?

No paid osTicket edition is needed for LDAP authentication, because the LDAP plugin is one of the core plugins in the osTicket-plugins repository. The same set includes CAS, OAuth2, passthrough authentication, two-factor authentication, password policy, audit and filesystem or S3 attachment storage. Confirm that the plugin version matches your osTicket release, then test group mapping and TLS settings against your directory before you rely on it. Also confirm the plugin license terms with osTicket, since the supplied facts do not state them. Support is a separate question: the free download has community support only, so a response commitment means buying a paid edition or a support engagement.

How long does a helpdesk migration take?

The duration depends on scope, and no timeline is supplied for either product. The main drivers are the number of mailboxes and channels, the years of ticket history, the volume of attachments, custom fields and forms, and the integrations that must be rebuilt. FreeScout's README links a migration service for moving to FreeScout from other help desks, which is worth asking about if you are leaving another tool. For osTicket, confirm what import and mapping work is required for your source system. DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so the timeline should come out of that written scope.

What does the internal team need to run either helpdesk?

The team needs someone who owns the web and PHP stack, the database, mail routing and backups. For osTicket, the README requires Apache or Microsoft IIS, PHP 8.2 to 8.4 (8.4 recommended) with the mysqli extension, and MySQL 5.5 or greater. For FreeScout, the requirements are Nginx, Apache or IIS, PHP 7.4 to 8.x, and MySQL 5.0+, MariaDB 5.0+ or PostgreSQL, with no minimum CPU or RAM stated in the README. Plan for:

Patching PHP, the web server and the database on a schedule
Mail configuration for SMTP, IMAP or POP3, and any OAuth setup
Backups of the database, attachments and codebase, with tested restores
A named owner for agent accounts, departments and workflow rules

Can our team run osTicket or FreeScout upgrades ourselves?

Yes, if you have a staff member who can follow the documented process and keep time for it. The osTicket README states that upgrades are supported from 1.6-rc1 and later, and it recommends backing up the attachment files, the database and the codebase first. Its documented deployment path uses php manage.php deploy and git pull to apply updates. FreeScout publishes releases roughly weekly, with 1.8.248 released on October 17, 2026, so the cadence of upgrades matters as much as the steps. Community support is the only support included with the osTicket download. If you prefer to hand off upgrades, backups and documentation, DeployOpen can take them on under a fixed scope or a retainer.

Which helpdesk fits a team that works from shared mailboxes?

FreeScout fits a team that works from shared mailboxes, because its model is a shared inbox where conversations from email, and from channels such as WhatsApp, Telegram, Facebook, Slack and live chat, are centralized. Its README lists unlimited agents, tickets and mailboxes, plus IMAP, POP3 and SMTP email integration. osTicket fits teams that want structured intake through email, phone and web forms, with tickets saved and assigned to agents in a multi-user interface. The choice turns on your intake channels and workflow rules, so test both with a sample of real mail flows before you decide. Confirm which channel integrations you need, since some may require paid modules or custom work.

How DeployOpen helps you choose, implement or migrate

DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. For osTicket vs FreeScout, we start from your team's ticket volume, email flows, identity requirements and hosting constraints, then turn that into a written scope before any work begins.

How we scope

Map how your support requests arrive today across email, web forms and shared mailboxes, and which of those must land in one queue
Confirm which authentication path you need, such as LDAP, OAuth for Microsoft 365 or Google Workspace, or SAML, and which modules or plugins that requires
Agree in writing on the hosting target, PHP and database versions, and whether attachment storage stays on the filesystem or moves to S3

How we build

Install and configure the chosen helpdesk in your environment, with mailboxes, departments, roles and SLA-related settings set to your written scope
Set up the authentication integration and test sign-in, password policy and two-factor behavior with a representative set of agent accounts
Run functional and security testing on the deployed helpdesk, including the forms, email ingestion and API endpoints in scope, and record the results

How we hand over

Document the installed configuration, plugin or module list, mailbox routing and upgrade procedure so your staff can operate the system
Provide backup and restore runbooks covering the database, attachments and codebase, aligned with the upgrade guidance from each project
Walk your administrators through daily operation and confirm acceptance against the written deliverables before closing the engagement

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts and any change is handled through that scope
Ongoing support, upgrades and continuous testing are available as a retainer if your team wants DeployOpen to keep the platform current
Ask any quote to itemize installation, integration, testing, documentation and handover separately so you can see what recurs and what is one-time

osTicket vs FreeScout