GLPI behind Nginx and PHP-FPM

Why GLPI behind Nginx and PHP-FPM needs a deliberate layout

Getting the web layout right is the first thing to settle when GLPI runs on Linux with Nginx and PHP-FPM, because every request from every user passes through that layout before the application sees it. The short answer is that the document root must point to GLPI's public directory, not the installation root, and every request that is not a real file must be routed through index.php. The GLPI installation documentation sets this as a requirement for Apache, Nginx, lighttpd and IIS alike, so it is not a tuning choice you can defer until after users log in.

The reason it matters is exposure. If the document root sits at the installation root, configuration, library and data paths can be reachable over HTTP, and the server block then has to block them one by one. Pointing the root at public keeps those directories out of the web tree by design, while the rewrite rule sends clean URLs to index.php. Session cookie flags, HTTPS redirects and the PHP-FPM socket settings all sit in the same server block, so they should be reviewed together. Confirm the exact rewrite and location rules against the version of the installation documentation you deploy, since the rules change with the release.

Scope this work explicitly in three cases: a new install, a move from an existing Apache virtual host, and a hardening review of an instance that was set up by hand. The stack context matters here too. The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation documentation for GLPI 11.0 lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, so check which set applies to your target release before choosing PHP-FPM and database packages.

Nginx layout choices and when each fits

This table compares the main Nginx layout decisions for GLPI: a dedicated server block, a subdirectory alias, TLS at Nginx or at a load balancer, and how the HTTPS scheme reaches PHP. Read each row as a choice you make once, with the trade-off you accept. The main takeaway is that the document root decision and the TLS termination point should be settled before the first production user signs in.

Decision	Option	Trade-off	When it fits
Server block layout	Dedicated server name with root on the public directory	Matches GLPI's documented layout, keeps the source tree out of the served path and simplifies rewrite rules	GLPI has its own hostname and this is the default choice for a new install
Server block layout	Subdirectory alias under an existing site	Shares a hostname with other applications, but routing and file exposure are easier to get wrong	Only when a shared hostname is a hard requirement and the team has tested that no other path leaks files
TLS termination	Nginx terminates TLS on the GLPI host	One place to manage certificates and to set the forwarded scheme, but Nginx holds the private key	Single-server installs or environments where Nginx is already the certificate boundary
TLS termination	Load balancer terminates TLS in front of Nginx	Centralized certificate handling, but Nginx must trust forwarded headers from that balancer only	Multiple GLPI front ends behind a shared balancer, provided the balancer address is fixed and trusted
HTTPS scheme to PHP	Nginx sets the HTTPS value for FastCGI itself	Session cookie and redirect logic see the real scheme, and the setting is local to the server	Nginx terminates TLS directly
HTTPS scheme to PHP	Scheme passed from a forwarded header	Works behind a balancer, but a spoofed header from an untrusted client changes what PHP believes	Balancer termination, and only after the trusted proxy range is restricted
Session cookie flags	Secure flag set because the site is served only over HTTPS	Cookies are never sent over plain HTTP, but a plain HTTP test host will appear to lose sessions	Production hosts that never serve GLPI over HTTP
Access to non-public paths	Explicit deny for paths outside the public directory	Blocks direct requests to configuration, files and plugin code, but each new path needs review after upgrades	Any layout where the web root is not the installation root
Verification	Test each option on a staging host with the same rules	Adds effort before go-live, but shows which redirects and cookies break under the chosen scheme	Before any layout change reaches production users

Configuring the Nginx server block for GLPI step by step

This sequence takes a fresh Linux host from a PHP-FPM install to a GLPI server block that serves only the public directory, hands unmatched requests to index.php and sends session cookies with the flags HTTPS requires. Each step ends with a check you can run before moving on.

Install PHP-FPM at the supported version
Your systems administrator installs Nginx and a PHP-FPM pool that matches the PHP version your GLPI release requires. The GLPI README on the main branch lists PHP 8.3 or later, while the installation docs list PHP 8.2 or later for GLPI 11.0, so confirm the version against the release you are deploying before you install. Enable the PHP extensions GLPI reports as missing during its own requirements check. The step is done when php -v reports the expected version and systemctl status php-fpm (the service name varies by distribution) shows the pool running and listening on its socket.
Point the root at the public directory
Create the server block and set the root directive to the public subdirectory of the GLPI installation, not the installation root. The GLPI installation docs require this for Nginx, Apache, lighttpd and IIS, because the installation root holds configuration, source code and files that must never be served directly. Keep the server_name and listening configuration for your environment, and load the file with nginx -t before reloading. The step is done when nginx -t passes and a request for / returns the GLPI login page, not a directory listing or raw source.
Route unmatched requests to index.php
Add a location / block with a try_files rule that sends any request that does not match a real file to /index.php with the original query string. GLPI's front controller then handles routing for pages such as the ticket and asset views, so these URLs work without a file for each page. Test the rule after reloading Nginx by requesting a deep GLPI URL that has no matching file on disk. The step is done when that URL returns the GLPI page through the front controller and the access log shows the request handled by index.php.
Restrict PHP execution to the front controller
Add a location block that matches PHP files and passes only index.php to PHP-FPM, then deny every other .php path with a 404 or 403. This limits the PHP attack surface to the one entry point GLPI needs, and it stops requests to bundled scripts, plugin files or uploaded content from executing. Also deny access to hidden files and to any directory that holds configuration, logs or files, as GLPI's installation docs describe for paths outside the public directory. The step is done when a request to a non-public path such as a config or log file returns a denial, and a request to another .php file in the tree returns the same denial.
Configure the FastCGI socket and parameters
Inside the PHP location block, set fastcgi_pass to the socket your PHP-FPM pool listens on, and include the standard FastCGI parameters file so SCRIPT_FILENAME points to the resolved index.php path. Confirm that the socket path matches the listen directive in the pool configuration and that the Nginx worker user can read and write the socket. Set fastcgi_read_timeout to a value your team chooses for long reports and imports, and confirm that value with your own workload testing, since no figure is supplied here. The step is done when a GLPI login page loads through PHP-FPM and the PHP-FPM log shows no socket or permission errors.
Set session cookie flags for HTTPS
Configure the session cookie settings so GLPI sends its session cookies with the Secure and HttpOnly attributes once the site is served over HTTPS. Set the matching PHP session options in the PHP-FPM pool (for example session.cookie_secure and session.cookie_httponly) and confirm that GLPI's own session handling does not override them, since the settings for GLPI version you run should be checked in its documentation. Make sure the site redirects plain HTTP to HTTPS so no session cookie is issued over an unencrypted connection. The step is done when a browser login response shows the session cookie with both Secure and HttpOnly set, which you can check in the browser developer tools or with curl -I against the login page.
Verify the complete server block
Run a final check from outside the server, not from the server itself, to confirm the whole configuration behaves as designed. Request the login page over HTTPS, request a file under the installation root, request a config or log path, and request a PHP file that is not index.php, and record the status code for each. Confirm the login cookies carry the flags set in the previous step and that the server header does not disclose more than your policy allows. Keep the results with your change record, since they become evidence for your hardening review. The step is done when every non-public path is denied, the login page loads, and the cookie check passes on the production hostname.

Which paths to block and why GLPI exposes them

GLPI keeps its source, configuration, uploaded files, logs and plugins under one installation root, but only the public directory should answer web requests. Each card below covers one class of path that Nginx must refuse, the reason GLPI makes it sensitive, and how to test the block from outside the server.

Configuration and key directories

The config directory holds database connection settings and the encryption keys GLPI uses for stored secrets. If Nginx serves it, a single request can expose credentials that unlock the database and every encrypted field. Confirm that a request for a config file path returns a refusal, not file contents, and that the server never falls back to a static file lookup for those locations.

Uploaded files directory

The files directory stores ticket attachments, documents and other user uploads. These files are served by GLPI itself after an authorization check, so a direct web path would bypass the access rules of the ticket or asset they belong to. Request a known upload path without a session and confirm the server refuses it rather than returning the file.

Other PHP files outside index.php

GLPI routes its web traffic through the front controller, so a request that names another PHP file, such as a setup or utility script, should not run it. Nginx should pass only index.php to PHP-FPM and return a not-found or refusal for any other .php path. Test this with a request to a script that exists in the source tree and confirm no PHP output appears.

Log and marketplace paths

Log files can record user names, request details and errors, and the marketplace directory holds downloaded plugin code. Neither should be readable through the web server, and plugin code should not be executable from a URL. Check that requests to log file names and marketplace paths fail, and review the Nginx access log for any successful hits on those paths after the change.

Dotfiles and backup copies

Editors and deployment tools often leave backup copies such as config_db.php.bak or .env style files beside the application, and version control leaves a .git directory. These files are plain text and are easy to request by guessing a name. Add a rule that refuses hidden files and common backup extensions across the whole site, then confirm each guessed name returns a refusal from both inside and outside the network.

Session cookie settings for HTTPS by deployment situation

Nginx terminates TLS on the same host that runs PHP-FPM, so the browser connects over HTTPS and the request reaches index.php through a local FastCGI socket. PHP sees the request as plain HTTP unless the Nginx configuration tells it otherwise. GLPI's session cookie behavior depends on what PHP believes about the connection, so this gap is where cookie problems start.

Pass the scheme to PHP: Set fastcgi_param HTTPS on; in the PHP location block so PHP-FPM receives the original scheme.
Secure flag: When PHP knows the request is HTTPS, session.cookie_secure can mark the session cookie as Secure. Check the effective value on a non-production host with php-fpm -i, then remove any diagnostic page.
SameSite value: Set session.cookie_samesite on purpose. Lax suits normal navigation. Confirm what GLPI already sends before overriding it, because a stricter value can break redirects that return from an external identity provider.
Redirect placement: Handle the HTTP to HTTPS redirect in the port 80 server block, not inside the PHP location, to avoid redirect loops.

Before go-live, sign in, load several pages, and use browser developer tools to confirm that the session cookie carries Secure and the expected SameSite value, and that the browser returns it on the next request.

TLS ends at a reverse proxy or load balancer, and the Nginx or Apache origin behind it receives plain HTTP. The browser sees HTTPS, but the origin sees HTTP unless the edge passes its scheme along. Without that signal, cookies can lack Secure, and GLPI can generate http:// links that the browser refuses to load from an HTTPS page.

Forward the scheme: Have the edge send X-Forwarded-Proto, then map it in the origin Nginx with fastcgi_param HTTPS on; when the value is https.
Trust list: Accept forwarding headers only from the proxy or load balancer addresses. Anyone who reaches the origin directly could otherwise claim HTTPS.
Multiple front ends: Every node needs identical settings. If session storage is local to each node, users are logged out when a balancer moves them, so confirm the session and cache design with the platform team.
Health checks: Point the balancer at a simple status path and confirm with the team that the check does not create sessions or log noise in GLPI.

After setup, sign in through the public hostname, then inspect the Set-Cookie header in developer tools to verify Secure, SameSite and the domain attribute. Also confirm that every redirect and link after login uses the https:// address.

A lab without TLS is useful for testing installs, plugins and upgrades on a private network. Browsers treat plain HTTP differently from HTTPS, and a Secure cookie set over HTTP is discarded. The sign-in can appear to succeed, then the next page asks for credentials again, which often looks like a GLPI fault when it is a transport setting.

Leave Secure off: On an HTTP-only host, keep session.cookie_secure disabled, or the browser drops the session cookie.
Keep lab settings out of production: Store lab PHP and pool files apart from the production configuration repository so a shortcut does not reach a live system.
Use the production hostname: Where possible, test with the name you will use in production, so cookie domain and redirect behavior are checked early.
Plan the switch to HTTPS: Moving to HTTPS later changes cookie flags and generated URLs, so existing sessions end and users sign in again.
Limit exposure: Keep the lab on a private network. Plain HTTP can expose passwords and session tokens to anyone on the network path.

Before promoting the configuration, compare the cookie flags in developer tools with the production design, and confirm that the base URL GLPI uses after sign-in is the HTTPS address.

Security and operational considerations for the Nginx front end

The Nginx server block is the only layer between GLPI's users and the application, so it carries TLS, header, upload and logging decisions that affect every session. Each card below ties one of those decisions to a check your team can run before and after a change, and to the GLPI update procedure, which requires a backup of the database, files and config directory, including glpi.key and glpicrypt.key, before application files are replaced.

TLS and session cookie settings

Terminate HTTPS at Nginx with a current protocol and cipher policy agreed with your security team, then confirm GLPI's session cookies are marked secure so browsers never send them over plain HTTP. Check the setting after every Nginx or PHP upgrade, because a redirect rule that works for one hostname can silently drop the flag on another. Record the chosen policy in the same change set as the server block so auditors can trace it. Test the login flow end to end after each change, not just the certificate.

Forwarded headers and trusted proxies

If a load balancer or reverse proxy sits in front of Nginx, decide which client address and protocol headers Nginx trusts and set them explicitly, rather than passing through whatever a client sends. Wrong forwarding causes GLPI to see the wrong scheme or address, which affects redirects, login logic and audit trails. Keep the trusted proxy list short and documented. Confirm that the URL GLPI is configured to use matches the public hostname users actually type.

Upload size and timeout limits

Ticket attachments, document imports and inventory-related files all pass through Nginx before PHP sees them, so the client body size limit and the read and send timeouts must match what GLPI's PHP settings allow. A mismatch produces opaque errors that look like application faults. Set the limits deliberately, write down the reason for each value, and test a large attachment after changing either side. Ask your GLPI administrators which file types and sizes their helpdesk process requires.

PHP-FPM pool isolation

Run GLPI in its own PHP-FPM pool with a dedicated Linux user, so that its files, sessions and socket are not shared with other sites on the same host. Restrict that user's write access to the directories GLPI actually needs to write, and keep the config directory and key files outside the web tree and owned by a separate administrative account. Pool isolation limits the damage from a compromised plugin, and it makes per-pool process limits and logs easier to read.

Access logs without sensitive data

Nginx access and error logs record request paths, query strings and client addresses by default, and GLPI URLs can carry identifiers or search terms. Review the log format, remove or mask query parameters that hold personal or ticket content, and set retention that your data protection policy allows. Make sure log files are readable only by the operations group. Verify the setting by sending a test search and checking what was written.

Keeping the server block in version control

Store the Nginx server block, PHP-FPM pool file and certificate paths in a Git repository with reviewed changes and a named owner. During a GLPI update, the backup step should capture this configuration alongside the database, files and config directory, so a rollback restores the front end as well as the application. Pair each committed change with a note on which GLPI version it was tested against. Confirm with your change board whether server configuration needs its own approval step.

What teams ask before running GLPI behind Nginx

Can our internal team set up GLPI behind Nginx and PHP-FPM on its own?

Yes, if your team already runs Linux web servers, PHP applications and a MySQL or MariaDB database. The work is standard: a PHP-FPM pool, an Nginx server block whose document root is GLPI's public directory, and rules that send every request through index.php. The parts that usually take longer are the ones around the web server: confirming the PHP extensions and versions GLPI needs, placing configuration and file directories outside the web tree, and testing login, file uploads and scheduled tasks after each change. The GLPI installation docs list PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later for current releases, so check those against your build before you start. If nobody on the team has tuned PHP-FPM or written Nginx rules before, a partner can shorten the first pass, but the knowledge still needs to stay with your staff.

How long does a GLPI Nginx and PHP-FPM setup take, and what drives the effort?

The duration depends mainly on how many environments you need, how many hosts sit in front of GLPI, and how much hardening your security team requires. A single test server with one virtual host is a different job from a load-balanced production pair with separate file storage. The main effort drivers are the number of server blocks, whether TLS terminates on Nginx or on a load balancer, how many PHP-FPM pools you run, whether you add rate limiting or access restrictions for administrative paths, and how many rounds of testing your change process requires. We do not publish a duration here. Ask for a timeline in the written scope, with the environments, hosts and test cases listed so you can compare proposals on the same basis.

What access, certificates and test accounts do we need to provide?

Expect to supply a few specific things before work starts. You need a host or VM with root or sudo access for the web and PHP packages, the database server details and a dedicated database account, and a DNS name for the GLPI site. For HTTPS you need a certificate and private key that your organization is allowed to use, or a decision to issue one from your internal certificate authority. Provide at least one test user for each authentication method you plan to enable, such as a local account and a directory account, plus a sample administrator and an end-user profile. Agree on a change window and a rollback route so test changes can be reverted without touching production. Confirm with your network team which firewall rules and proxy paths apply, since these often delay work more than the configuration itself.

Is Apache required for GLPI, or can we use Nginx?

Apache is not required. The GLPI installation docs support Apache, Nginx, lighttpd and IIS, and the common requirement across all of them is the same: the web server's document root must point to GLPI's public directory rather than the installation root, with URL rewriting that routes requests through index.php. Choose Nginx if your platform team already standardizes on it, if you want PHP-FPM process control separate from the web server, or if the same proxy layer serves other applications. Choose Apache if your team has stronger experience with its module model or existing virtual host standards. Either choice works when the rewrite rules, the blocking of direct access to other paths and the session cookie settings are configured and tested.

Which cost components should we expect for a GLPI Nginx deployment?

The cost has three parts: the labor to build and test the web layer, the infrastructure that runs it, and any recurring support you choose to buy. Labor covers design, configuration, testing and documentation, and it is usually the largest one-time item. Infrastructure covers the server or virtual machine, storage, backups, and TLS certificates if you buy them. Recurring costs include patching PHP and Nginx, handling GLPI version updates, and monitoring. Software licensing is a separate question. GLPI is distributed under the GNU General Public License version 3, so the core application carries no license fee. If you want Teclib's commercial offering, the GLPI Network subscriptions page lists self-hosted plans from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), which is a different decision from the web layer itself.

What should we ask for in a fixed-scope quote for this work?

Ask for a written scope that names each deliverable, the environments covered and the acceptance tests. DeployOpen typically agrees scope, deliverables and timelines in writing before work starts, so the quote should reflect that document rather than a generic estimate. Ask the proposal to list the Nginx server blocks and PHP-FPM pools to be built, the rewrite and access rules, the directory placement, the TLS and session cookie settings, the authentication tests, the documentation handed over, and the items the client must provide. Ask what is excluded, such as load balancers, database work or upgrades, and what the change to a later GLPI release would cost. Also ask how post-go-live support is handled, either as a separate retainer or as a defined warranty period, and whether that period is written into the agreement.

What goes wrong most often with GLPI behind Nginx?

The most common failures are small configuration gaps that look like application bugs. Typical examples include a document root that still points at the installation root, which exposes files that should stay private, missing rewrite rules that break links and API calls, PHP-FPM settings such as upload size or execution time that are lower than GLPI needs, and cookies set without the secure flag after HTTPS is enabled. Teams also forget to check the logs after a GLPI update, because the update procedure requires backing up the database, files and config directory, including glpi.key and glpicrypt.key, then running php bin/console db:update. Plugins are suspended after a new version is detected in GLPI 11.0 and later, so test that path as part of the web layer rollout, not after go-live.

Does the Nginx layer need to change when we upgrade GLPI?

Often it does not, but you should check each upgrade rather than assume. The web layer depends on the PHP version, the required PHP extensions and the rewrite behavior of the release you move to. GLPI 12.0.0 was released on October 7, 2026, and the GLPI installation docs and release notes should be checked for changed requirements before you schedule the upgrade. Keep your Nginx and PHP-FPM configuration in version control so you can compare it against the new release notes and roll back quickly if a rule needs to change. Confirm with the vendor documentation which PHP versions the target release supports before you upgrade PHP itself.

How DeployOpen scopes and delivers a GLPI web layer

DeployOpen treats the Nginx and PHP-FPM layer for GLPI as a written, fixed-scope piece of infrastructure work, planned alongside the database, storage and identity choices around it. We build it inside your own cloud accounts, data centers or air-gapped networks, then document and test it so your team can run it after handover.

How we scope

Confirm the GLPI release line and PHP version your instance will run before any server configuration is written
Map every public hostname, TLS termination point and load balancer that will sit in front of the public directory
Record the agreed deliverables, test cases and timelines in writing before work starts, since engagements are fixed-scope

How we build

Configure the Nginx server block so every request routes through public/index.php and nothing else is served directly
Tune the PHP-FPM pool, socket permissions and upload limits to match the PHP version and GLPI release you selected
Set session cookie flags for HTTPS and check the result against the hardening settings GLPI expects in your environment

How we hand over

Deliver versioned Nginx and PHP-FPM configuration with a written rationale for each directive and each blocked path
Provide test evidence showing that non-public paths return refusals and that sessions carry the agreed cookie attributes
Document the update steps, including how the web layer changes when you move to a new GLPI release during an upgrade

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover is complete
Re-check the web layer when GLPI, PHP or Nginx versions change, using the same test cases agreed at handover
Ask any provider, including DeployOpen, to confirm the current GLPI and PHP support matrix in writing before you commit