Hosting van het OTOBO-ticketsysteem – Gids voor beginners en gevorderden

Inleiding

OTOBO is een veelzijdig, open-source ticketsysteem (een fork van de ((OTRS)) Community Edition) voor helpdesks en servicebeheer. Bedrijven kunnen hiermee klantvragen en interne taken efficiënt beheren. In tegenstelling tot cloudoplossingen is OTOBO gratis, maar moet het op een eigen server worden gehost – waardoor hosting een cruciale rol speelt. Stabiele en veilige hosting zorgt ervoor dat het ticketsysteem altijd beschikbaar is, goed presteert en gevoelige gegevens beschermt blijven. Dit artikel biedt een uitgebreid overzicht van OTOBO-hosting – van vereisten en installatie (via Docker) tot vergelijking van aanbieders en best practices.

Hardware- en besturingssysteemvereisten voor OTOBO (Docker-installatie)

Voordat u begint met de installatie, moet u controleren of uw hardware en besturingssysteem voldoen aan de vereisten van OTOBO. In principe draait OTOBO alleen op Linux/Unix-systemen. Voor een Docker-gebaseerde installatie raadt het OTOBO-project een recente Linux-distributie aan (zoals Ubuntu 20.04 LTS of nieuwer) als hostsysteem.

Minimale hardware (testomgeving): Voor kleine testinstallaties volstaat een server met ongeveer 2 CPU-kernen, 4 GB RAM en 15–20 GB opslag. Dit is voldoende voor een beperkt aantal tickets per dag en kleine bijlagen.

Aanbevolen hardware (productie): Voor productiegebruik met een hogere ticketvolume dient de machine krachtiger te zijn – bijvoorbeeld 4 vCPU, 8 GB RAM (beter 16 GB) en 40+ GB schijfruimte. Ruime RAM zorgt ervoor dat de database, webserver en diensten zoals Elasticsearch soepel draaien. De exacte dimensie hangt af van gebruik (aantal tickets, gebruikers, bijlagen); plan bij twijfel liever wat extra capaciteit in.

Tip

Gebruik indien mogelijk SSD-gebaseerde opslag voor snelle database-toegang en back-ups. Zorg er ook voor dat Docker op de host is geïnstalleerd (getest met minimaal Docker 19.03+ en Docker Compose 1.25+). Meer details vindt u in de OTOBO-installatiehandleiding (sectie Systeemvereisten).

Vergelijking van hostingaanbieders voor OTOBO

De keuze van de hostingaanbieder beïnvloedt aanzienlijk de inspanning, kosten en prestaties van uw OTOBO-systeem. Hieronder vergelijken we vier veelgebruikte opties – van Duitse datacenters tot de globale cloud – met hun voor- en nadelen.

Hetzner

Hetzner is een Duitse aanbieder bekend om voordelige hosting met hoge prestaties. Voordelen zijn onder andere serverlocaties in Duitsland (ideaal voor gegevensbescherming) en een uitstekende prijs-kwaliteitverhouding – vergelijkbare resources kosten bij AWS/Azure vaak een veelvoud (AWS and Azure are At Least 4x–10x More Expensive Than Hetzner). Hetzner biedt zowel cloudservers (flexibel schaalbaar, per uur factureerbaar) als dedicated servers met volledige roottoegang. Voor OTOBO Docker-installaties zijn de cloud VPS of CX/CPX-servers van Hetzner populair, omdat ze Docker direct ondersteunen. Voordelen: Lage kosten, snelle hardware (NVMe-SSDs, AMD EPYC/Intel Xeon CPU's), eenvoudig beheer via een webconsole, gegevensopslag in Duitse datacenters. Nadelen: Geen wereldwijd netwerk – datacenters voornamelijk in Duitsland (en Finland), dus minder ideaal voor internationale gebruikers met lage latentie-eisen. Bovendien dient u het systeem zelf te beheren (geen beheerde ondersteuning in basistarief). Over het algemeen is Hetzner ideaal voor ervaren gebruikers of bedrijven die kostenefficiënt in Duitsland willen hosten.

AWS (Amazon Web Services)

AWS is een wereldwijde cloudmarktleider met een enorme keuze aan diensten. Voor OTOBO-hosting kunt u bijvoorbeeld Amazon EC2-instanties gebruiken (virtuele Linux-servers) of beheerde databases via RDS koppelen. Voordelen: Hoogste flexibiliteit en schaalbaarheid – u kunt de servercapaciteit naar behoefte op- of afbouwen, load balancing en auto-scaling gebruiken en kiezen uit vele regio's wereldwijd. Er zijn ook tal van aanvullende diensten (back-up, monitoring, CDN) die in de OTOBO-omgeving kunnen worden geïntegreerd. Nadelen: Kosten – AWS is aanzienlijk duurder dan Hetzner bij gelijke prestaties (AWS and Azure are At Least 4x–10x More Expensive Than Hetzner), vooral bij langdurige reserveringen. De prijsstructuur is complex (bijv. kosten voor verkeer, opslag, back-ups apart), wat voor beginners verwarrend kan zijn. Bovendien vereist AWS expertise, omdat de vele opties de configuratie ingewikkelder maken. AWS is vooral interessant voor grote implementaties of als u waarde hecht aan wereldwijde beschikbaarheid en beheerde diensten. Voor een mkb-bedrijf dat OTOBO afzonderlijk gebruikt, zijn de extra kosten van AWS vaak niet gerechtvaardigd.

Microsoft Azure

Azure (van Microsoft) is net als AWS een wereldwijde cloudplatform met uitgebreide diensten. Azure biedt Linux-VM's voor Docker evenals containerdiensten (zoals Azure Container Instances of AKS, indien u Kubernetes wilt gebruiken). Voordelen: Goede integratie in het Microsoft-ecosysteem – ideaal als u al Microsoft-diensten gebruikt (Azure AD voor Single Sign-On, koppeling met Office 365, enz.). Azure heeft datacenters wereldwijd, inclusief in Europa, en biedt betrouwbare infrastructuur met uitgebreide compliancecertificeringen (belangrijk voor zakelijke klanten). Nadelen: Kosten en complexiteit zijn vergelijkbaar met AWS – Azure behoort ook tot de duurdere opties, vooral bij veel resources of Windows-servers. Het beheer via het Azure-portaal vereist inwerkingsperiode; voor zuivere Linux/Docker-hosts kan het soms overdreven zijn. Als hoofdzakelijk één OTOBO-systeem wordt beheerd, kan Azure – net als AWS – overbodig lijken. Het is echter een sterke optie voor bedrijven die al op Microsoft zijn aangesloten of extra Azure-diensten (AI, BI, enz.) willen integreren.

IONOS (1&1 IONOS)

IONOS is een Duitse hostingaanbieder die zowel klassieke webhostingpakketten als cloudservers en beheerde diensten aanbiedt. Voor het hosten van een OTOBO-ticketsysteem wordt bij IONOS een cloudserver of VPS met Linux aanbevolen, waarop u Docker kunt installeren. Voordelen: Datacenterlocatie in Duitsland (ideaal voor AVG) en Nederlandstalige ondersteuning. IONOS richt zich op gebruiksvriendelijkheid – het dashboard is beginner-vriendelijk, en er zijn one-click-installers voor sommige toepassingen (voor OTRS/OTOBO is er echter geen standaardimage bekend, per vandaag). Prijstechnisch liggen de cloudservers in het middensegment, vaak goedkoper dan AWS/Azure, maar meestal iets duurder dan Hetzner bij gelijke prestaties. Nadelen: Minder communityresources en tutorials online in vergelijking met AWS/Hetzner. Bovendien zijn de goedkoopste tarieven (shared hosting) niet geschikt voor OTOBO; u hebt minstens een dedicated VM-tarief met Docker-ondersteuning nodig. Over het algemeen is IONOS een goede keuze als u een Duitse aanbieder met ondersteuning wilt en tevreden bent met een conventionele hostingomgeving.

Beheerd OTOBO-hosting

Als u de technische inspanning wilt vermijden, zijn er ook beheerde hosting-aanbieders voor OTOBO. Hierbij zorgt een dienstverlener voor installatie, updates, monitoring en back-ups, terwijl u het ticketsysteem gewoon kunt gebruiken. Enkele gespecialiseerde bedrijven bieden OTOBO beheerde hosting aan.

Tip

Of u nu zelf beheert of beheerde hosting gebruikt – zorg ervoor dat de hostlocatie voldoet aan uw compliance-eisen. Veel Duitse bedrijven geven bijvoorbeeld de voorkeur aan Hetzner of IONOS om hun gegevens in Duitsland te houden.

Installatie van OTOBO met Docker

• OTOBO-installatie;
• Geavanceerde installatie

Best practices voor veilig en presterend OTOBO-hosting

Nadat u OTOBO succesvol hebt geïnstalleerd, dient u enkele best practices te volgen om de werking zo veilig, snel en betrouwbaar mogelijk te maken. Hieronder de belangrijkste aanbevelingen voor prestaties, beveiliging en back-ups:

Prestatie-tips

• Caching en zoekindex gebruiken: OTOBO bevat via Docker al Redis als cache en Elasticsearch voor fulltextzoekopdrachten. Zorg dat deze containers actief zijn (otobo_redis_1 en otobo_elastic_1 draaien standaard) – ze verbeteren de prestaties aanzienlijk (snellere paginalading, snellere zoekresultaten). Zonder Elasticsearch moet de database alle ticketteksten doorzoeken, wat trager is.

• Voldoende resources toewijzen: Houd de CPU- en geheugengebruik van uw server in de gaten. Bij veel gelijktijdige agents of tickets kan 4 GB RAM ontoereikend zijn – schaal op naar 8 of 16 GB voordat het systeem gaat swappen. Hetzelfde geldt voor de CPU: meer kernen helpen bij veel parallelle verzoeken. Gebruik eventueel een aparte database-server bij hoge belasting (in Docker kunt u de database ook op een afzonderlijke host plaatsen).

• Aantal tickets beheren: Laat niet tienduizenden open tickets in de actieve wachtrij staan. Archiveer of sluit oude tickets regelmatig. OTOBO heeft functies voor archivering van tickets, wat de ticketlijsten en zoekindexen ontlast. Bovendien kan bij een zeer groot aantal tickets de overstap naar de statische ticketindex zinvol zijn (Performance Tuning — OTOBO Installation Guide 10.1 documentation) – dit is echter meestal pas nodig bij >80.000 open tickets.

• Bestandsopslag optimaliseren: Standaard slaat OTOBO bijlagen als bestanden op in het volume. Dit is sneller dan opslag in de database. Zorg dat het volume (otobo_opt_otobo in Docker) op snelle opslag staat. Indien nodig kunt u de bijlagenmap op een aparte partitie plaatsen. Houd voldoende vrije schijfruimte vrij – bij veel of grote bijlagen kan de schijf anders vollopen en het systeem vastlopen.

• Monitoring instellen: Houd uw systeem in de gaten (CPU, RAM, databaseprestaties, Docker-containerstatus). Vroegtijdige waarschuwingen bij hoge belasting of fouten maken proactief handelen mogelijk. Docker biedt met docker stats eenvoudige livegegevens per container. Voor langdurig monitoring kunnen tools zoals Prometheus/Grafana of CloudWatch (bij AWS) worden gebruikt.

Beveiligingsmaatregelen

• Updates en patches installeren: Houd OTOBO, het besturingssysteem en Docker up-to-date. Beveiligingsupdates van het OTOBO-project dienen snel te worden geïnstalleerd (bij Docker gewoon een nieuw image ophalen en container herstarten). Werk ook regelmatig gebruikte Perl-modules en bibliotheken bij, indien u een handmatig systeem heeft.

• HTTPS gebruiken: Beveilig de webinterface met SSL/TLS. In de Docker-omgeving kunt u de meegeleverde Nginx-proxy gebruiken (zie .env-optie voor HTTPS) of een externe proxy/webserver plaatsen. Gratis certificaten van Let’s Encrypt kunnen automatisch worden geïntegreerd. Zo zorgt u dat aanmeldgegevens en gevoelige ticketinhoud versleuteld worden overgedragen.

• Sterke wachtwoorden & 2FA: Vereis complexe wachtwoorden voor alle agentaccounts. Wijzig het standaard-adminwachtwoord direct na installatie. OTOBO biedt tweefactorauthenticatie (OTP) voor agents (OTOBO/Znuny en OTRS ((Community Edition)) Inleiding - Aan de slag | OTOBO) – overweeg deze in te schakelen voor extra beveiliging.

• Toegang beveiligen: Beperk indien mogelijk de externe toegang tot de OTOBO-interface. Bijvoorbeeld via VPN of vaste IP-whitelist voor het agenteninterface, als alleen medewerkers intern moeten kunnen verbinden. In elk geval mag de admin-dashboard-URL niet openbaar op internet staan. Gebruik ook firewalls (UFW, iptables of cloudbeveiligingsgroepen) om alleen de benodigde poorten (HTTP/HTTPS, SSH) open te zetten. De database- en Redis/Elasticsearch-poorten mogen niet openbaar toegankelijk zijn.

• Serververharding: Schakel ongebruikte diensten uit op Linux-servers en installeer alleen noodzakelijke software. Stel regelmatige beveiligingsscans in. Als u RHEL/CentOS gebruikt, houd er rekening mee dat SELinux Docker-containers kan beperken – configureer de benodigde rechten of schakel SELinux uit, anders werkt OTOBO mogelijk niet correct.

Back-ups en onderhoud

• Regelmatige back-ups: Voer dagelijks back-ups uit van de OTOBO-database en belangrijke mappen. In Docker-omgevingen kunt u bijv. met docker exec een MySQL-dump maken en bestanden uit het volume veiligstellen. Automatiseer dit via een cronjob. Bewaar back-ups op externe systemen of opslag (bijv. cloudopslag), zodat ze ook bij serveruitval beschikbaar zijn.

• Back-upstrategie testen: Controleer uw back-ups regelmatig via testherstel. Niets is erger dan een back-up die in noodgevallen onbruikbaar blijkt. OTOBO biedt officiële handleidingen voor back-up en herstel – volg deze en documenteer de procedure intern.

• Configuratie documenteren: Noteer welke aanpassingen u aan de OTOBO-configuratie hebt gedaan (bijv. in SysConfig, extra pakketten/add-ons, cronjobs). Dit helpt bij het snel opsporen van problemen bij fouten of updates. Exporteer belangrijke instellingen en houd versies van de Docker-Compose-bestanden en .env-bestanden onder versiebeheer.

• Updates plannen: Plan onderhoudsvensters voor OTOBO-upgrades in. Bij een Docker-gebaseerde installatie kan een update betekenen dat nieuwe containers worden opgestart. Maak eerst een back-up, controleer de release notes en test de upgrade idealiter in een stagingomgeving. Zo houdt u uw systeem op lange termijn veilig en compatibel.

Veelvoorkomende problemen en oplossingen bij OTOBO-hosting

Ondanks goede voorbereiding kunnen tijdens het gebruik problemen optreden. Hieronder enkele veelvoorkomende problemen bij OTOBO-hosting (met name in Docker-omgevingen) en tips voor probleemoplossing:

• Webinterface niet bereikbaar: Als de OTOBO-webinterface niet laadt, controleer dan eerst of alle Docker-containers draaien: docker-compose ps zou voor web, db, enz. "Up (healthy)" moeten tonen. Zorg dat de poort (standaard 80 of 5000) in de firewall is vrijgegeven. Bij toegang via een domein controleer DNS-instellingen en de .env-configuratie (FQDN). Oplossing: Voer docker-compose logs web uit voor foutmeldingen. Vaak helpt een docker-compose restart van de betrokken services. Bij Connection refused-fouten zorg dat geen andere dienst de poort blokkeert.

• Prestatieproblemen: Reageert het systeem traag of hangt het? Controleer of de server mogelijk geheugentekort heeft (swapgebruik) of de CPU overbelast is. Vaak is te weinig RAM de oorzaak – MySQL presteert dan slecht. Oplossing: Wijs meer RAM/CPU toe of schaal op naar een grotere server. Controleer ook of Redis en Elasticsearch correct draaien – zonder cache en index wordt OTOBO aanzienlijk trager. Een blik in het OTOBO-systeemlog (adminomgeving of bestand otobo.log) kan tonen of queries te lang duren. Archiveer indien nodig oude tickets om de actieve gegevenshoeveelheid klein te houden.

• E-mailverzending of -ontvangst mislukt: OTOBO haalt e-mails op uit postvakken en verzendt via SMTP. Werkt dit niet, dan ligt het vaak aan verkeerde instellingen of verbindingsproblemen. Oplossing: Open de SysConfig in OTOBO en controleer de e-mailaccountinstellingen (server, poort, gebruiker, wachtwoord). Bij Office 365/Exchange moeten soms moderne authenticatiemethoden of app-wachtwoorden worden gebruikt. Houd het OTOBO-log in de gaten op foutmeldingen bij e-mailontvangst (trefwoord IMAP/POP-fouten) of verzending (SMTP-fouten). Een typische fout is "Authentication failed" – dan kloppen de inloggegevens niet. Bij SSL/TLS-problemen (certificaatfouten) zorg dat de container de e-mailserver vertrouwt (indien nodig CA-certificaat installeren). Ook firewallinstellingen van de server kunnen het probleem zijn – sta uitgaande verbindingen toe op poort 993 (IMAPS) en 587/465 (SMTPS) in de serverfirewall.

• Docker-containerproblemen (crashes, rechten): Als containers onverwacht stoppen of herstarten (crash loop), kijk met docker-compose logs naar foutmeldingen. Een veelvoorkomend probleem zijn bestandsrechten op de gekoppelde volumes. De OTOBO-container draait als gebruiker otobo (UID 1000) – zorg dat de mappen op de host deze UID schrijfrechten geven. Foutmeldingen als "Permission denied" in de logs wijzen hierop. Oplossing: Voer indien nodig het script otobo.SetPermissions.pl (in de container onder /opt/otobo/bin/) uit om rechten goed in te stellen. Of pas de eigenaar op de host aan (chown -R 1000:1000 ./otobo-docker/opt_otobo). Een ander probleem kunnen ontbrekende omgevingsvariabelen zijn – als docker-compose up direct afbreekt, controleer of alle vereiste variabelen in de .env zijn ingesteld. Voorbeeld: ontbreekt MYSQL_ROOT_PASSWORD, dan start de database niet. Raadpleeg de documentatie voor vereiste .env-invoer.

• Back-up/herstelfouten: Bij het herstellen van een back-up kunnen fouten optreden, zoals incompatibele databaseversie of ontbrekende bestanden. Oplossing: Zorg dat dezelfde OTOBO-versie wordt gebruikt als waarmee het back-up is gemaakt. Importeer eerst de database (bijv. via mysql < backup.sql in de DB-container) en herstel daarna bijlagen en configuratiebestanden. Stel daarna de rechten correct in. Controleer na het herstel de OTOBO-logs en systeemconfiguratie. Bij grotere versieverschillen voer het migratiescript uit (otobo.Console.pl Maint::Database::Migration) indien nodig. Bij twijfel vindt u in de OTOBO-documentatie onder Backup and Restore verdere hulp.

Conclusie

Met zorgvuldige planning en het volgen van deze richtlijnen lukt OTOBO-hosting zowel beginners als gevorderden. Van de juiste keuze van infrastructuur tot optimale installatie, beveiliging en prestaties – met deze gids haalt u het maximale uit uw OTOBO-ticketsysteem. Bij vragen of complexe omgevingen aarzel niet om gebruik te maken van de uitgebreide OTOBO-documentatie en de community, of een ervaren OTOBO-dienstverlener te raadplegen. Veel succes met uw OTOBO-server!