description: "OTOBO Hosting made easy: System requirements, Docker installation, hosting provider comparison, and tips for security, performance, and troubleshooting."

Hosting the OTOBO Ticket System – A Guide for Beginners and Advanced Users

Introduction

OTOBO is a versatile, open-source ticketing system (a fork of the ((OTRS)) Community Edition) for helpdesks and service management. Companies can use it to efficiently manage customer inquiries and internal tasks. Unlike cloud solutions, OTOBO is free of charge, but must be operated on its own server – which is why hosting plays a crucial role. Stable and secure hosting ensures that the ticketing system is always available, runs performantly, and sensitive data remains protected. This article provides a comprehensive overview of OTOBO Hosting – from the prerequisites and installation (via Docker) to provider comparisons and best practices.

Hardware and Operating System Requirements for OTOBO (Docker Installation)

Before you begin the installation, you should ensure that your hardware and operating system meet the requirements of OTOBO. Basically, OTOBO only runs on Linux/Unix systems; For the Docker-based installation, the OTOBO project recommends a current Linux (e.g., Ubuntu 20.04 LTS or newer) as the host system.

Minimum Hardware (Test System): For small test installations, a server with approximately 2 CPU cores, 4 GB RAM, and 15–20 GB storage is sufficient. This allows for processing fewer tickets per day and smaller attachments.

Recommended Hardware (Production): For production use with a higher ticket volume, the machine should be more powerful – e.g., 4 vCPUs, 8 GB RAM (preferably 16 GB), and 40+ GB disk space. Sufficient RAM, in particular, ensures that the database, web server, and services like Elasticsearch run smoothly. The exact sizing depends on usage (number of tickets, users, attachments); if in doubt, plan for a little extra capacity.

Tip

Whenever possible, use SSD-based storage for fast database access and backups. Also, ensure that Docker is installed on the host (at least Docker 19.03+ and Docker Compose 1.25+ have been tested). For more details, see the OTOBO Installation Guide (System Requirements section).

Comparison of Hosting Providers for OTOBO

The choice of hosting provider significantly influences the effort, cost, and performance of your OTOBO system. Below, we compare four common options – from German data centers to global cloud providers – with their pros and cons.

Hetzner

Hetzner is a German provider known for affordable hosting with high performance. Advantages include server locations in Germany (good for data privacy) and an excellent price-performance ratio – comparable resources often cost many times more with AWS/Azure (AWS and Azure are At Least 4x–10x More Expensive Than Hetzner). Hetzner offers both Cloud Servers (flexibly scalable, billed hourly) and Dedicated Servers with full root access. For OTOBO Docker installations, Hetzner's Cloud VPS or CX/CPX servers are popular as they support Docker immediately. Advantages: Low prices, fast hardware (NVMe SSDs, AMD EPYC/Intel Xeon CPUs), easy management via a web console, data storage in German data centers. Disadvantages: No globally distributed network – data centers are primarily in DE (and Finland), making them less ideal for international users with latency requirements. Furthermore, you have to administer the system yourself (no managed support in the basic tariff). Overall, Hetzner is ideal for experienced users or companies that want to host cost-effectively in Germany.

AWS (Amazon Web Services)

AWS is a global cloud market leader and offers a vast array of services. For OTOBO hosting, you can use Amazon EC2 instances (virtual Linux servers) or connect to managed databases via RDS. Advantages: Highest flexibility and scalability – you can scale server performance up or down as needed, use load balancing and auto-scaling, and choose from many regions worldwide. Additionally, there are numerous additional services (backup, monitoring, CDN) that can be integrated into the OTOBO setup. Disadvantages: Cost – AWS is significantly more expensive than Hetzner for the same hardware performance (AWS and Azure are At Least 4x–10x More Expensive Than Hetzner), especially when resources are booked permanently. The pricing structure is complex (e.g., costs for traffic, storage, backups are extra), which can be confusing for beginners. AWS also requires expertise, as the multitude of options makes configuration more complex. AWS is particularly worthwhile for large deployments or when global availability and managed services are important. For a medium-sized company operating OTOBO individually, the additional AWS costs are often not justified.

Microsoft Azure

Azure (from Microsoft) is – similar to AWS – a global cloud platform with extensive services. Azure offers Linux VMs for Docker as well as container services (e.g., Azure Container Instances or AKS, if you want to use Kubernetes). Advantages: Good integration into Microsoft ecosystems – ideal if you already use Microsoft services (Azure AD for Single Sign-On, Office 365 integration, etc.). Azure has data centers worldwide, including in Europe, and offers reliable infrastructure with extensive compliance certifications (important for enterprise customers). Disadvantages: Cost and complexity are comparable to AWS – Azure is also among the high-priced options, especially when many resources or Windows servers are used. Management via the Azure portal requires familiarization; for pure Linux/Docker hosts, it is sometimes overkill. If primarily a single OTOBO system is to be operated, Azure – like AWS – can seem oversized. However, it is a strong option for companies that rely on Microsoft anyway or want to integrate additional Azure services (AI, BI, etc.).

IONOS (1&1 IONOS)

IONOS is a German hosting provider that offers both classic web hosting packages and cloud servers and managed services. For hosting an OTOBO ticket system, IONOS recommends a Cloud Server or VPS with Linux, on which you install Docker. Advantages: Data location Germany (ideal for GDPR) and German-speaking support. IONOS focuses on user-friendliness – the dashboard is beginner-friendly, and there are one-click installers for some applications (though not as a ready-made image for OTRS/OTOBO, as far as is known today). In terms of price, the cloud servers are in the mid-range, often cheaper than AWS/Azure, but tend to be slightly more expensive than Hetzner for the same performance. Disadvantages: Slightly fewer community resources and tutorials online compared to AWS/Hetzner. Furthermore, the really cheap tariffs (shared hosting) are not suitable for OTOBO; you need at least a dedicated VM tariff with Docker support. Overall, IONOS is a good choice if you want a German provider with support and are satisfied with a more conventional hosting environment.

Managed OTOBO Hosting

If you want to avoid the technical effort, there are also Managed Hosting offers for OTOBO. A service provider takes care of installation, updates, monitoring, and backups, while you simply use the ticketing system. Some specialized companies offer OTOBO Managed Hosting.

Tip

Regardless of whether you operate it yourself or use managed services – ensure that the hosting location matches your compliance requirements. Many German companies, for example, prefer Hetzner or IONOS to keep their data in Germany.

Installing OTOBO with Docker

• OTOBO Installation;
• Advanced Installation

Best Practices for Secure and Performant OTOBO Hosting

Once you have successfully installed OTOBO, you should follow some best practices to ensure operation is as secure, fast, and reliable as possible. Here are the most important recommendations for performance, security, and backups:

Performance Tips

• Utilize Caching and Search Index: OTOBO already includes Redis as a cache and Elasticsearch for full-text search via Docker. Ensure these containers are enabled (otobo_redis_1 and otobo_elastic_1 run by default) – they significantly improve performance (faster page loads, faster search results). Without Elasticsearch, the database has to search through all ticket text, which is slower.

• Allocate Sufficient Resources: Monitor your server's CPU and memory usage. With many simultaneous agents or tickets, 4 GB of RAM can become tight – scale up to 8 or 16 GB before the system starts swapping. The same applies to the CPU: more cores help with many parallel requests. If necessary, use dedicated database servers if the load is very high (in Docker, you can also move the DB to a separate host).

• Manage Ticket Volume: Do not leave tens of thousands of open tickets in the active queue. Archive or close old tickets regularly. OTOBO has functions for archiving tickets, which unloads the ticket lists and search indexes. Furthermore, with a very large number of tickets, switching to the static ticket index may be advisable (Performance Tuning — OTOBO Installation Guide 10.1 documentation) (Performance Tuning — OTOBO Installation Guide 10.1 documentation) – however, this is usually only necessary with >80,000 open tickets.

• Optimize File Storage: By default, OTOBO stores attachments as files on the volume. This is more performant than storing them in the database. Ensure that the volume (otobo_opt_otobo in Docker) is on fast storage. If necessary, you can place the attachments directory on a separate partition. Keep sufficient free disk space available – with many and large attachments, the disk could fill up and stop the system.

• Set Up Monitoring: Monitor your system (CPU, RAM, DB performance, Docker container health). Early warnings of high load or errors allow for proactive action. Docker provides simple live data per container with docker stats. For long-term monitoring, tools like Prometheus/Grafana or CloudWatch (with AWS) can be used.

Security Measures

• Apply Updates and Patches: Keep OTOBO itself, as well as the operating system and Docker, up to date. Security updates from the OTOBO project should be installed promptly (with Docker, simply pull a new image and restart the containers). Also, regularly update the Perl modules and libraries used if you have a manual system.

• Use HTTPS: Protect the web interface with SSL/TLS. In the Docker environment, you can either use the included Nginx proxy (see .env option for HTTPS) or place an external proxy/web server in front. Free certificates from Let’s Encrypt can be integrated automatically. This ensures that login credentials and sensitive ticket content are transmitted encrypted.

• Strong Passwords & 2FA: Enforce complex passwords for all agent accounts. Change the default admin password immediately after installation. OTOBO offers two-factor authentication (OTP) for agents (OTOBO/Znuny und OTRS ((Community Edition)) Einführung - Get Started | OTOBO) – consider enabling it to further secure access.

• Secure Access: If possible, restrict external access to the OTOBO interface. For example, VPN or a fixed IP whitelist could be used for the agent interface if only employees need internal access. At a minimum, the admin dashboard URL should not be exposed directly to the internet. Also, use firewalls ( UFW, iptables, or cloud security groups) to open only the necessary ports (HTTP/HTTPS, SSH). The database and Redis/Elasticsearch ports should not be publicly accessible.

• Server Hardening: On Linux servers, disable unused services and install only necessary software. Configure regular security scans. If you use RHEL/CentOS, note that SELinux can restrict Docker containers – either configure the required permissions or disable SELinux, otherwise OTOBO might not function correctly.

Backups and Maintenance

• Regular Backups: Perform daily backups of the OTOBO database and important file directories. In Docker environments, you can create a MySQL dump using docker exec and back up the files from the volume. Automate this using a cron job. Store backups on external systems or storage (e.g., cloud storage) so they are available even in case of a server failure.

• Test Backup Strategy: Regularly verify your backups by performing test restores. Nothing is worse than a backup that turns out to be unusable in an emergency. OTOBO provides official instructions for backup and restore; follow them and document the process internally.

• Document Configuration: Record which customizations you have made to the OTOBO configuration (e.g., in SysConfig, additional packages/addons, cron jobs). This helps to quickly isolate problems in case of errors or during updates. Export important settings and keep versions of Docker Compose files or .env files under version control.

• Schedule Updates: Plan maintenance windows for OTOBO upgrades. With a Docker-based setup, an update might involve bringing up new containers. Perform a backup beforehand, check the release notes, and ideally test the upgrade in a staging environment. This keeps your system secure and compatible in the long term.

Common Problems and Solutions in OTOBO Hosting

Despite good preparation, problems can occur during operation. Here are some common problems with OTOBO hosting (especially in Docker setups) and tips for troubleshooting:

• Web Interface Not Reachable: If the OTOBO web interface does not load, first check if all Docker containers are running: docker-compose ps should show "Up (healthy)" for web, db, etc. Ensure that the port (default 80 or 5000) is open in the firewall. When accessing via a domain, check the DNS settings and the .env configuration (FQDN). Solution: Run docker-compose logs web to get hints about errors. A docker-compose restart of the affected services often helps. For Connection refused errors, ensure no other service is blocking the port.

• Performance Issues: The system is sluggish or hangs? Check if the server is possibly **short on memory ** (swap usage) or if the CPU is overloaded. Often, insufficient RAM is the cause – MySQL then struggles. Solution: Allocate more RAM/CPU or scale up to a larger server. Also, check if Redis and Elasticsearch are running correctly – without cache and index, OTOBO becomes significantly slower. A look into the OTOBO system log ( Admin area or file otobo.log) can show if, for example, queries are taking too long. If necessary, archive old tickets to keep the active data volume small.

• Email Sending or Retrieval Fails: OTOBO retrieves emails from mailboxes and sends emails via SMTP. If this does not work, it is often due to incorrect settings or connection problems. Solution: Open SysConfig in OTOBO and check the mail account settings (server, port, user, password). For Office 365/Exchange, modern authentication methods or app passwords may need to be used. Monitor the OTOBO log for error messages during mail retrieval (keyword IMAP/POP errors) or sending (SMTP errors). A typical error is, for example, "Authentication failed" – then the credentials are not correct. For SSL/TLS problems ( certificate errors), ensure that the container trusts the mail server (install CA certificate if necessary). Server firewall settings can also be a problem – allow outgoing connections on port 993 (IMAPS) and 587/465 (SMTPS) in the server firewall.

• Docker Container Problems (Crashes, Permissions): If containers stop unexpectedly or restart (crash loop), check docker-compose logs for error messages. A common stumbling block is file permissions on the mounted volumes. The OTOBO container runs as user otobo (UID 1000) – ensure that the directories on the host grant write permissions to this UID. Error messages like "Permission denied" in the logs are an indication of this. Solution: If in doubt, run the script otobo.SetPermissions.pl (in the container under /opt/otobo/bin/) to set the permissions correctly. Or adjust the owners on the host (chown -R 1000:1000 ./otobo-docker/opt_otobo). Another problem can be missing environment variables – if docker-compose up aborts immediately, check if all required variables in the .env are set. Example: If the MYSQL_ROOT_PASSWORD is missing, the DB will not start. Consult the documentation for required .env entries.

• Backup/Restore Errors: Errors can occur when restoring a backup, e.g., incompatible database version or missing files. Solution: Ensure that the same OTOBO version is used that generated the backup. First, import the database (e.g., via mysql < backup.sql in the DB container) and then restore the file attachments and configuration files. Then, set the permissions correctly. After restoring, check the OTOBO logs and the system configuration. For major version jumps, run the migration script (otobo.Console.pl Maint::Database::Migration), if necessary. If in doubt, you can find more help in the OTOBO Documentation under Backup and Restore.

Conclusion

With careful planning and by following these tips, both beginners and advanced users can achieve successful OTOBO Hosting. From choosing the right infrastructure and optimal installation to security and performance – with the guide above, you will get the most out of your OTOBO ticketing system. If you have questions or complex environments, do not hesitate to consult the extensive OTOBO Documentation and the community, or seek advice from an experienced OTOBO service provider. Good luck with your OTOBO server!