Spreadsheets stop working as an IT inventory somewhere around the third rack. i-doit is the tool most teams reach for at that point: an open source CMDB and IT documentation system that tracks servers, VMs, racks, licenses, cabling, and the relationships between them, following ITIL practice. The Open edition is free, self-hosted, and runs on a plain LAMP stack.
This guide covers everything needed to install i-doit on Ubuntu: Apache with PHP-FPM, a tuned MariaDB, Let’s Encrypt HTTPS, the web setup wizard, and the console installer for anyone scripting the deployment. If you are still comparing tools, we have separate guides for Snipe-IT, GLPI, and the Ralph CMDB. The stack, the setup wizard, and the console install were run end to end in August 2026 on Ubuntu 24.04 (PHP 8.3, MariaDB 10.11) and again on Ubuntu 26.04 (PHP 8.5, MariaDB 11.8), against i-doit Open 38; our lab sat on a private LAN, so its certificate came through the DNS-01 path described below.
What i-doit expects from the host
The current i-doit release is strict about its stack, and the two Ubuntu LTS releases land on different sides of that line. This matters before you type a single command:
| Component | Supported by i-doit | Ubuntu 24.04 ships | Ubuntu 26.04 ships |
|---|---|---|---|
| PHP | 8.2 (deprecated), 8.3, 8.4 (recommended) | 8.3 (supported) | 8.5 (above the supported range) |
| MariaDB | 10.6, 10.11 (recommended), 11.4, 11.8 | 10.11 (recommended) | 11.8 (supported) |
| Web server | Apache 2.4 | Apache 2.4 | Apache 2.4 |
Ubuntu 24.04 is the clean match, and it is the release this guide leads with. Ubuntu 26.04 works, but its PHP is newer than what i-doit officially supports, and the installer says so out loud. The Ubuntu 26.04 section further down covers the exact differences we hit. The full matrix lives in the official i-doit system requirements.
On hardware, the vendor minimum is 2 vCPUs, 2 GB RAM, and 10 GB disk for roughly 10,000 objects and 10 concurrent users, with 8 GB RAM and 50 GB disk as the reference configuration. RAM is the real driver: MariaDB’s InnoDB buffer pool should hold your working set, so a large CMDB with heavy reporting wants the reference spec or better. Our test VM ran 2 vCPUs and 4 GB RAM, which is a floor for following along, not a production recommendation.
Install Apache, PHP, and MariaDB
One apt line covers the whole stack. i-doit’s own install documentation moved from mod_php to PHP-FPM behind Apache’s fcgid module, so that is what we install here. On Ubuntu 24.04:
sudo apt update
sudo apt install -y apache2 libapache2-mod-fcgid mariadb-server mariadb-client \
memcached unzip moreutils php-bcmath php-cli php-common php-curl php-fpm \
php-gd php-imagick php-ldap php-mbstring php-memcached php-mysql \
php-opcache php-pgsql php-soap php-xml php-zipOn Ubuntu 26.04, drop php-opcache from that line. The meta package no longer exists there because OPcache is compiled into the base PHP packages, and apt aborts the whole install if you keep it. Everything else is identical.
Confirm the PHP and MariaDB versions apt resolved:
php -v | head -1
mariadb --versionOn 24.04 you get the combination i-doit recommends:
PHP 8.3.6 (cli) (built: Jul 16 2026 18:30:41) (NTS)
mariadb Ver 15.1 Distrib 10.11.14-MariaDB, for debian-linux-gnu (x86_64)Configure PHP for i-doit
i-doit needs a handful of PHP settings raised above their defaults, mainly upload sizes, execution time, and max_input_vars, which the setup wizard checks explicitly. Ubuntu’s PHP packaging has a clean mechanism for this: drop a file in mods-available and enable it for every SAPI at once. Create the file:
sudo vim /etc/php/8.3/mods-available/i-doit.iniPaste the following, adjusting date.timezone to your own zone:
allow_url_fopen = Yes
file_uploads = On
max_execution_time = 300
max_file_uploads = 42
max_input_time = 60
max_input_vars = 10000
memory_limit = 256M
post_max_size = 128M
register_argc_argv = On
short_open_tag = On
upload_max_filesize = 128M
display_errors = Off
display_startup_errors = Off
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
log_errors = On
default_charset = "UTF-8"
default_socket_timeout = 60
date.timezone = Africa/Nairobi
session.gc_maxlifetime = 604800
session.cookie_lifetime = 0
mysqli.default_socket = /var/run/mysqld/mysqld.sockOn 26.04 the path is /etc/php/8.5/mods-available/i-doit.ini, same content. Enable the config together with the memcached module, then restart PHP-FPM:
sudo phpenmod i-doit memcached
sudo systemctl restart php8.3-fpmThe FPM unit is versioned (php8.5-fpm on 26.04), which catches people out because the CLI binary and the socket symlink are not. We use the versionless /run/php/php-fpm.sock in the Apache config later precisely so the vhost survives a PHP upgrade.
Tune MariaDB and set a root password
i-doit is database-heavy, and the vendor ships a recommended InnoDB profile. Create a dedicated config so it overrides the distro defaults cleanly:
sudo vim /etc/mysql/mariadb.conf.d/99-i-doit.cnfAdd the tuning block. The buffer pool line is the one worth thinking about: 1G is safe on a 4 GB host, and the vendor’s own examples scale it to 5-6G on an 8 GB host and 20-25G on 32 GB:
[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 512M
innodb_sort_buffer_size = 64M
sort_buffer_size = 262144
join_buffer_size = 262144
max_allowed_packet = 128M
max_heap_table_size = 32M
tmp_table_size = 32M
max_connections = 200
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
innodb_lru_scan_depth = 2048
table_definition_cache = 1024
table_open_cache = 2048
innodb_stats_on_metadata = 0
sql-mode = ""Restart MariaDB and check it came back clean:
sudo systemctl restart mariadb
systemctl is-active mariadbNow the step the old LAMP tutorials skip. Ubuntu’s MariaDB authenticates root through unix_socket, with no password at all. That works fine on the shell, but the i-doit setup wizard connects over TCP as the database root user, and a socket-only root cannot log in that way. Give root a real password before you open the wizard:
sudo mariadb -e "ALTER USER 'root'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('StrongDBPass2026'); FLUSH PRIVILEGES;"Pick your own password, obviously. Verify password login works before moving on:
mariadb -u root -p -e "SELECT VERSION();"The version string confirms authentication now works over a normal client connection:
VERSION()
10.11.14-MariaDB-0ubuntu0.24.04.1Download and extract i-doit
The Open edition is distributed through SourceForge, linked from i-doit.org. SourceForge exposes the newest release through its JSON API, so the download can detect the current version at runtime instead of hardcoding one:
IDOIT_VER=$(curl -s https://sourceforge.net/projects/i-doit/best_release.json | grep -oE "i-doit/[0-9]+/" | head -1 | tr -d "a-z/-")
echo "${IDOIT_VER}"The echo prints a bare release number:
38Download the archive and unpack it into the web root:
curl -sL -o idoit-open-${IDOIT_VER}.zip "https://sourceforge.net/projects/i-doit/files/i-doit/${IDOIT_VER}/idoit-open-${IDOIT_VER}.zip/download"
sudo mkdir -p /var/www/html/i-doit
sudo unzip -q idoit-open-${IDOIT_VER}.zip -d /var/www/html/i-doitError: “End-of-central-directory signature not found”
This unzip error means the file you downloaded is not a zip archive but SourceForge’s mirror-selection HTML page. It happens when the download command does not follow redirects, and plain wget on the raw project URL produced exactly this during our testing. The fix is the URL form ending in /download together with curl -L, as shown above. A quick file idoit-open-38.zip should report “Zip archive data” before you extract.
Hand the tree to the web server user and set the permissions the vendor documents:
cd /var/www/html/i-doit
sudo chown -R www-data:www-data .
sudo find . -type d -exec chmod 775 {} \;
sudo find . -type f -exec chmod 664 {} \;
sudo chmod 774 console.php *.sh setup/*.shCreate the Apache virtual host
The vhost points at the i-doit directory, allows the shipped .htaccess rewrite rules, and hands PHP files to FPM over the versionless socket:
sudo vim /etc/apache2/sites-available/i-doit.confUse your real domain in place of the example:
<VirtualHost *:80>
ServerName idoit.example.com
ServerAdmin [email protected]
DocumentRoot /var/www/html/i-doit
<Directory /var/www/html/i-doit>
AllowOverride All
Require all granted
</Directory>
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch>
ErrorLog ${APACHE_LOG_DIR}/i-doit_error.log
CustomLog ${APACHE_LOG_DIR}/i-doit_access.log combined
</VirtualHost>Swap the default site for this one, enable the modules FPM and the rewrite rules need, and restart:
sudo a2dissite 000-default
sudo a2ensite i-doit
sudo a2enmod rewrite proxy_fcgi setenvif
sudo apache2ctl configtest
sudo systemctl restart apache2If UFW is active on the host, open the web ports as well with sudo ufw allow 80,443/tcp. This stack is the same one our LAMP setup guide builds in more depth, if you want the background on any piece of it.
Add HTTPS with Let’s Encrypt
A CMDB holds your infrastructure’s crown jewels, so it does not run over plain HTTP. With an A record pointing at the server and port 80 reachable, any DNS provider works for the standard HTTP-01 challenge:
sudo apt install -y certbot python3-certbot-apache
sudo certbot certonly --apache -d idoit.example.com --non-interactive --agree-tos -m [email protected]Then replace the vhost with an SSL pair: the 443 site serving i-doit, and the port 80 site reduced to a redirect. Edit the same file:
sudo vim /etc/apache2/sites-available/i-doit.confThis is the exact configuration our test instance served the wizard and every screenshot below through:
<VirtualHost *:443>
ServerName idoit.example.com
ServerAdmin [email protected]
DocumentRoot /var/www/html/i-doit
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/idoit.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/idoit.example.com/privkey.pem
<Directory /var/www/html/i-doit>
AllowOverride All
Require all granted
</Directory>
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch>
ErrorLog ${APACHE_LOG_DIR}/i-doit_error.log
CustomLog ${APACHE_LOG_DIR}/i-doit_access.log combined
</VirtualHost>
<VirtualHost *:80>
ServerName idoit.example.com
Redirect permanent / https://idoit.example.com/
</VirtualHost>Enable SSL and reload:
sudo a2enmod ssl
sudo apache2ctl configtest
sudo systemctl restart apache2Renewal is automatic through the systemd timer certbot installs; sudo certbot renew --dry-run confirms it.
Server on a private network? Use the DNS-01 challenge
HTTP-01 requires Let’s Encrypt to reach port 80 from the internet. For a CMDB on an internal LAN (which is where ours ran, and honestly where most belong), issue the certificate through DNS instead. Install your DNS provider’s certbot plugin, e.g. python3-certbot-dns-cloudflare, python3-certbot-dns-route53, python3-certbot-dns-digitalocean, or the RFC2136 plugin for self-hosted BIND, then run certbot certonly --dns-<provider> with an API credentials file. The validation happens through a DNS TXT record, so the server never needs an inbound port. The rest of the vhost setup is identical.
Run the i-doit setup wizard
Open https://idoit.example.com/ and the installer takes over. The first page is a system check that validates PHP, every required extension, the ini settings from earlier, and mod_rewrite. With the config above, everything shows OK. You will see one orange note on Ubuntu 24.04: i-doit prefers PHP 8.4 and says so, but 8.3 is fully supported and the check passes.
Step 2 asks where uploaded files and object images should live; the suggested paths inside the install directory are fine. Step 3 is the database configuration, and it is the page where the root password from earlier gets used:
The wizard uses the root connection once, to create two databases and a dedicated idoit database user that the application runs as afterwards:
| Field | What to enter |
|---|---|
| Host / Port | 127.0.0.1 and 3306, the defaults |
| Username (root) / Password | root and the password you set with ALTER USER |
| MySQL user settings | idoit plus a new password; the wizard creates this user |
| System Database Name | idoit_system, framework-internal data |
| Mandator Database Name | idoit_data, your actual CMDB objects |
| Mandator title | Your organization name, shown in the top bar |
Step 4 sets credentials for the Admin Center, a separate maintenance interface for tenants, licenses, and updates. Set a password here rather than leaving it blank. Step 5 re-checks everything, and step 6 performs the installation. Each task should report OK:
The final task spells out the initial credentials: username admin, password admin. Click Next and the login screen confirms the installed release in its corner:
First login and your first objects
Log in as admin/admin and change that password immediately in the user menu; every scanner on the internet knows i-doit’s default. The landing dashboard shows a news feed, your recent changes, and the full object-type tree down the left side. To document a machine, go to Infrastructure, pick the Server object type, hit New, give it a title, and Save. We added three this way (web01, db01, k8s-node01) and they show up in the tree counts and the last-changed widget right away:
Every object gets an overview page plus dozens of attribute categories: CPU, drives, host addresses, contracts, backup assignments, cabling. This per-object depth is what separates a CMDB from an asset spreadsheet, and it pairs naturally with a dedicated IPAM like NetBox for the network side:
A quick terminal pass confirms the whole stack is healthy, and the console utility reports the installed release:
What changes on Ubuntu 26.04
We ran the identical procedure on Ubuntu 26.04 to map the differences. There are three, and only one requires a decision.
Error: “Package ‘php-opcache’ has no installation candidate”
Ubuntu 26.04 dropped the php-opcache meta package because OPcache now ships inside the base PHP packages. Remove it from the apt install line and continue; php -m still lists Zend OPcache afterwards, so nothing is actually missing.
PHP 8.5 is newer than i-doit officially supports
Ubuntu 26.04 ships PHP 8.5, above the current i-doit maximum of 8.4.99. The setup’s system check flags it in plain words: “You are about to install i-doit with a PHP version that is currently not officially supported.” It warns rather than blocks. We completed a full installation on PHP 8.5.4 and the application ran normally in our testing, but an unsupported interpreter is a risk you carry into every future i-doit update. For a production CMDB, either run it on Ubuntu 24.04’s PHP 8.3 or wait until the requirements page lists 8.5.
The third difference is cosmetic by comparison: 26.04 pairs MariaDB 11.8 with the newer PHP, and 11.8 is on i-doit’s supported list, so the database side needs no changes at all. Same tuning file, same root password step, with only the FPM unit name (php8.5-fpm) and ini path (/etc/php/8.5/) shifting.
Install from the terminal instead of the wizard
Automating the deployment, or working on a box with no browser handy? i-doit ships a console installer that does everything the wizard does. It runs as the web server user and takes the same values as flags:
cd /var/www/html/i-doit
sudo -u www-data php console.php install -u root -p StrongDBPass2026 \
--host localhost -d idoit_system -U idoit -P IdoitDBPass2026 \
--admin-password AdminCenter2026 -nThat installs the framework and system database. A tenant (the mandator holding your actual CMDB data) is a second command:
sudo -u www-data php console.php tenant-create -u root -p StrongDBPass2026 \
-U idoit -P IdoitDBPass2026 -d idoit_data -t "Your Company" \
--login-user admin --login-password admin -nEach task echoes its status as it goes, ending with the users being written:
Check tenant exist with Your Company and DB idoit_data: does not exist OK
Add tenant Your Company: added with id 1 OK
Adding persons OK
Inserting persons to database: Users successfully added! OKThis is the path we used for the Ubuntu 26.04 test install, and the resulting instance served the login page identically to the wizard-built one.
Before it goes into production
A CMDB earns trust slowly and loses it in one bad restore, so close these gaps before the team starts entering real data:
- Replace the
admin/adminlogin on day one, and set distinct passwords for the Admin Center and theidoitdatabase user. - Set up the i-doit cron jobs for housekeeping tasks like report caching and notifications.
- Back up both databases (
idoit_systemandidoit_data) plus/var/www/html/i-doiton a schedule, and test a restore once before you need it. - Keep the instance off the public internet where possible; the DNS-01 certificate path above exists exactly for that layout.
From here the work is data modeling, not system administration: define your object types, agree on naming, and start documenting the infrastructure one rack at a time.
