Which osTicket model fits your support team
The cloud edition fits a team that wants agents answering tickets next week without running a PHP and MySQL stack. If your support group is small, has no infrastructure staff, and your data policy allows ticket content and attachments to be held by a hosting provider in a location you have approved, the hosted edition removes the install, patching and backup work from your queue. The published starting price is $12 per agent per month, so the recurring cost scales with headcount. Confirm with osTicket what that price includes, which storage regions are available, how attachments are retained and what happens to your data on exit before you sign.
Self-hosting fits when the data must stay inside your own cloud account, data center or air-gapped network, or when you need custom code or deep identity integration. The free download is GPL2 and gives you full control of the codebase, the database and the plugin set. The core plugins from the osTicket-plugins repository cover LDAP, CAS, OAuth2, two-factor authentication, password policy, audit and S3 attachment storage, which may cover your identity requirements without custom work. The trade-off is that support is community-only, so your team owns upgrades, backups and incident response. The virtual appliance is a middle path if you want a packaged image inside your environment, but its pricing is custom, so request a written quote before comparing it with either option.
Decide on the controls you must own, then price the work that goes with them. For self-hosting, list who will apply releases such as the 1.18.4 and 1.17.8 builds published June 17, 2026, who takes the backups the README calls for (attachments, database and codebase) and who tests a restore. For cloud, list the evidence you will need from the provider for your own assessments and the exit terms for your data. Ask both paths for a written scope that covers identity integration, attachment storage and upgrade support, so the comparison reflects the same work on each side.
How osTicket Cloud and self-hosted osTicket compare on each factor
This table sets the hosted osTicket edition beside the free download you run yourself, factor by factor. Read each row as a question to answer for your own team, and treat any cell marked as a vendor question as open until the vendor confirms it in writing.
| Factor | osTicket Cloud | Self-hosted osTicket |
|---|---|---|
| License | Cloud service sold by osTicket under its editions terms, so confirm what the subscription grants beyond the software itself | Free download released under GPL2, per the osTicket README |
| Published pricing | Starts at $12 per agent per month, per the osTicket editions page | No license fee for the download; your costs are hosting, staff time and any paid services you buy |
| Virtual appliance option | Not applicable | Virtual appliance edition with custom pricing, per the osTicket editions page; ask for the quote scope in writing |
| Support | Confirm the support tiers and response commitments included in the cloud plan with the vendor | Community support only for the free download, so plan internal or partner support for production incidents |
| Core plugin set | Ask the vendor which LDAP, CAS, OAuth2, two-factor, password policy, audit and S3 or filesystem attachment options are offered | Available from the osticket-plugins repository for osTicket 1.8 and later, covering LDAP, CAS, OAuth2, passthrough, two-factor, password policy, audit and attachment storage |
| PHP and database requirements | Confirm the PHP and MySQL versions the vendor runs and whether you can choose them | Apache or Microsoft IIS, PHP 8.2 to 8.4 (8.4 recommended) with mysqli, and MySQL 5.5 or greater, per the osTicket README |
| Upgrade method | Vendor-managed; ask how release timing, testing and rollback are handled for your tenant | Back up attachments, database and codebase, then update with git pull and redeploy, per the osTicket README |
| Backups and availability | Ask what backup frequency, restore testing and availability targets the plan includes | Your responsibility: schedule, store and test backups of attachments, database and code |
Who controls the data and what compliance means in each model
Hosted and self-hosted osTicket split responsibility for data, access and evidence differently. The cards below cover the questions a compliance owner should settle before choosing a model, and the points where the vendor's own assurance documents, not assumptions, must answer them.
Data location and residency
With osTicket Cloud, ticket content, attachments and logs sit in the vendor's hosting environment, so the cloud data location must be confirmed in writing before contracting. With self-hosting, you choose the cloud account, data center or air-gapped network, and the residency question becomes an infrastructure decision. Ask the vendor which regions host the service, where backups and support access originate, and whether any sub-processors receive ticket content.
Administrative access and key management
In the hosted model, the vendor's operators hold the platform administration path, and you depend on their access controls and logging. Self-hosting puts the config.php secrets, database credentials and encryption-related settings under your own key management. Document who can reach the database, the web root and the mail connectors, and confirm how the hosted provider handles privileged access and key rotation.
Audit evidence
Compliance assessments need evidence such as access reviews, change records and backup restore tests, and the evidence has to come from the system that runs osTicket. Self-hosting means you produce this evidence yourself, using the logs and records your installation keeps, and the audit plugin in the core plugin set can help if you enable it. For a hosted service, request the vendor's own assurance documents and confirm which evidence it will share. DeployOpen prepares systems and evidence for assessments, but independent auditors and certification bodies issue any audit report or certification.
Identity integration
Core plugins cover LDAP, CAS, OAuth2 and passthrough authentication, along with two-factor authentication and password policy. In a self-hosted install, you wire these into your own directory and enforce them on the server. In the hosted edition, confirm which identity integrations the vendor supports, whether they can reach an internal directory, and who manages the connection. Record each agent's authentication path as part of the access evidence.
Incident responsibility
When a ticket system is breached or a backup fails, the response owner differs by model. A hosted contract should state the vendor's notification commitments, response windows and cooperation duties, and you should compare those against your own regulatory deadlines. Self-hosting makes your team responsible for patching, detection and recovery, and the free download comes with community support only. Agree the escalation path before the first incident.
Vendor dependency and exit
A hosted subscription ties your ticket history, configuration and integrations to one provider's roadmap, pricing and continuity. Self-hosting on the GPL2 codebase keeps the software replaceable, but you then own the upgrade and backup routine, documented in the README as backing up attachments, the database and the codebase before each upgrade. Ask the hosted vendor for a data export format, a deletion commitment at exit and a timeline for returning records.
What work stays with your team when you self-host osTicket
When you run the free osTicket download yourself, the software is free but the operating work is not. Your team keeps the web tier and runtime current: Apache or Microsoft IIS, PHP between 8.2 and 8.4 (8.4 is the recommended version in the README), the mysqli extension, and MySQL 5.5 or greater. Each of those components has its own security patch cycle, and you own the change window, the rollback plan and the testing that goes with it. Ask whether anyone on your team already owns patching for this exact stack, because osTicket will not do it for you.
Backups are the step most teams underestimate. The README recommends backing up attachment files, the database and the codebase before every upgrade, and upgrades are supported from 1.6-rc1 and later. Treat those three artifacts as one restore set and test a restore on a separate host, not just a dump file. Plugin compatibility is a second recurring check: the osTicket-plugins repository ships LDAP, CAS, OAuth2, two-factor, password policy, audit and S3 or filesystem attachment storage plugins, and each one must be verified against the osTicket version you deploy. Confirm the plugin list you depend on in the osTicket plugins documentation before you schedule an upgrade.
Support is the last piece to plan. The free download comes with community support only, so a production fault in a self-hosted install has no contractual response path unless you buy one from an outside provider. Track release lines deliberately: osTicket v1.18.4 and v1.17.8 were both published on June 17, 2026, so the 1.17 and 1.18 branches receive fixes in parallel and you must know which line you run. Monitor web and database health, disk use for attachments and the mail intake path, and set an owner for reviewing each new release. Ask any implementation partner to state in writing which of these tasks are included in the scope and which stay with your staff.
What your team runs in each hosting model
With the free open-source download, your team owns the whole stack: the web server, PHP, the MySQL database, the osTicket codebase and every plugin you add. osTicket's README describes deploying from a clone of the public repository with php manage.php deploy and pulling later updates with git pull before redeploying. The project offers community support only, so vendor help on a defect is not part of this model.
- Patching: Your team applies each osTicket release, including the 1.18.4 and 1.17.8 releases published on June 17, 2026, and follows OS and web server patches.
- Backups and restore tests: Your team backs up the database, attachment files and codebase, which the README recommends before any upgrade. Restore tests are yours to schedule and record.
- PHP and database upgrades: Your team moves the stack within the supported range of PHP 8.2 to 8.4 (8.4 recommended) and MySQL 5.5 or greater, and tests plugins after each change.
- End-user support: Your team runs the help desk and handles access, email routing and any authentication plugins such as LDAP or CAS.
- Confirm with the community: Check which community channels and documentation you will rely on for security advisories and upgrade problems, and who on your side receives them.
The virtual appliance edition is a packaged osTicket image that you run inside your own virtualization platform. Pricing is custom, so the vendor quote defines what the appliance includes. Your infrastructure team still operates the hypervisor, network segments, storage and access controls, and the appliance inherits whatever hosting standards your environment enforces.
- Patching: Confirm with the vendor who ships appliance updates, how they are delivered, and whether your team or the vendor applies them.
- Backups and restore tests: Confirm whether the appliance includes backup tooling, what it captures (database, attachments, configuration) and whether your hypervisor snapshots are sufficient. Restore procedures must be tested in your own environment.
- PHP and database upgrades: Confirm whether the vendor maintains the PHP and database versions inside the image and how long each image line is supported.
- End-user support: Your team typically still runs the help desk process, while the support terms of the appliance edition determine what the vendor covers.
- Confirm in the quote: Ask for the support level, the update cadence, the backup and restore procedure in writing, and what happens to your data if you leave the appliance later.
Ask for all of these answers in writing before you compare the appliance with a self-built install.
The cloud-hosted edition moves hosting, the application stack and most operational work to the vendor. osTicket publishes a starting price of $12 per agent per month for cloud hosting, so your recurring cost scales with the number of agents. Your team keeps configuration, departments, users, workflows and the process of using the help desk.
- Patching: The vendor applies platform updates. Confirm the timing, whether you can defer a change, and how you are notified.
- Backups and restore tests: The vendor runs backups. Confirm the retention period, backup location, encryption, who can request a restore, and how long a restore takes. Do not assume a restore test has been run unless the vendor documents one.
- PHP and database upgrades: The vendor manages them. Confirm which PHP and database versions are in use and how upgrade windows are communicated.
- End-user support: Your team still answers end users, while the vendor's support terms cover the platform itself. Confirm response channels and hours.
- Data location and exit: Confirm where data is stored, whether it can be exported in full, and what the process is for leaving the service.
Get these terms in writing, because they replace the controls you would otherwise build and test yourself.
How to move between self-hosted osTicket and the cloud edition
This sequence gives you a verified inventory, a confirmed export and import path, a planned cutover and a retired source instance, so ticket history, attachments and configuration arrive intact in whichever direction you move.
Inventory tickets, attachments and configuration
Before any data moves, list what the source instance holds: ticket volume and open versus closed counts, attachment storage location, custom forms and fields, department and team structure, SLA and email settings, and every enabled plugin and authentication method. Assign an owner to each item, usually the osTicket administrator on the self-hosted side and the platform owner on the cloud side. This step is done when the inventory is written down and a reviewer has signed off that nothing material is missing. Confirm with osTicket which of these categories its export and import tools cover, because the inventory determines what you must rebuild by hand.
Confirm the vendor export and import options
Ask osTicket in writing whether the cloud edition supports importing from a self-hosted database, whether a supported export format exists for tickets, threads, attachments and custom fields, and whether attachment files travel with the records. Do not assume a path exists because the self-hosted code is open source. Request the answer for both directions, since moving from cloud back to self-hosted may use different tooling. This step is done when you hold a written answer that names each data category and the method, and you have tested that method on a copy.
Map plugins and authentication for parity
Compare each plugin in your inventory, such as LDAP, CAS, OAuth2, two-factor authentication, password policy, audit or attachment storage, against what the target edition offers. Plugin parity is not guaranteed, so record every plugin as matched, replaced, or unavailable. For authentication, document how agents and end users sign in today and how that will work after the move, including directory connections and any single sign-on requirements. This step is done when each plugin and sign-in path has a recorded outcome and an owner accepts any gaps as a business decision.
Run a test migration on a copy
Load a copy of the exported data into the target environment and check it against the inventory. Verify ticket counts, thread order, assignment history, custom field values, attachment links and agent permissions for a sample of tickets from each department. Note any loss, truncation or mismatched timestamps. This step is done when the test run produces a written defect list and the owner has either fixed each item or accepted it in writing, so the production run has no unknown behavior.
Plan the cutover window and routing changes
Agree a cutover window with the people who depend on the helpdesk, and set a freeze on new ticket creation during the final export. Prepare the DNS changes for the web address and the email routing changes for inbound support mailboxes, including the mail forwarding or connector settings that deliver new messages to the new instance. Write the rollback path, which keeps the source instance reachable until the new system is accepted. Lengths of the window depend on your data volume and the vendor's guidance, so confirm them rather than estimating. This step is done when the runbook names each change, its owner and the rollback trigger.
Execute cutover and verify live traffic
Freeze the source, run the final export and import, switch DNS and email routing, then send test messages through each inbound channel: email, web form and any phone-to-ticket process. Check that new tickets land in the correct queues and that agents can sign in with the authentication path you mapped. Confirm that outbound notifications come from the expected sender. This step is done when test tickets from every channel appear on the new instance, outbound mail arrives, and the owner records the cutover as complete.
Validate ticket history and attachments
After traffic has run for a period you agree in advance, sample historical tickets and confirm that thread history, timestamps, attachments and custom field values match the source. Check that attachments open and that file storage paths resolve correctly. Compare totals against the inventory from the first step. This step is done when the validation checklist is signed by the business owner and any residual differences are documented with an agreed resolution.
Decommission the old instance
Once validation is accepted, retire the source. Take a final backup of the database, attachment files and codebase, store it under your retention policy, then disable inbound mail routing to the old instance, revoke its service accounts and API keys, and remove or archive its web server configuration. Keep the backup available for the retention period your records policy requires. This step is done when the old instance no longer receives mail or traffic, its credentials are revoked, and the final backup is verified and stored.
Questions buyers ask before choosing a hosting model
What does osTicket cloud cost per agent per month?
The cloud-hosted edition starts at $12 per agent per month, according to osTicket's editions page. The agent count is the main driver, so your recurring cost scales with the number of agents you license. Before you compare it with self-hosting, ask whether the starting price includes storage, backups, plugin access, and the support tier you need. Confirm any minimum agent count, the billing term (monthly or annual), how mid-term additions are priced, and whether any setup or migration fee applies. Self-hosting removes the per-agent fee but moves hosting, patching, backups and staff time onto your budget, so compare the full annual cost rather than the license line alone.
What does the osTicket virtual appliance cost, and what should a quote include?
The virtual appliance edition is priced on request, so no published figure exists to compare against the cloud rate. Quotes typically depend on the number of agents, the support level and the term. Ask for a written statement of what the appliance includes, how updates are delivered, how long each release line stays supported, and who patches the underlying operating system. Also confirm your hypervisor requirements, host capacity, and who pays for any virtualization licenses. Ask what happens to your data and access if you stop renewing, and whether attachments and database exports are available in standard formats. Request the quote against a written scope so that two vendors can be compared on the same terms.
How long does a self-hosted osTicket install and migration take?
The supplied material does not give a duration, so treat any published timeline with caution and ask for your own plan. The main drivers are the state of your target server, whether PHP and MySQL are already in place, how many inbound channels you need (email, phone and web forms), how much attachment data must move, and which plugins you need, such as LDAP, single sign-on or two-factor authentication. Testing, a cutover window for email routing, and staff sign-off on the new workflow add further time. Ask any provider for a phased written plan with dependencies and acceptance checks. DeployOpen agrees timelines in writing before work starts, within a fixed-scope agreement.
Can our team run osTicket ourselves, and what skills does it need?
Yes, if you have people who can operate the stack. The free download requires Apache or Microsoft IIS, PHP 8.2 to 8.4 with the mysqli extension (8.4 is recommended), and MySQL 5.5 or greater, according to the osTicket README. Your team needs web server and PHP administration, database administration and tested backups, and enough Git familiarity to deploy with php manage.php deploy and pull updates. Upgrades require backing up attachments, the database and the codebase first. Someone must also own security patching, plugin compatibility and monitoring. Assign a named owner and a patching calendar before you commit, because the support model is community-based.
What does community-only support mean if our helpdesk goes down?
Community-only support means the free self-hosted download does not come with a vendor-backed support contract, according to osTicket's editions page. The supplied material does not state response times or service levels, so do not assume a fixed response. Plan for outages as an internal responsibility: keep tested backups of the database, attachments and codebase, document a rollback path, and monitor the web tier, PHP and the database. Ask osTicket which paid options exist for your deployment before you rely on any of them. If you need someone accountable for restoring service, DeployOpen offers ongoing support and upgrades through retainers, scoped in writing.
How do I move osTicket data between cloud and self-hosted?
Start by confirming with osTicket what export options exist for your cloud account, in what format, and whether attachments come with the export. The osTicket README advises backing up the attachment files, the database and the codebase before any upgrade, which shows the three data sets you must account for. Map users, agents, departments and permissions, and check whether plugin settings such as LDAP, single sign-on or two-factor authentication transfer or must be rebuilt. Run a test import on a copy, define a freeze window for new tickets, and plan the email routing change as a separate cutover step. Keep the cloud account active until you have verified a complete restore.
Can DeployOpen plan, implement and support a self-hosted osTicket under a fixed-scope agreement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Confirm during scoping that osTicket and its plugins fall within the platforms DeployOpen will support in your environment, and ask how the agreement covers backups, upgrade testing and documentation. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.
What drives the total cost of each model
The cloud edition bills per agent, and the published starting point is $12 per agent per month, according to the osTicket editions page. Multiply that by the number of agents who need a login, not the number of people on the support rota, and you have the recurring base. Ask the vendor whether supervisors, read-only users and light agents are billed the same way, whether the figure is monthly or annual, and what happens when you add agents mid-term. The virtual appliance edition is priced on request, so its total depends on the quote rather than on a published number. Self-hosting removes the subscription line but moves the cost into people and infrastructure. The free download carries community support only, so any fix you cannot resolve yourself becomes a cost you either absorb or buy from an outside firm.
Self-hosting costs fall into four groups. The first is staff time for installing, applying upgrades, testing plugins and restoring from backup. The osTicket README recommends backing up attachment files, the database and the codebase before every upgrade, so the backup routine and its storage are a recurring cost. The second is infrastructure: a web server running Apache or IIS, PHP 8.2 to 8.4, and MySQL 5.5 or later, plus hosting for attachments if you store them on disk or in S3. The third is any plugin you add from the osTicket-plugins repository, such as LDAP, CAS, OAuth2 or two-factor authentication, which carry their own testing and maintenance effort. The fourth is external implementation scope, which is one-time and fixed by the written statement of work.
Separate one-time costs (setup, migration, initial hardening, and documentation) from recurring costs (subscriptions, staff hours for upgrades, backup storage, monitoring, and any retainer). When you request a written quote, ask the vendor for the per-agent price, the billing period, the minimum term, and the cost of exporting your data if you leave. For a self-hosted quote, ask a services provider to list each deliverable, the assumptions about your environment, what is excluded, and how upgrades are handled after go-live. Confirm your own staff hours with your operations team, because no supplied figure gives a reliable estimate for your environment. A useful exercise is to compare three years of total cost for both models using your agent count, not a single year, since the recurring items compound.
How DeployOpen scopes and runs self-hosted osTicket
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For osTicket, that means taking the free open-source download and turning it into a documented, backed-up deployment in your cloud account, data center or air-gapped network, with the upgrade and support work written into scope.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the PHP, MySQL and web server stack, hosting location and attachment storage choice.
- Authentication, plugins and email or phone intake channels are listed explicitly so the cost of each is visible.
How we build
- Installation follows the osTicket README deployment path, with the PHP 8.2 to 8.4 and MySQL requirements checked first.
- Core plugins such as LDAP, CAS, OAuth2 or two-factor authentication are configured and tested against your directory.
- Backup routines covering attachment files, the database and the codebase are set up and tested before any upgrade is attempted.
How we hand over
- Runbooks cover the deployment, the git pull and redeploy update steps, and the rollback path for each upgrade.
- Administrator documentation records plugin versions, configuration keys and where each backup is stored.
- Handover sessions walk your team through agent accounts, ticket routing and the support tasks that stay with you.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainer scope should state which osTicket release lines are covered and who applies security patches.
- Ask any provider, including DeployOpen, to confirm response expectations in writing before you sign.
