How to Self-Host OTOBO with Docker Compose

What Is OTOBO?

If you need an ITIL-compliant service desk, OTOBO is the open-source fork of OTRS Community Edition — the ticketing system that enterprises used for decades before OTRS AG discontinued the open-source version. Rother OSS GmbH forked it and has been actively developing it since 2020 under the GPL-3.0 license.

OTOBO handles the full ITSM lifecycle: incident management, problem management, change management, service catalogs, SLA tracking, and asset management (CMDB). It includes a web installer, full-text search via Elasticsearch, email-to-ticket automation, and multi-channel support across email, phone, chat, and customer portal.

Prerequisites

A Linux server (Ubuntu 22.04+ recommended)
Docker and Docker Compose installed (guide)
8 GB of RAM (4 GB minimum for testing)
40 GB of free disk space
A domain name (recommended for production)
vm.max_map_count=262144 set for Elasticsearch

Set the kernel parameter:

sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf

Docker Compose Configuration

Create a docker-compose.yml:

services:
  db:
    image: mariadb:11.8.6-noble
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: changeme_root_password       # Change this
      MARIADB_AUTO_UPGRADE: "1"
    volumes:
      - mariadb-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mariadb-admin", "ping", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"]
      interval: 10s
      timeout: 5s
      retries: 10

  elastic:
    image: rotheross/otobo-elasticsearch:rel-11_0_15
    restart: unless-stopped
    environment:
      ES_JAVA_OPTS: "-Xms512m -Xmx512m"    # Adjust based on available RAM
    volumes:
      - elasticsearch-data:/usr/share/elasticsearch/data
    healthcheck:
      test: ["CMD-SHELL", "curl -sf http://localhost:9200/_cluster/health || exit 1"]
      interval: 15s
      timeout: 10s
      retries: 10

  redis:
    image: redis:8-bookworm
    restart: unless-stopped
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  web:
    image: rotheross/otobo:rel-11_0_15
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
      elastic:
        condition: service_healthy
      redis:
        condition: service_healthy
    ports:
      - "80:5000"
    environment:
      OTOBO_WEB_OPTION: "deployment"
    volumes:
      - otobo-data:/opt/otobo
    healthcheck:
      test: ["CMD-SHELL", "curl -sf http://localhost:5000/robots.txt || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5

  daemon:
    image: rotheross/otobo:rel-11_0_15
    restart: unless-stopped
    depends_on:
      web:
        condition: service_healthy
    command: /opt/otobo_install/entrypoint.sh daemon
    volumes:
      - otobo-data:/opt/otobo    # Shared volume with web

volumes:
  mariadb-data:
  elasticsearch-data:
  redis-data:
  otobo-data:

Start the stack:

docker compose up -d

Wait 2-3 minutes for all services to initialize. Check health:

docker compose ps

Initial Setup

Open http://your-server-ip/otobo/installer.pl in your browser
Accept the license (GPL-3.0) and proceed
On the database configuration page:

Field	Value
Database Type	MySQL
Database Host	`db`
Database User	`root`
Root Password	Your `MYSQL_ROOT_PASSWORD`

The installer creates the otobo database user and schema automatically
Set your admin email, organization name, and system FQDN
Create the admin account with a strong password
Complete the wizard — OTOBO generates default queues, groups, and SLA configurations

Configuration

Queue and Agent Setup

OTOBO organizes tickets into queues (similar to categories or departments). Default queues include Raw, Junk, and Misc. Create queues for your support structure:

Navigate to Admin → Ticket Settings → Queues
Create queues like “Support”, “Sales”, “Engineering”
Assign queues to agent groups for access control

Email Integration

Configure email-to-ticket by setting up PostMaster Mail Accounts:

Go to Admin → Communication → PostMaster Mail Accounts
Add your IMAP/POP3 mail account details
OTOBO polls the mailbox and converts incoming emails to tickets
Configure PostMaster Filter rules to route emails to specific queues based on headers, sender, or content

SLA Configuration

Define SLAs under Admin → Ticket Settings → Service Level Agreements:

Field	Example
Name	Priority Support
First Response Time	1 hour
Update Time	4 hours
Solution Time	24 hours
Calendar	Default (24/7) or business hours

Elasticsearch Configuration

OTOBO’s full-text search indexes ticket content, email bodies, and attachments. The search is configured automatically when Elasticsearch is available. Verify it’s working:

Go to Admin → System Administration → System Configuration
Search for Elasticsearch — verify the host is set to elastic port 9200

Advanced Configuration

HTTPS with Nginx Proxy

For production, add the OTOBO Nginx proxy container. Create SSL certificates first:

# Create SSL volume
docker volume create otobo_nginx_ssl

# Copy your certificates
docker run --rm -v otobo_nginx_ssl:/ssl -v /path/to/certs:/certs alpine \
  sh -c "cp /certs/cert.pem /ssl/ssl-cert.pem && cp /certs/key.pem /ssl/ssl-key.pem"

Add the Nginx service to your compose file:

  nginx:
    image: rotheross/otobo-nginx-webproxy:rel-11_0_15
    restart: unless-stopped
    depends_on:
      web:
        condition: service_healthy
    ports:
      - "443:8443"
      - "80:8080"      # HTTP to HTTPS redirect
    environment:
      OTOBO_NGINX_WEB_HOST: "web"
      OTOBO_NGINX_WEB_PORT: "5000"
    volumes:
      - otobo_nginx_ssl:/etc/nginx/ssl:ro

Remove the port mapping from the web service when using the Nginx proxy.

LDAP/Active Directory

Configure LDAP authentication under Admin → System Administration → System Configuration. Search for Customer::AuthModule and configure the LDAP backend with your directory server details.

CMDB (Configuration Management Database)

OTOBO includes ITSM modules for asset management. Enable CMDB under Admin → CMDB to track configuration items (servers, services, software) and link them to tickets for impact analysis.

Reverse Proxy

If using an external reverse proxy instead of OTOBO’s built-in Nginx, point to port 5000 (the Gazelle/Plack web server). OTOBO requires WebSocket support for real-time features.

For general reverse proxy setup, see our Reverse Proxy guide.

Backup

OTOBO stores all data in two locations: MariaDB (tickets, config, users) and the shared volume (attachments, custom modules). Back up both:

# Database backup
docker compose exec db mariadb-dump -u root -p --all-databases > otobo_db_backup.sql

# Application data backup
docker run --rm -v otobo_otobo-data:/data -v $(pwd):/backup alpine \
  tar czf /backup/otobo-data.tar.gz -C /data .

For a comprehensive backup strategy, see our Backup guide.

Troubleshooting

Elasticsearch Out of Memory

Symptom: The elastic container exits with an OOM error.

Fix: Increase the JVM heap size in the compose environment:

environment:
  ES_JAVA_OPTS: "-Xms1g -Xmx1g"

Also verify vm.max_map_count=262144 is set:

sysctl vm.max_map_count

Web Installer Not Loading

Symptom: installer.pl returns 404 or a blank page.

Fix: The web server needs 1-2 minutes to start. Check the container logs:

docker compose logs web

If MariaDB isn’t ready yet, the web service waits due to the health check dependency.

Daemon Not Processing Tickets

Symptom: Email fetching or escalation timers aren’t working.

Fix: The daemon container runs background jobs (email fetch, escalations, generic agent). Check its status:

docker compose logs daemon

The daemon depends on the web service and shares its data volume. If the otobo-data volume isn’t properly shared, the daemon can’t access configuration.

Slow Full-Text Search

Symptom: Ticket search takes several seconds.

Fix: Reindex Elasticsearch. In the OTOBO admin panel, go to Admin → System Administration → Elasticsearch and trigger a reindex. For large installations, increase the Elasticsearch heap size.

Resource Requirements

Resource	Minimum (Testing)	Recommended (Production)
RAM	4 GB	8-16 GB
CPU	2 cores	4+ cores
Disk	10 GB	40+ GB
Elasticsearch heap	512 MB	1-4 GB

OTOBO is one of the heavier self-hosted helpdesk options due to its Elasticsearch dependency and Perl-based architecture. The trade-off is enterprise-grade ITSM functionality.

Verdict

For teams that need ITIL-compliant service management — incident tracking, change management, SLA enforcement, CMDB — OTOBO is the only serious open-source contender. It’s the natural successor to OTRS Community Edition with active development and a clear roadmap.

If you just need a helpdesk for customer email, OTOBO is overkill. FreeScout or LibreDesk handle that with a fraction of the resource requirements. OTOBO exists for organizations that need ITIL workflows, and it does that job well.

FAQ

Is OTOBO the same as OTRS?

OTOBO is a fork of OTRS Community Edition, created after OTRS AG discontinued the open-source version. OTOBO includes all the community features plus continued development under GPL-3.0. Migration from OTRS is supported.

How much RAM does OTOBO actually use?

A minimal deployment with Elasticsearch at 512 MB heap uses about 3-4 GB total. Production deployments with 1-2 GB Elasticsearch heap, active ticket volume, and the daemon running use 6-10 GB.

Can OTOBO handle customer-facing support?

Yes. OTOBO includes a customer portal where customers can create and track tickets. It supports email-to-ticket, web forms, and phone ticket creation by agents.

Does OTOBO support migration from Zendesk or Freshdesk?

Not directly. OTOBO includes migration tools for OTRS. For Zendesk/Freshdesk migration, you’d need to export tickets via their APIs and import them using OTOBO’s Generic Agent or API.