OTOBO Docker Update – Safely upgrading the version

Regularly upgrading your OTOBO installation ensures that you can immediately take advantage of new features, security patches, and bug fixes. This guide explains how to bring a Docker-based OTOBO instance to the desired release in just a few steps.

Prerequisites

• An existing OTOBO installation with Docker & Docker Compose
• SSH access to the host
• Backup of your important data (Docker volumes for /opt/otobo, database, Elasticsearch index)
• Desired target version, e.g., 11.0.10 or 10.1.8

Step 1: Update the Docker Compose configuration

1. Change to the directory of your OTOBO Docker project:

   cd /opt/otobo-docker

2. Fetch new Git tags and switch to the desired release:

   git fetch --tags
   git checkout rel-11_0_10    # Example for version 11.0.10

3. If necessary, adjust your .env, e.g.:

   OTOBO_IMAGE=rotheross/otobo:11.0.10
   OTOBO_IMAGE_ELASTICSEARCH=elasticsearch:8.8.2
   OTOBO_IMAGE_NGINX=nginx:1.23-alpine

Step 2: Pull new Docker images

docker-compose pull

Step 3: Stop and update containers

1. Stop old containers (volumes are preserved):

   docker-compose down

2. Migrate the code volume to the new version:

   docker-compose run --rm web copy_otobo_next

3. Start containers with the new software:

   docker-compose up -d

Step 4: Perform OTOBO internal update

1. Execute update tasks:

   docker-compose exec web entrypoint.sh do_update_tasks

2. Optional: Database migration script for major releases (e.g., 10.1→11.0):

   docker exec -it otobo_web_1 perl scripts/DBUpdate-to-11.0.pl

3. Check the update log:

   docker-compose exec web cat /opt/otobo/var/log/update.log

Step 5: Completion & Verification

• Check status: docker-compose ps shows whether all containers are running
• Test login: Ensure that agents and customers can log in
• Quick test: Create a ticket, send emails, and check core functions

Available OTOBO versions

Major and minor releases (selection):

• 11.0.16 (Apr 2026): Security patch – fixes XSS (CVE-2025-59490) and updates Compress::Raw::Zlib against CVE-2026-3381 in Docker; email X-headers usable as a dynamic-field source.
• 11.0.15 (Feb 2026): Fixes for multi-value fields with empty values and CKEditor formatting; database-attribute correction.
• 11.0.14 (Dec 2025): Stability and bug fixes.
• 11.0.13 (Oct 2025): Maintenance release with bug fixes.
• 11.0.12 (Sep 2025): Maintenance release with bug fixes.
• 11.0.11: OTOBO now handles log rotation for otobo.log directly, simplifying external configuration.
• 11.0.10: Offers internal improvements and updated Docker tags for stable deployments.
• 11.0.9: Closes a critical security vulnerability (CVE-2025-43926) and optimizes the ticket search module.
• 11.0.8: Strengthened password hashing algorithms and improved two-factor authentication.
• 11.0.7: Various bug fixes, including corrections for checkbox display and article links.
• 11.0.6: Important security updates against JavaScript injection and switch to CKEditor 5.
• 11.0.5: Layout optimizations for CKEditor 5 and improved translation of services.
• 11.0.4: Extended translation system and optimized Docker quickstart scripts.
• 11.0.3: Fixes database errors during ticket merge and issues with dynamic fields.
• 11.0.2: Automatic loading of ITSM repos and better upgrade detection for core packages.
• 11.0.1: New dynamic field functions and a high-contrast skin for better accessibility.
• 11.0.0-beta3: Switch to HTML::Scrubber for safer Safety() behavior.
• 11.0.0-beta2: Refined dynamic reference fields and integration of new core packages.
• 10.1.8: Security fix for XSS in AdminCustomerUser and robust HTTP header validation.
• 10.1.7: Improved calendar display and more stable Elasticsearch handling.
• 10.1.6: Closes an SQL injection in TicketSearch and optimizes appointment notifications.
• 10.1.5: Prevents code injection in ACLs and updates important JavaScript libraries.
• 10.1.4: Corrects gaps in LDAP synchronization and improves bulk updates.
• 10.1.3: Prevents server-side calls in the admin interface and closes XSS gaps.
• 10.1.2: Bug fixes in the DynamicFieldDatabase module for consistent search.
• 10.1.1: Extended customer dashboard and improved Elasticsearch self-healing.

Note: For major version jumps (e.g., 10.1 → 11.0), always perform the minor upgrade (10.1) first, then the major upgrade (11.0).

Frequently asked questions

How do you update a Docker-based OTOBO installation to a new version?

Updating a Docker-based OTOBO installation involves several key phases to ensure a smooth transition to a new major or minor release. First, you need to update your Docker Compose configuration by navigating to your OTOBO Docker project directory, fetching new Git tags, and checking out the desired release. It's crucial to adjust your .env file with the new image versions (e.g., OTOBO_IMAGE=rotheross/otobo:11.0.10). After updating the configuration, pull the new Docker images using docker-compose pull. Next, stop the old containers cleanly with docker-compose down, migrate the code volume with docker-compose run --rm web copy_otobo_next, and then start the new containers using docker-compose up -d. Finally, perform OTOBO's internal update tasks via docker-compose exec web entrypoint.sh do_update_tasks and verify the upgrade.Quellen / Sources:- OTOBO Docker Update – Safely upgrading the version- Updating a Docker-based Installation of OTOBO

Why is it crucial to back up your OTOBO data before an upgrade?

Backing up your OTOBO data is an absolutely critical prerequisite before initiating any upgrade process, whether it's a major or minor version bump. This step safeguards your entire OTOBO environment, providing a reliable rollback point in case any unforeseen issues or complications arise during the update. Without a current backup, you risk data loss or a non-functional system, which can lead to significant downtime and operational disruption. Essential data to back up includes your database, all Docker volumes (especially for /opt/otobo), and your Elasticsearch index if you are using it. These backups ensure that you can restore your OTOBO instance to its previous working state if the upgrade doesn't proceed as expected, minimizing potential business impact.Quellen / Sources:- OTOBO Docker Update – Safely upgrading the version- Updating a Docker-based Installation of OTOBO

What are the essential prerequisites for safely upgrading OTOBO via Docker?

To ensure a safe and successful OTOBO upgrade using Docker, several prerequisites must be met. You need an existing OTOBO installation that is already running with Docker and Docker Compose. This ensures that your environment is correctly set up for containerized operations. SSH access to the host machine is also necessary to execute the required commands for updating configurations, pulling images, and managing containers. Most importantly, a complete backup of your critical data is indispensable. This includes:- Docker volumes for /opt/otobo- Your database- Your Elasticsearch index (if applicable)Finally, you must clearly identify your desired target OTOBO version, such as 11.0.10 or 10.1.8, as this will guide the specific Git checkout and image tag selections during the upgrade process.Quellen / Sources:- OTOBO Docker Update – Safely upgrading the version- Updating a Docker-based Installation of OTOBO

What is the process for updating the Docker Compose configuration and pulling new images during an OTOBO upgrade?

The initial steps for updating a Docker-based OTOBO involve preparing your Docker Compose environment. First, navigate to your OTOBO Docker project directory, typically /opt/otobo-docker. Then, you'll use Git commands to fetch the latest tags and switch to the desired release branch, for example, git fetch --tags followed by git checkout rel-11_0_10 for version 11.0.10. It's crucial to review and adjust your .env file to reflect the new image versions for OTOBO, Elasticsearch, and Nginx. For instance, you might change OTOBO_IMAGE=rotheross/otobo:11.0.9 to OTOBO_IMAGE=rotheross/otobo:11.0.10. Once your configuration is updated, execute docker-compose pull to download all the new Docker images specified in your updated docker-compose.yml and .env files. This ensures that the latest versions of all OTOBO components are available locally before you proceed with stopping and restarting your services.Quellen / Sources:- OTOBO Docker Update – Safely upgrading the version- Updating a Docker-based Installation of OTOBO

How do you perform the OTOBO internal update tasks and database migrations after container updates?

After successfully updating your Docker containers with the new OTOBO software, the next critical step is to perform OTOBO's internal update tasks and any necessary database migrations. This ensures that the application logic and database schema are aligned with the new version. You execute the primary update tasks by running docker-compose exec web entrypoint.sh do_update_tasks. This command triggers OTOBO's internal scripts to apply schema changes, update configurations, and perform other version-specific adjustments. For major version upgrades, such as moving from OTOBO 10.1 to 11.0, an additional, optional database migration script might be required. This is typically executed with docker exec -it otobo_web_1 perl scripts/DBUpdate-to-11.0.pl (adjusting the script name as per the target version). Always remember to check the update log located at /opt/otobo/var/log/update.log within the web container using docker-compose exec web cat /opt/otobo/var/log/update.log to confirm that all tasks completed without errors.Quellen / Sources:- OTOBO Docker Update – Safely upgrading the version- Updating a Docker-based Installation of OTOBO

What specific steps should be taken to verify a successful OTOBO Docker upgrade?

Verification is the final and crucial step to confirm that your OTOBO Docker upgrade was successful and that all services are functioning as expected. Begin by checking the status of your Docker containers using docker-compose ps. This command will show whether all OTOBO-related containers are running without issues. Next, perform essential functional tests:- Test login: Ensure that both agents and customers can successfully log into their respective portals.- Quick test of core functions: Create a new ticket, send and receive emails, and verify that other critical OTOBO functionalities (e.g., searching, dynamic fields, queues) are working correctly.- Review logs: While not explicitly listed as a step, it's always good practice to quickly review OTOBO application logs and Docker container logs for any unexpected errors or warnings that might indicate underlying problems not immediately apparent through functional tests. Thorough verification helps catch potential issues early, preventing disruptions to your service desk operations.Quellen / Sources:- OTOBO Docker Update – Safely upgrading the version- Updating a Docker-based Installation of OTOBO

Are there special considerations when upgrading OTOBO between major versions (e.g., 10.1 to 11.0)?

Yes, upgrading OTOBO between major versions, such as from 10.1 to 11.0, requires special attention beyond a typical minor version update. The most important consideration is to always perform the minor upgrade first, then the major upgrade. For example, if you are on 10.1.x and want to go to 11.0.x, you should first upgrade to the latest 10.1.x release (e.g., 10.1.8), and then proceed with the upgrade to 11.0.x. This staged approach helps ensure compatibility and smooth transitions for database schema changes and application logic. Additionally, major version upgrades often necessitate running a specific database migration script, like perl scripts/DBUpdate-to-11.0.pl, which is an optional but highly recommended step to update the database structure for the new major release. Always consult the official documentation for the specific major version you are targeting to understand any unique requirements or additional steps.Quellen / Sources:- OTOBO Docker Update – Safely upgrading the version- Updating a Docker-based Installation of OTOBO