Installing GLPI on Ubuntu with Apache: when a bare-metal or VM install fits
A production Apache install of GLPI on Ubuntu means a VM or server your team controls, PHP and its extensions sized for the GLPI release you plan to run, a MariaDB or MySQL database that is not shared with other applications, an Apache virtual host whose document root points at GLPI's public directory, and cron jobs that run GLPI's maintenance tasks. Choose this layout when your team already runs Ubuntu servers, wants direct control over PHP and Apache configuration, and expects to manage patching and backups with the same tools it uses for other services. GLPI describes itself in its README as an open-source IT service management platform covering tickets, assets, CMDB, contracts, financial management and data center infrastructure, distributed under the GNU General Public License version 3. That breadth means the install will eventually hold service records, asset history and contract data, so the server design matters from day one.
The Docker image is the alternative worth comparing. It suits teams that already operate container hosts and want image-tag upgrades, while a bare-metal or VM install suits teams that want every file path, PHP setting and database grant visible on a host they administer directly. Confirm which PHP and database versions your target GLPI release requires before choosing the operating system package set, because the README and the installation docs list different minimums across releases. Also confirm which Ubuntu release your security team supports and whether its default PHP packages meet the GLPI requirement for that release.
Which install layout fits your team
This table compares three ways to lay out a GLPI install on Ubuntu: one server running Apache and MariaDB, a split layout with a separate database server, and the Docker-based install covered in the sibling topic. Read each row against your team's operating skills, and treat the upgrade row as the main takeaway, since it determines how much planning each layout needs before a version change.
| Layout | When it fits | Operational burden | What changes for upgrades |
|---|---|---|---|
| Single server, Apache and MariaDB | A small team with one or two administrators, a modest number of users and agents, and no separate database platform to run | Lowest. One host to patch, back up and monitor, but Apache, PHP and MariaDB all share its resources | Back up the database, files and config directory including glpi.key and glpicrypt.key, replace application files, then run php bin/console db:update on the same host |
| Split database server | Teams that already run a managed MariaDB service or need database capacity and backup controls separate from the web tier | Moderate. Two hosts, a network path to protect and a database account to manage, plus the same web tier tasks as a single server | Schedule the database backup and version check on the database host first, then update the web tier; the db:update step still runs from the GLPI application host |
| Docker with the official image | Teams that already operate container hosts and want image tags as the unit of change, with volumes for persistent data | Moderate. You maintain the image pull process, volume backups, compose configuration and host runtime, while Apache and PHP live inside the image | Upgrades move by image tag, but the same backups of the database, files and config keys still apply before changing the tag; confirm the image's update steps in the sibling topic |
| Version floor for all layouts | Confirm before choosing any layout: the README lists PHP 8.3 or later and MariaDB 10.11 or later, while the install docs list PHP 8.2 with MariaDB 10.6 for GLPI 11.0 | Check the target release's requirements against the Ubuntu packages you can get before the build starts | A version mismatch blocks the update path, so confirm the exact PHP and MariaDB versions for your target release with the official prerequisites page |
How to install GLPI on Ubuntu with Apache, step by step
This sequence takes a bare Ubuntu server to a GLPI instance where Apache serves only the public directory, the database is provisioned with timezone access, cron runs GLPI's scheduled tasks, and configuration, files and logs sit outside the web tree.
Install Apache and the PHP extensions
The systems administrator installs Apache, PHP and the extensions GLPI requires, then confirms the PHP version meets the release you plan to deploy. The GLPI prerequisites list PHP 8.3 or later for the current main branch and PHP 8.2 or later for GLPI 11.0, so check the version your target release documents before you install anything. Verify by running php -v and apache2ctl -v, then loading a test page through Apache to confirm PHP executes. Confirm the exact extension list against the prerequisites page for your release, since packaged names differ between Ubuntu versions.
Create the MariaDB database and user
The database administrator creates a dedicated database and an application user with privileges limited to that database, using a long generated password stored in your secrets manager. Pick a MariaDB version that matches the GLPI release notes: the README lists MariaDB 10.11 or later for the main branch, and the GLPI 11.0 docs list MariaDB 10.6. Verify by logging in as the new user from the application host and running a simple SELECT against the new database. The user should not have global privileges.
Grant timezone tables to the GLPI user
The database administrator loads the system timezone data into MariaDB and grants the GLPI user read access to the mysql timezone tables so that GLPI can handle time zones in its database queries. Without this, date handling for tickets, reminders and scheduled actions can be wrong. Verify by running a query such as SELECT CONVERT_TZ with a named zone as the GLPI user, and confirm it returns a value rather than NULL. Record the grant in your change log so it survives database rebuilds.
Deploy the GLPI application files
The administrator downloads the release archive from the official GLPI releases page, checks it against the published checksum, and extracts it to a location outside the web root, such as /opt/glpi. Set ownership so the web server user can read the code and write only to the directories GLPI needs to write. Verify by listing the extracted tree and confirming that the public directory exists and that the web server user cannot write to the application code itself.
Point the Apache virtual host at the public directory
The web administrator creates a virtual host whose DocumentRoot is the public directory inside the GLPI installation, not the installation root, and enables URL rewriting so that requests route through index.php. Enable the rewrite module and set AllowOverride or equivalent rules as the documentation describes for your Apache version. Verify by requesting the GLPI login page through the virtual host, then requesting a known path outside public such as /config or /inc, and confirming Apache returns a 403 or 404 rather than file contents.
Run the GLPI installer and complete the database setup
The administrator opens the GLPI web installer in a browser over HTTPS and connects it to the database created earlier, then lets the installer create the schema and set the default administrator passwords, which must be changed immediately. The installer writes the encryption keys glpi.key and glpicrypt.key, and these must be backed up before anything else changes. Verify by signing in with the new administrator account and checking that the installer's own status page reports no blocking errors.
Configure cron for GLPI scheduled tasks
The administrator creates a system cron entry for the web server user that runs the GLPI cron script at a fixed interval, so automatic actions such as notifications and inventory cleanup run without a browser visit. Confirm the interval against the GLPI operations documentation for your release. Verify by checking the automatic actions page in GLPI to confirm the last run time updates, and by reviewing the system log for errors from the cron job.
Move files, config and logs out of the web tree
The administrator relocates the files directory, configuration, log directory and marketplace to paths outside the source tree and points GLPI at them using its downstream and local definition files. Set restrictive permissions so only the web server user can read the config directory, and keep glpi.key and glpicrypt.key in a protected location with an offline backup copy. Verify by confirming that a fresh request to the web server cannot reach the config, files or logs paths, that GLPI still loads after a restart of Apache, and that backups of the database, files and config directory have been taken and restored successfully in a test.
Why the Apache document root must point to the public directory
The GLPI install docs require the Apache document root to point at GLPI's public directory, not the installation root, and to route requests through index.php with URL rewriting enabled. The reason is exposure: the installation root holds PHP source, library code, templates, vendor dependencies and the configuration directory. If Apache serves that root, a browser can request files that were never meant to be reached directly, and the attack surface grows with every file a future release adds. Pointing the virtual host at public means only the entry point and the assets it needs are addressable, and everything else is reached through the application's own routing.
On Ubuntu, the virtual host is a conceptual decision you make before the first browser test. Its DocumentRoot is the public path inside the GLPI source tree, its ServerName matches the name users will type, and a Directory block for that path allows the rewrite rules to be applied with AllowOverride or equivalent settings so GLPI's routing works. Confirm the exact directives against the GLPI installation documentation for your GLPI version, since the layout and the rewrite handling have changed between major releases. Keep the mod_rewrite module enabled and the site enabled before testing, and record which virtual host file holds the GLPI configuration so an upgrade does not leave a stale default site active.
Verify the result with requests, not assumptions. From a host that can reach the server, request the login page through the virtual host name and confirm it loads, then request paths that sit above public, such as a known PHP file in src or the config directory, and confirm they return a 403 or 404 rather than file contents. Repeat the check for any path an earlier install left behind, and check that a request for a nonexistent route is handled by GLPI rather than exposing a directory listing. Record these results with the date and GLPI version, because an auditor or your own change process will ask for the same proof after the next upgrade.
Security settings to decide before go-live
A GLPI install is only as safe as the choices made during setup. The items below are the settings to decide before users sign in, because each one is hard to correct cleanly after data has been entered. For the full hardening checklist, read the GLPI security hardening hub.
HTTPS and session cookie settings
Serve GLPI only over HTTPS on the Apache virtual host, and confirm that session cookies are marked secure and HTTP-only so they are not sent over plain HTTP or read by scripts. Decide the certificate source and renewal process before go-live, not after. Check the cookie behavior in a browser after setup, since a proxy or load balancer in front can change how the scheme is seen by the application.
Config and files outside the web tree
Only the public directory should be reachable from the web server. Keep the configuration directory, the files directory for uploads and documents, and the logs outside the document root so that a misrouted request cannot download them. Decide these paths during the install, because moving them later means editing configuration and re-testing uploads and attachments.
File permissions for the web user
Give the Apache user write access only to the directories GLPI must write to, such as the files and logs locations, and keep application code owned by a separate account that the web server cannot modify. Read access should be limited to what PHP needs. Test uploads, plugin installation and the marketplace after setting permissions, since an overly strict setup breaks updates and an overly loose one lets a compromised request change code.
Protecting glpi.key and glpicrypt.key in backups
The keys GLPI uses to encrypt stored secrets are needed to read those secrets after a restore, so a database backup without them can be unusable and a backup with them is sensitive. Store the key files in a separate, access-controlled location, encrypt backup copies, and rehearse a restore that includes the keys. Record who holds the keys and how they rotate, because a lost key can leave stored credentials unreadable.
Restricting administrator access
Decide who can reach the administrative interface and from which networks before publishing the site. Limit administrator accounts to named people, separate them from day-to-day user accounts, and plan how authentication for administrators will work, including any second factor. Use the web server or network controls to limit access to the admin paths where your environment allows it.
Keeping the database off the public network
The MariaDB or MySQL server should accept connections only from the GLPI application host, and it should not be reachable from the internet or from user networks. Create a database account with only the privileges GLPI needs, and confirm the bind address and firewall rules after installation. Check this during the install, because a database listening on all interfaces is a common and avoidable exposure.
Questions teams ask before installing GLPI on Ubuntu
What drives the effort of installing GLPI on Ubuntu with Apache?
The effort depends mainly on how many environments you need, how many users and agents will connect, and how much integration work sits around the core install. A single production instance with a standard LAMP-style stack is the simplest case. Effort rises when you add a separate database server, TLS termination, SSO through an external identity provider, mail and LDAP connections, agent deployment at scale, and a staging copy for testing upgrades. Each of these adds configuration, testing and documentation work that is separate from the install itself.
Can an in-house team install GLPI on Ubuntu without a partner?
Yes, if the team already runs Linux servers, Apache, PHP and MariaDB and can keep those components patched. The GLPI installation docs describe the steps in enough detail for an experienced administrator to follow. The gaps usually appear in less familiar areas: moving the public directory into the web root correctly, keeping the config and files directories outside the source tree, scheduling cron, and recording the encryption keys so backups can be restored. Ask whether the team has someone who has run a PHP application through a major version upgrade before.
How long does a GLPI installation on Ubuntu take?
No duration has been fixed for this work, so confirm it against your own scope. The time depends on the number of servers, whether the database is shared, how many authentication sources you connect, and how many review cycles the security team requires before go-live. Ask any provider for a written timeline tied to a defined scope, with each environment, integration and handover listed separately. Ask also what happens if a dependency, such as a DNS record or certificate, arrives late.
What must our team provide before the installation starts?
Plan to supply the following before work begins:
- One or more Ubuntu servers, or virtual machines, in your own infrastructure with the network paths you require
- A DNS name for the GLPI instance and any internal name used for the database
- A TLS certificate issued by your certificate authority, with the private key handled under your policy
- Database credentials and a network path from the web server to MariaDB, including grant permissions for the GLPI database user
- Access to the mail relay, LDAP directory or identity provider if these are in scope
- Named approvers for the security review and the change window
How do GLPI upgrades differ from the first installation?
An upgrade works on existing data, so the risk moves from setup to preservation. The GLPI update procedure requires a backup of the database, the files and the config directory, including the glpi.key and glpicrypt.key files, before you replace the application files and run php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Plan for a staging copy, a tested rollback path and a check of each plugin's compatibility with the target release before you touch production.
Which GLPI release should we install, and what does the vendor publish about licensing?
Choose the release based on your plugin list, PHP and database versions, and support needs. The GLPI README lists PHP 8.3 or later and MariaDB 10.11 or later for the current main branch, while the installation docs list PHP 8.2 or later with MariaDB 10.6 for GLPI 11.0, so confirm the exact requirements for the version you select. GLPI is distributed under the GNU General Public License version 3. Teclib publishes self-hosted GLPI Network subscriptions starting at 100 euros per month (Basic, up to 10 agents and 500 assets), which is the vendor's published figure and is separate from the software license and from any services work.
When should we bring in a partner for a GLPI installation?
Bring in a partner when the install carries compliance evidence, identity integration, or a tight deadline that your team cannot absorb. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, but it can prepare systems and evidence for an independent assessment. Ask for a written scope before comparing any quote.
Limits to confirm in your own environment
The steps in this install depend on versions and defaults that change between GLPI releases and operating system images. Confirm each item below against the vendor documentation or in a test build before you fix the design, because a mismatch found in staging costs far less than one found after cutover.
PHP extension list for your release
The required PHP version and extension set differ between GLPI 11.0 and the newer README requirements, so the apt install line you copy from any guide may be incomplete or stale. Confirm the minimum PHP version and the full extension list against the prerequisites page for the exact GLPI release you will deploy, then run GLPI's own requirements check on the test server and resolve every warning before you move on.
Ubuntu and Apache builds in your catalog
The Ubuntu release, its default PHP package, and the Apache build your organization approves may not match the versions used in public examples. Confirm which Ubuntu LTS release your image catalog supports, which PHP version its repositories provide, and whether the Apache packages carry the modules you need for URL rewriting and TLS. Record the results so the vhost and PHP settings are tested against the same stack you will patch in production.
MariaDB version against release notes
GLPI publishes a minimum MariaDB version for each major release, and the README and installation docs do not always agree on the floor. Check the MariaDB version your Ubuntu repositories or approved channel provide against the requirements for your chosen GLPI release. Also confirm the sql_mode and character set expectations in the install guide, because a database version that installs cleanly can still fail during the setup wizard.
Plugin status after the GLPI 11 change
Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Confirm which plugins you depend on have releases that support your target GLPI version, and test reactivation in a copy of the database before the production change window. Plan for plugins that have no compatible release, since those will stay suspended until you replace or remove them.
Cron and timezone against your policy
The install steps for the GLPI cron job and the MariaDB timezone grants both need decisions about the service account, the file permissions on the cron entry, and whether your database team allows timezone tables to be loaded. Confirm with your security team which user runs the cron job, where its output goes, and how grants are reviewed. Verify that scheduled tasks run after the first install, because a silent cron failure can hide notification and cleanup work.
How DeployOpen plans and delivers a GLPI install
DeployOpen plans and builds self-hosted GLPI inside infrastructure you control, including the Ubuntu host, Apache virtual host, MariaDB, cron and data directories. Engagements start with a written scope that fixes what is built, tested and handed over before any work begins.
How we scope
- Confirm the target GLPI release and PHP and MariaDB versions against the current installation prerequisites before choosing the Ubuntu release.
- Record the Apache virtual host layout, with the document root on the public directory and URL rewriting for index.php.
- Agree in writing where the config, files and log directories will live outside the web tree, and who owns each path.
How we build
- Install PHP extensions, MariaDB and Apache on hosts you provide, with each package version recorded in the build notes.
- Load timezone data into MariaDB and set the grants the GLPI installer needs, then verify that the database user has only the rights it requires.
- Configure the system cron job for GLPI and test that scheduled tasks run under the Apache service account with correct file permissions.
How we hand over
- Run a documented verification pass covering login, the web server routing, cron execution and file permissions on the relocated directories.
- Deliver a runbook with the install steps, configuration locations, the key files to back up such as glpi.key and glpicrypt.key, and the update procedure.
- Walk your operations team through the setup and record open items, such as TLS certificate renewal, for your own owners to confirm.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the install.
- Ask for a quote built from the written scope, which states the work, the deliverables and the systems you must provide.
