Choosing a Freshdesk alternative for email, phone and web form tickets
osTicket fits teams that want self-hosted, straightforward ticketing and can run PHP and MySQL themselves, while Freshdesk fits teams that want a hosted service with upgrades handled by the vendor. The choice usually starts with a renewal, a pricing change or a data control requirement, but the decision itself turns on three questions: who will operate the stack, which channels and plugins the team needs, and whether community-only support is acceptable for the free edition. Answer those before comparing feature lists. Start with operations. osTicket needs Apache or Microsoft IIS, PHP 8.2 to 8.4 (8.4 recommended) with the mysqli extension, and MySQL 5.5 or greater, according to the osTicket README. Someone must patch the web server, PHP, the database, and the osTicket codebase, and must back up attachment files, the database and the code before each upgrade, as the README recommends. Confirm that your platform team has that capacity and a tested restore procedure before you commit.
Next, map your channels and authentication needs to the core plugins. The osTicket-plugins repository holds core plugins for osTicket 1.8 and later, including LDAP, CAS, OAuth2 and passthrough authentication, two-factor authentication, password policy, audit, and attachment storage on the filesystem or S3. Check each one against your identity provider, your audit obligations and your retention rules for attachments, and confirm plugin compatibility with the osTicket version you plan to run. Finally, weigh support. The free download comes with community support only, so a production outage or a compliance question has no contractual response behind it. If that risk is unacceptable, ask Freshdesk for its plan terms and compare them with the cost of a fixed-scope implementation and retainer support from a provider such as DeployOpen.
Which option fits which scenario
This table matches common team situations to the better fit between Freshdesk and osTicket. Read each row for the team's constraint, then check the reason against the facts on the free edition, core plugins and supported platforms. The main takeaway is that osTicket suits teams that can operate PHP and MySQL and accept community support, while Freshdesk suits teams that want a managed service with vendor support.
| Team situation | Better fit | Why |
|---|---|---|
| Small support team handling mainly email and a web form | osTicket | osTicket integrates email, phone and web form inquiries into one multi-user interface where tickets are assigned to agents, and the free download needs no per-agent fee. |
| Team that must keep attachments in its own S3-compatible store | osTicket, if an operator can maintain the plugin | The osTicket-plugins repository includes S3 attachment storage as a core plugin, but you must confirm its compatibility with your specific store before committing. |
| Team with no PHP or MySQL operator | Freshdesk | osTicket requires Apache or IIS, PHP 8.2 to 8.4 and MySQL 5.5 or greater, so someone must own those layers, while Freshdesk is run by its vendor. |
| Team that needs vendor support contracts | Freshdesk | The free osTicket edition offers community support only, so a paid support path means the cloud or virtual appliance editions, which must be checked against your requirements. |
| Team that wants LDAP, OAuth2 and two-factor sign-in on its own servers | osTicket | LDAP, OAuth2 and two-factor authentication are listed among the core plugins, but you need to test each plugin against your identity provider and PHP version. |
| Team that needs a strict upgrade and backup routine it controls | osTicket | The README recommends backing up attachments, the database and the codebase before upgrading, and deploys updates with git pull and php manage.php deploy under your own schedule. |
| Team that needs a fully managed service with no infrastructure work | Freshdesk | Freshdesk is delivered as a hosted service, so patching, hosting and uptime sit with the vendor rather than your staff. |
| Team that wants audit logging in its own environment | osTicket | An audit plugin is available in the core plugin set, so confirm which events it records and where its logs are stored for your assessors. |
Which osTicket core plugins cover authentication, audit and storage
osTicket's core plugins cover sign-in, second factors, password rules, audit and attachment storage without third-party code. Each one matters under a specific condition, so the choice depends on how your staff authenticate and where attachments may live.
Directory and single sign-on
The osTicket-plugins repository holds LDAP, CAS, OAuth2 and passthrough authentication plugins. Choose LDAP when staff already sign in through an Active Directory or LDAP directory and access must end when a directory account is disabled. Choose OAuth2 or CAS when your identity provider already issues tokens or CAS tickets. Passthrough suits environments where the web server has already authenticated the user. Confirm which of these your identity provider supports and test deprovisioning before go-live.
Two-factor authentication
The two-factor plugin adds a second step to staff sign-in. It matters when agents can see customer personal data or when staff accounts are reachable from outside the corporate network. Confirm which second-factor methods the plugin supports and whether it applies to agents only or also to administrators. Plan how lost devices are recovered, since recovery procedures are a common source of support load and access gaps.
Password policy
The password policy plugin enforces rules on staff passwords beyond the defaults. It matters when your security standard requires minimum length, complexity or reuse limits that the base install does not enforce. Note that it governs local osTicket accounts. If you authenticate through LDAP or SSO, password rules stay in your directory, so check which system is the source of truth before configuring it.
Audit logging
The audit plugin records staff actions so reviewers can see who changed or viewed a ticket. It matters when a regulator, internal audit or a customer contract asks for evidence of access to support records. Confirm what the plugin captures, where the records are stored, who can read them, and how long your retention policy keeps them. Export or forward these logs to your central logging platform if you need tamper resistance.
Attachment storage on S3
The attachment storage plugins write files to the filesystem or to S3. Filesystem storage keeps attachments on the web server or a mounted volume, which suits small deployments. S3 storage moves attachments out of the web server, which helps when attachments must sit in a separate, encrypted bucket or when web nodes are replaced often. Ask your storage team whether the bucket is S3-compatible and whether it is inside your approved region. Back up attachments with the database, as the upgrade guidance recommends.
How Freshdesk and osTicket compare on capability
This table sets Freshdesk's hosted service desk against osTicket, a self-hosted GPL-2.0 ticketing system, row by row on intake, agent work, security controls, data export, upgrades and support. Where a Freshdesk plan feature is not covered by our research, the cell tells you what to confirm with Freshdesk. The main takeaway is that osTicket's core plugins cover the controls most teams ask about, but you own their configuration, testing and upgrades.
| Capability | Freshdesk | osTicket (self-hosted) |
|---|---|---|
| Intake channels (email, phone, web forms) | Email, web forms and other channels per plan; confirm phone and channel availability on your plan with Freshdesk | Email, phone and web forms integrated into one ticket system, per the README |
| Multi-user agent interface and assignment | Agent workspace with ticket assignment; confirm routing and automation rules included in your plan | Multi-user web interface where incoming tickets are saved and assigned to agents, per the README |
| Authentication options | Vendor-managed sign-in; confirm SSO options and identity provider support with Freshdesk | LDAP, CAS, OAuth2 and passthrough authentication through core plugins from the osTicket-plugins repository |
| Two-factor authentication | Confirm the two-factor methods available on your plan with Freshdesk | Two-factor authentication is available as a core plugin; confirm the methods it supports in your version |
| Audit and logging | Confirm audit trail depth and retention for your plan with Freshdesk | Audit is available as a core plugin; confirm which events it records and where logs are kept |
| Attachment storage | Vendor-hosted storage in the Freshdesk data center region you chose; confirm region options | Filesystem or S3 attachment storage through core plugins, so you choose where files sit |
| Admin export path | Admin, Account, Account Details, Export data produces XML of tickets, solutions, forums and customers on all plans | Data lives in your own MySQL database and attachment store, so export is a database and file task for your team |
| Hosting and runtime | Vendor-operated SaaS; no servers for you to run | Apache or Microsoft IIS, PHP 8.2 to 8.4 (8.4 recommended) with mysqli, and MySQL 5.5 or greater |
| Upgrade process | Vendor applies platform updates; confirm release notice and change control terms | Upgrades supported from 1.6-rc1 onward; back up attachments, database and codebase first, per the README |
| Support model | Support included with your Freshdesk plan; confirm tiers and response terms in writing | Community support only for the free download; confirm any paid options with osTicket before you rely on them |
Where the data sits with a self-hosted osTicket
With a self-hosted osTicket, the tickets, attachments and database live wherever your team deploys the application, whether that is your own data center, a cloud account you control or an air-gapped network. Your team decides where backups go, who holds database credentials and how long attachments are kept. With Freshdesk, the account data sits in the vendor's hosted service, and you choose only among the data center options Freshdesk offers. Its account export gives you a copy of tickets, solutions, forums and customers as XML from Admin, Account, Account Details, Export data, but that copy is a snapshot, not a live replica of the service. Confirm with Freshdesk which regions apply to your account, how long deleted tickets and attachments are retained and what the contract says about data return on exit.
Identity and access are where a self-hosted osTicket needs deliberate design. The core LDAP and OAuth2 authentication plugins from the osTicket-plugins repository let agents sign in with your directory accounts, so access removal follows the same joiner and leaver process as other internal systems. Two-factor authentication and the audit plugin add controls you will need to test and document, including which agent actions are logged, where those logs are stored and how long they are kept. Confirm that your audit and log retention settings match your own policy before go-live, because the platform will only record what you configure.
DeployOpen can plan the hosting design, configure directory integration, set up backup and access controls and assemble the evidence an assessor will ask for. It does not issue audit reports, attestations or certifications. Those come from an independent auditor or certification body that you select and that assesses your environment. Ask your auditor early which controls and evidence they expect for your sector, then agree that list in writing as part of the fixed scope before implementation begins.
Freshdesk plans versus osTicket editions
The free osTicket download is the open-source GPL-2.0 release that you clone, deploy and run on your own servers. There is no license fee, but you own the hosting, the upgrades and every fix. Support comes only from the community, so answers depend on forum and repository activity rather than a contracted response.
- Web server: Apache or Microsoft IIS must serve the application.
- PHP: PHP 8.2 to 8.4 is supported, with 8.4 recommended, and the mysqli extension must be enabled.
- Database: MySQL 5.5 or greater is required.
- Deployment: The README describes deploying from a clone of the public repository with
php manage.php deployand pulling later updates withgit pullbefore redeploying. - Support: Community support only, so budget internal or partner time for production incidents.
Before committing, confirm that your PHP and MySQL versions match the supported range, and decide who will own patching and backups for the attachment files, database and codebase.
osTicket's cloud-hosted edition is run by osTicket rather than by your team. According to the osTicket editions page, it starts at $12 per agent per month. That figure is the starting price only, so the total depends on the number of agents and any options that the editions page or a quote adds.
- Starting price: $12 per agent per month, per the osTicket editions page.
- Who operates it: osTicket hosts the platform, so your team does not run PHP, MySQL or the web server.
- Recurring cost: The fee repeats monthly for each agent, so it grows as the team grows.
- Data location: Confirm where hosting occurs and what the provider does with ticket data and attachments.
- Customization: Confirm which plugins and authentication options are available in the hosted edition before assuming the self-hosted plugin set applies.
Ask the vendor for a written quote that states the agent count, included features, support terms and data handling.
The virtual appliance edition is a packaged osTicket image that you run in your own virtualization environment. The editions page does not publish a fixed price for it. Pricing is custom, so the cost depends on what the vendor includes in your quote.
- Pricing: Custom, set by quote rather than a published list price.
- Packaging: A pre-built image reduces the setup work compared with the free download.
- Operations: Your team still runs the hypervisor, backups and network controls around the appliance.
- Support scope: Confirm whether support, updates and upgrade paths are included and for how long.
- Lock-in: Ask how the image is updated and whether you can export your data and move to the free download later.
Request a quote that lists the license term, included support level, update process and any per-agent or per-instance charges.
Freshdesk is a hosted SaaS help desk sold on subscription plans, and Freshdesk operates the platform for you. This page's sources do not list Freshdesk plan names or prices, so you should check the current plan sheet and request a quote before comparing costs.
- Plan names and prices: Not included in this page's sources. Check the current Freshdesk pricing page.
- Operations: Freshdesk runs hosting, upgrades and availability, so your team manages configuration rather than servers.
- Data export: Account administrators can export tickets, solutions, forums and customers as XML from Admin, Account, Account Details, Export data, on all plans.
- Feature comparison: Map the plan features your agents use, such as automations, SLAs and channels, against the osTicket plugin set.
- Contract terms: Confirm billing cadence, agent-count rules and any minimum commitment in writing.
Ask Freshdesk for a quote for your exact agent count and channels, and compare the total annual figure with the osTicket options above.
What drives the cost of running osTicket yourself
The osTicket software carries no license fee, so the cost of running it comes from the people and infrastructure around it. Someone is paid to host the application on Apache or Microsoft IIS, keep PHP 8.2 to 8.4 with the mysqli extension and MySQL 5.5 or greater running, back up the database and attachments, and configure the core plugins from the osTicket-plugins repository for LDAP, OAuth2, two-factor authentication, audit and S3 attachment storage. That labor may be your own staff, an internal platform team or an external consultant or support contract. Confirm with your team who owns each of those tasks and how many hours of that time already exist in someone's role, because that unpaid internal time is the largest cost line most teams underestimate. Split the work into one-time and recurring items. One-time work covers the initial deployment, plugin setup, identity and channel integration, data migration from your current helpdesk and hardening against your own baseline. Recurring work covers PHP and MySQL patching, applying osTicket upgrades (the README asks you to back up attachments, the database and the codebase first), reviewing backup restores, monitoring mail and web form intake and handling agent account changes. Costs rise with the number of agents, the number of email, phone and web form channels that feed one queue, S3 attachment storage that needs its own access controls and lifecycle rules, and any evidence you must produce for a compliance assessment. Costs fall when one team owns a standard build, when the plugin set is kept small and when restore tests are scheduled rather than improvised. When you request a written quote from DeployOpen, ask for the scope split into those components: the deployment and hardening work, each plugin configured and tested, the migration approach and its data checks, the backup and restore procedure with a documented restore test, the upgrade runbook and the support model that applies after go-live. A fixed-scope quote should name what is excluded, such as hosting capacity, licenses for any external identity provider or S3 service and compliance evidence that an independent auditor would need to review. DeployOpen does not publish a price list, so compare quotes on the stated scope rather than on headline totals.
How a move from Freshdesk to osTicket runs
The sequence takes a Freshdesk account from a complete XML export to an osTicket instance that handles email, phone and web form intake on infrastructure you run. Each step ends with a check that the next one can rely on.
Export the Freshdesk account data
A Freshdesk account administrator opens Admin, Account, Account Details, Export data and requests the export of tickets, solutions, forums and customers as XML. The export is available on every Freshdesk plan, so the account tier does not block this step. Store the files in a restricted location, because they contain customer personal data. Done means the team has a complete copy of the XML files, checked against the ticket counts shown in Freshdesk, and a named owner for the archive.
Choose the osTicket release line
The engineering lead selects a release line from the osTicket releases page, which currently shows the 1.18 and 1.17 lines receiving updates together, and confirms the target server stack. The osTicket 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. Confirm each version against the README before ordering or building hosts. Done means a written platform decision that names the release, PHP version and MySQL version.
Deploy osTicket from the public repository
The platform team clones the osTicket repository on a server that meets the requirements and runs php manage.php deploy, as described in the README. Later updates come from git pull followed by a redeploy, so record the exact commit or tag used. Put the instance behind your standard TLS, backup and access controls before loading any customer data. Done means a fresh instance answers over HTTPS, the admin login works, and the deployment steps are written into the runbook.
Map Freshdesk structure to osTicket
Support leads map Freshdesk agents to osTicket staff accounts, Freshdesk groups to departments, and Freshdesk mailboxes, web forms and phone intake to osTicket email and intake sources. This is a design exercise, not a copy job, and it decides how tickets are routed and who sees them. Record which Freshdesk automations and SLAs must be recreated by hand. Done means a signed-off mapping sheet that every intake channel and team has reviewed.
Convert and load the exported data
The Freshdesk XML needs conversion work before another helpdesk can load it, because the files do not match osTicket's database schema. The sources supplied for this page do not name a Freshdesk importer for osTicket, so the team must confirm the import method with the osTicket project or a qualified implementer before committing to one. Test the chosen method on a copy of the instance first, then compare ticket, customer and attachment counts. Done means a test load reconciles with the Freshdesk export and the reconciliation report is filed.
Configure plugins and storage
The administrator installs the core plugins that match your identity and audit needs from the osTicket-plugins repository, following the plugins documentation. Options include LDAP, OAuth2, two-factor authentication, password policy, audit and attachment storage on the filesystem or S3. Confirm each plugin's compatibility with your chosen release before enabling it, and remember that the README advises backing up attachments, the database and the codebase before any upgrade. Done means each plugin is enabled, tested with a test account, and listed in the configuration record.
Test intake and cut over
The support team sends test messages through email, places a test phone intake and submits a test web form, then confirms each ticket lands in the correct department and is assigned as mapped. Run a final delta export from Freshdesk for anything created during testing, and agree a cutover window with the business owners. Switch the public mailboxes, forms and phone routing to osTicket, and keep Freshdesk read-only for reference. Done means every intake channel has produced a correctly routed ticket in production and the cutover record is signed.
What buyers ask before moving from Freshdesk to osTicket
How does the cost of running osTicket compare with a Freshdesk subscription?
osTicket's free edition has no license fee, so the cost sits in the components you pay for: the server or virtual machine, backups, storage, mail handling, and the staff time to install, configure, patch and upgrade it. Freshdesk bills per agent under its plans, and that subscription covers hosting, platform updates and vendor support. The comparison depends on agent count, how many hours your admins spend on the platform each month, and whether you buy outside help. Ask any implementation partner for a quote built from a written scope that lists each component separately, and compare it against your current Freshdesk invoice for the same number of agents and channels.
How long does a move from Freshdesk to osTicket take?
The time depends on the size of the ticket history, the number of mailboxes and phone or web form channels to rebuild, the custom fields and departments you need to recreate, and how much testing your team requires before cutover. The supplied information does not give a duration for this move, so do not plan from a generic figure. Ask for a fixed-scope timeline in writing that lists the phases, the deliverables for each phase, and the decisions your team must make before work starts. Confirm how the export from Freshdesk will be converted and loaded, since that step often drives the schedule.
What does the team need to run osTicket after the move?
You need at least one named administrator who owns the platform, a Linux server or virtual machine that meets the PHP and web server requirements, a MySQL database that someone can back up and restore, and access to the mailboxes that feed the system. The osTicket README requires Apache or Microsoft IIS, PHP 8.2 to 8.4 with the mysqli extension, and MySQL 5.5 or greater, and it recommends PHP 8.4. Make sure your team also covers TLS certificates, operating system patching, and monitoring of mail polling. Assign these duties to people by name before the move so they do not fall to whoever is available when something breaks.
Can our own staff migrate and run osTicket without outside help?
Yes, for a small deployment where someone already has PHP, Apache or IIS, and MySQL skills, and where the ticket history and channel setup are simple. Clone the public repository, run the deploy command from the README, then configure mail, departments, and the plugins you need. The harder parts are data conversion from Freshdesk's XML export, rebuilding automations and SLA rules, and validating that email, phone and web form tickets arrive correctly. Bring in outside help when the team lacks those skills, when you need authentication through LDAP or OAuth2 wired into your directory, when you must document controls for an assessment, or when staff cannot take the cutover window without support.
How do osTicket upgrades work, and what should we back up first?
The README states that upgrades are supported from 1.6-rc1 and later, so you should confirm your current version before you plan the path forward. Before any upgrade, the README recommends backing up the attachment files, the database, and the codebase. Keep those three backups together and test restoring them on a separate host before you change production. Upgrades follow the same deployment flow as the initial install: pull the later updates with git pull, then redeploy with the manage.php deploy command. Schedule upgrades after reading the release notes for the line you run, and rehearse them in a staging copy.
What does community-only support mean for response times and risk?
Community-only support means that the free edition has no vendor support contract with a response commitment. You get the public community channels, documentation, and the open-source code, so fixes depend on community activity and on your own or a partner's ability to diagnose problems. Freshdesk's paid plans include vendor support, so the risk profile changes. If a ticket outage affects customers, you will need an internal on-call path or a support retainer with a provider that you have agreed on in writing. Ask any provider to state its response targets, escalation path, and what is excluded, and do not assume a response time that has not been written into a contract.
Which osTicket plugins cover LDAP, two-factor authentication and audit needs?
The osTicket-plugins repository holds core plugins for osTicket 1.8 and later, including LDAP, CAS, OAuth2 and passthrough authentication, two-factor authentication, password policy, audit, and attachment storage on the filesystem or S3. Check each plugin against your directory, identity provider, and retention requirements before you commit to the design. Confirm how each one behaves with your osTicket version, and test login, lockout, and audit log output in staging. Plugin installation and configuration are part of the scope to agree in writing, along with any gaps that need custom development.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Freshdesk vs osTicket decision, we start with the written requirements your team needs to meet, then build and document only what the chosen platform must do.
How we scope
- We confirm which channels you need from email, phone and web forms, and which agents, queues and reports depend on them.
- We map your authentication needs, such as LDAP, OAuth2 or two-factor authentication, to the osTicket plugins you would run.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We install osTicket on the Apache or IIS, PHP and MySQL versions your environment supports, inside your own infrastructure.
- We configure authentication, attachment storage and audit plugins, then test each one against your real ticket flows.
- We document the upgrade path, including backups of attachment files, the database and the codebase before each release.
How we hand over
- You receive configuration records, runbooks and the deployment steps, so your administrators can repeat the work.
- We walk your staff through queue setup, agent roles and the day-to-day administration tasks in osTicket.
- We agree a written list of what you must confirm yourselves, such as mail server settings and retention rules.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Because the free edition has community support only, a retainer can cover patching, plugin updates and incident help.
- Quotes follow from the written scope, so you can compare the one-time build cost with any recurring retainer.
