How to Increase the phpMyAdmin Session Timeout

phpMyAdmin logs you out after 24 idle minutes, which is exactly long enough to lose your place in the middle of a slow import. This DevAnswers guide raises the session timeout properly: the two settings that control it, the persistent way to set them on Ubuntu and Debian, and the security trade-off you accept.

Quick Answer: Raise Both Timeout Values Together #

Set $cfg['LoginCookieValidity'] = 14400; in /etc/phpmyadmin/conf.d/timeout.php and session.gc_maxlifetime = 14400 in the php.ini of the SAPI serving phpMyAdmin, then restart PHP-FPM or Apache. Both values, or the change won’t hold; 14400 seconds is four hours. The sections below walk each step and the trade-offs. If you have not set up the panel yet, follow the guide to install and secure phpMyAdmin on Ubuntu first.

What Controls the phpMyAdmin Session Timeout #

In cookie authentication mode, the default on Ubuntu and Debian packages, phpMyAdmin issues a login cookie whose lifetime is set by $cfg['LoginCookieValidity']. The default value is 1440 seconds. That’s 24 idle minutes, and then you’re back at the login screen.

Raising that one value isn’t enough, though. PHP’s session garbage collection runs on the same clock: session.gc_maxlifetime treats session data as garbage after (by default) the same 1440 seconds, and once the server-side session is gone your login cookie points at nothing. phpMyAdmin’s own documentation says to set session.gc_maxlifetime at least as high as LoginCookieValidity. Raise the two values together, or the change simply won’t hold.

Raise LoginCookieValidity with a conf.d Drop-In #

On Ubuntu and Debian the package keeps phpMyAdmin’s configuration at /etc/phpmyadmin/config.inc.php, but editing that file directly is the wrong move: the package owns it, and an upgrade can overwrite your change. The packaging convention is a drop-in. Every file ending in .php inside /etc/phpmyadmin/conf.d/ is loaded automatically, so create one:

sudo nano /etc/phpmyadmin/conf.d/timeout.php

Add both lines:

<?php
$cfg['LoginCookieValidity'] = 14400;

Save and exit (press CTRL + X, press Y, then press ENTER)

14400 seconds is four hours, a sensible ceiling for a working session; the security section below explains why bigger values are a bad idea. If you installed phpMyAdmin from source rather than apt, there is no conf.d directory: set the same line in config.inc.php in phpMyAdmin’s top-level directory instead.

Raise session.gc_maxlifetime to Match #

Now the PHP side. Which php.ini to edit depends on how phpMyAdmin is served: Apache with mod_php reads /etc/php/8.3/apache2/php.ini, while PHP-FPM reads /etc/php/8.3/fpm/php.ini (swap 8.3 for your version; note php -v reports the CLI’s version, and on Ubuntu 26.04 the default is PHP 8.5, so the paths start /etc/php/8.5/). If you’re not sure which file your setup loads, see how to find and edit the right php.ini.

sudo nano /etc/php/8.3/fpm/php.ini

Find the session.gc_maxlifetime line and set it to the same number:

session.gc_maxlifetime = 14400

Save and exit (press CTRL + X, press Y, then press ENTER)

One Debian/Ubuntu-specific trap: skip the FPM pool-file override (php_admin_value[session.gc_maxlifetime] in www.conf) for this particular setting. These distros clean up sessions with a scheduled system job that reads the main php.ini files, so a pool-level value is invisible to the cleaner that actually deletes session files, and your sessions would still die on the old 24-minute clock. Edit the SAPI’s php.ini as shown above. Either way, treat the value as a minimum lifetime rather than a stopwatch: cleanup runs periodically, not at the exact configured second.

Apply the Change and Verify It #

PHP-FPM only picks up php.ini and pool changes on a restart or reload, so apply it now:

sudo systemctl restart php8.3-fpm

The service name carries the PHP version, so match it to yours (php8.1-fpm, php8.4-fpm, and so on). Under Apache with mod_php, restart Apache instead:

sudo systemctl restart apache2

Confirm the value landed, pointing the path at the file you edited (FPM shown; use the apache2 path under mod_php):

grep 'session.gc_maxlifetime' /etc/php/8.3/fpm/php.ini

session.gc_maxlifetime = 14400

Then the behavioural check: log into phpMyAdmin and stay idle past the old 24-minute mark; the session should survive. If the login page previously warned that your session.gc_maxlifetime is lower than the cookie validity configured in phpMyAdmin, that warning is gone too.

Keep Production Timeouts Modest #

The short default exists for a reason. A phpMyAdmin session is a logged-in database superuser sitting in a browser tab. Anyone who steals the session token, or simply sits down at an unattended machine, can act with that user’s full privileges for as long as the session remains valid, with no password prompt in the way. The timeout is the blast-radius limit on that scenario.

Four hours covers almost any real import or editing session. Values measured in days belong only on a local development VM that nothing else can reach. And since a longer-lived cookie spends more time being worth stealing, make sure the panel is only reachable over TLS: force phpMyAdmin to use HTTPS if you haven’t already.

Troubleshooting: The Change Does Not Stick #

The classic trap is phpMyAdmin’s own Settings screen. phpMyAdmin has several configuration layers: config.inc.php holds the global, system-wide settings, while anything you change in the web interface is a user-level preference kept in phpMyAdmin’s configuration storage, or just in your session or browser when that storage isn’t set up. A timeout raised there looks like it worked, then quietly resets. Persistent, server-wide changes belong in the server-side config, which on Ubuntu and Debian means your conf.d drop-in.

• Wrong php.ini. The CLI, Apache, and FPM each read their own file under /etc/php/8.3/. Edit the one for the SAPI that actually serves phpMyAdmin.
• No restart. PHP-FPM applies configuration at startup; until you restart the service, the old value is live.
• Drop-in ignored. Files in /etc/phpmyadmin/conf.d/ only load if they end in .php.
• Login breaks outright. If phpMyAdmin now refuses to log you in with a session-cookie error, that’s a different fault with its own fixes: see fixing the “failed to set session cookie” error.

Next Steps #

Your session now outlives the import instead of dying underneath it. Since the panel is worth attacking, keep it current as well: when the packaged version lags a security release, you can manually upgrade phpMyAdmin without waiting for the repo.