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

Introduction

OTOBO is a versatile, open-source ticket system (a fork of the ((OTRS)) Community Edition) for helpdesks and service management. It allows companies to efficiently manage customer inquiries and internal tasks. Unlike cloud solutions, OTOBO is free, but it must be operated on your own server—which is why hosting plays a crucial role. Stable and secure hosting ensures that the ticket system is always available, performs well, and keeps sensitive data protected. This article provides a comprehensive overview of OTOBO hosting—from requirements 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 OTOBO's requirements. OTOBO generally only runs on Linux/Unix systems; for a Docker-based installation, the OTOBO project recommends a current Linux distribution (such as Ubuntu 20.04 LTS or newer) as the host system.

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

Recommended Hardware (Production): For production use with a higher ticket volume, the machine should be more powerful—for example, 4 vCPU, 8 GB RAM (16 GB is better), and 40+ GB of disk space. Ample memory (RAM) is particularly important to ensure that the database, web server, and services like Elasticsearch run smoothly. The exact sizing depends on usage (number of tickets, users, attachments); when in doubt, it's better to plan for some reserve capacity.

Tip

Use SSD-based storage whenever possible for fast database access and backups. Also, ensure that Docker is installed on the host (tested with at least Docker 19.03+ and Docker Compose 1.25+). You can find more details in 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 the global cloud—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 protection) and an excellent price-performance ratio— comparable resources often cost several times more at 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 because they support Docker out of the box. Advantages: Low prices, fast hardware (NVMe SSDs, AMD EPYC/Intel Xeon CPUs), simple management via a web console, data stored in German data centers. Disadvantages: Not a globally distributed network—data centers are primarily in Germany (and Finland), making it less ideal for international users with latency requirements. Additionally, you must administer the system yourself (no managed support in the basic plan). Overall, Hetzner is ideal for experienced users or companies looking to host cost-effectively in Germany.

AWS (Amazon Web Services)

AWS is a global cloud market leader and offers a huge selection 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. There are also 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 long-term. The pricing structure is complex (e.g., extra costs for traffic, storage, backups), which can be confusing for beginners. Furthermore, AWS requires expertise, as the multitude of options also makes configuration more complex. AWS is particularly worthwhile for large deployments or if you value global availability and managed services. For a medium-sized business running OTOBO as a standalone system, the extra costs of AWS 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 one of the high-priced options, especially if many resources or Windows servers are used. Management via the Azure portal requires a learning curve; for pure Linux/Docker hosts, it can sometimes be overkill. If you primarily need to run a single OTOBO system, Azure—like AWS—can seem oversized. However, it is a strong option for companies that already rely on Microsoft or want to integrate additional Azure services (AI, BI, etc.).

IONOS (1&1 IONOS)

IONOS is a German hosting provider that offers classic web hosting packages as well as cloud servers and managed services. For hosting an OTOBO ticket system, an IONOS Cloud Server or VPS with Linux, on which you can install Docker, is recommended. Advantages: Data location in Germany (ideal for GDPR) and German-speaking support. IONOS is geared towards user-friendliness—the dashboard is beginner-friendly, and there are one-click installers for some applications (though, as of today, not available as a ready-made image for OTRS/OTOBO, to our knowledge). 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: Fewer community resources and tutorials available online compared to AWS/Hetzner. Also, the really cheap plans (shared hosting) are not suitable for OTOBO; you need at least a dedicated VM plan 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. In this case, a service provider takes care of installation, updates, monitoring, and backups, while you simply use the ticket system. Some specialized companies offer OTOBO Managed Hosting.

Tip

Whether you manage it yourself or use a managed service—ensure that the hosting location meets 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 OTOBO is successfully installed, you should follow some best practices to make its operation as secure, fast, and reliable as possible. Here are the most important recommendations for performance, security, and backups:

Performance Tips

• Use Caching and Search Index: OTOBO comes with Redis for caching and Elasticsearch for full-text search via Docker. Ensure that these containers are enabled (otobo_redis_1 and otobo_elastic_1 run by default)—they significantly improve performance (faster page loads, quicker 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 concurrent 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 the load is very high, consider using dedicated database servers (in Docker, you can also offload the DB to a separate host).

• Manage Ticket Count: Don't let tens of thousands of open tickets sit in the active queue. Archive or close old tickets regularly. OTOBO has functions for archiving tickets, which reduces the load on ticket lists and search indexes. Additionally, with a very large number of tickets, switching to the static ticket index can be beneficial (Performance Tuning — OTOBO Installation Guide 10.1 documentation) (Performance Tuning — OTOBO Installation Guide 10.1 documentation)— however, this is usually only necessary for >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 DB. 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 enough free disk space available—with many 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 (on 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 container). Also, regularly update the Perl modules and libraries you use if you have a manual setup.

• Use HTTPS: Protect the web interface with SSL/TLS. In the Docker environment, you can either use the included Nginx proxy (see the .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 and OTRS ((Community Edition)) Introduction - Get Started | OTOBO)— consider activating it to further secure access.

• Secure Access: If possible, restrict external access to the OTOBO interface. For example, a VPN or a fixed IP whitelist could be used for the agent interface if only internal employees need access. At the very least, the admin dashboard URL should not be exposed to the public 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, be aware that SELinux can restrict Docker containers—either configure the necessary permissions or disable SELinux, otherwise OTOBO may not function correctly.

Backups and Maintenance

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

• Test Your Backup Strategy: Regularly check 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: Keep a record of the customizations you have made to the OTOBO configuration (e.g., in SysConfig, additional packages/addons, cronjobs). In case of an error or during updates, this helps to narrow down problems more quickly. Export important settings and keep versions of your Docker Compose files or .env under version control.

• Schedule Updates: Plan maintenance windows for OTOBO upgrades. With a Docker-based setup, an update can mean pulling up new containers. Make a backup beforehand, check the release notes, and ideally test the upgrade in a staging environment. This will keep your system secure and compatible in the long run.

Common Problems and Solutions in OTOBO Hosting

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

• Web interface not reachable: If the OTOBO web interface doesn't 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. If accessing via a domain, check the DNS settings and the .env configuration (FQDN). Solution: Run docker-compose logs web to get clues about errors. Often, a docker-compose restart of the affected services helps. For Connection refused errors, make sure no other service is blocking the port.

• Performance issues: The system is slow or hangs? Check if the server is experiencing a **memory shortage ** (swap usage) or if the CPU is overloaded. Often, insufficient RAM is the cause—MySQL will then struggle. Solution: Allocate more RAM/CPU or scale up to a larger server. Also, check if Redis and Elasticsearch are running correctly—without a cache and index, OTOBO will be significantly slower. A look at the OTOBO system log ( Admin area or the otobo.log file) 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 fetching fails: OTOBO fetches emails from mailboxes and sends emails via SMTP. If this doesn't work, it's often due to incorrect settings or connection problems. Solution: Open the SysConfig in OTOBO and check the mail account settings (server, port, user, password). With Office 365/Exchange, modern authentication methods or app passwords may need to be used. Monitor the OTOBO log for error messages during mail fetching (keyword IMAP/POP errors) or sending (SMTP errors). A typical error is, for example, "Authentication failed"—in which case the credentials are incorrect. For SSL/TLS issues ( certificate errors), ensure that the container trusts the mail server (install the CA certificate if necessary). The server's firewall settings can also be the problem—allow outgoing connections on port 993 (IMAPS) and 587/465 (SMTPS) in the server firewall.

• Docker container issues (crashes, permissions): If containers stop or restart unexpectedly (crash loop), check for error messages with docker-compose logs. A common pitfall is file permissions on the mounted volumes. The OTOBO container runs as the user otobo (UID 1000)— ensure that the directories on the host grant write permissions to this UID. An indication of this are error messages like "Permission denied" in the logs. Solution: If in doubt, run the script otobo.SetPermissions.pl (located in the container at /opt/otobo/bin/) to set the permissions correctly. Or adjust the owner 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 variables required in the .env file 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: When restoring a backup, errors can occur, e.g., an incompatible database version or missing files. Solution: Make sure you are using the same OTOBO version that created 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. Afterwards, set the permissions correctly. After the restore, 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

Through 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 ticket system. For 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