I’m considering using HestiaCP for an upcoming project and I’d like to clarify a few things before moving forward.
First, I wanted to ask about the project’s update cycle. From what I could see, the last release was around half a year ago. Is HestiaCP still actively maintained and expected to receive updates in the near future?
Second, with the current version of Hestia, is it possible to use PHP 8.5 ?
My plan is to run Nginx + PHP-FPM. I understand from the documentation how Nginx templates work and how they’re selected per domain in the panel. However, I was wondering if there’s a way to add additional Nginx configuration without having to SSH into the server every time.
For example, with PHP-FPM we have .user.ini. Is there an equivalent approach for Nginx, such as including a per-domain file like .extra.conf located in public_html or the domain directory, that can be managed without touching the main templates via terminal?
If you could point me in the right direction or share best practices for this setup, I’d really appreciate it.
There is no fixed update cycle, when a new version is ready, it is released.
Yes.
Not directly. It’s easy to add, but it will be available in the next Hestia release, which should happen next week (I hope so ).
No, there isn’t such a feature. You can add nginx.conf_* and nginx.ssl.conf_* files in /home/user/conf/web/domain/ to include extra configuration without modifying the template, but this is not possible for normal users or via the Web UI.
I’ve already done some testing on my side, especially with .user.ini. While it works fine for basic PHP settings, I noticed that many directives are simply ignored, for example some Xdebug options, OPcache settings, and a few other runtime-related configurations.
I can confirm that using nginx.conf_* and nginx.ssl.conf_* files works well and seems like a clean, update-safe way to add extra Nginx configuration without touching the main templates.
Keep in mind that modifications in .user.ini files have a limited scope. They will only work if the option is set to one of these modes: INI_USER, INI_PERDIR, or INI_ALL. If it is INI_SYSTEM, PHP will ignore it. Info about INI modes scope.
Here you can see a list of directives so you can check whether they can be changed in .user.ini files or not.
Thanks for pointing that out… that makes perfect sense now.
After a bit more testing, I ended up handling the settings that are INI_SYSTEM only (mainly advanced directives) by using a custom 99-*.ini file under: /etc/php/*/fpm/conf.d/
I’m not sure if this is the best approach overall, but I can say that it works very well for me.
If you want those directives to affect all domains using that PHP version, that’s fine. If you want them to affect only one or several domains, you can create a PHP template with those directives and assign it to the domain or domains you need.
For example, this is the template for PHP 8.3:
❯ cat /usr/local/hestia/data/templates/web/php-fpm/PHP-8_3.tpl
; origin-src: deb/php-fpm/multiphp.tpl
;#=========================================================================#
;# Default Web Domain Template #
;# DO NOT MODIFY THIS FILE! CHANGES WILL BE LOST WHEN REBUILDING DOMAINS #
;# https://hestiacp.com/docs/server-administration/web-templates.html #
;#=========================================================================#
[%domain%]
listen = /run/php/php%backend_version%-fpm-%domain%.sock
listen.owner = %user%
listen.group = www-data
listen.mode = 0660
user = %user%
group = %user%
pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s
pm.status_path = /status
php_admin_value[upload_tmp_dir] = /home/%user%/tmp
php_admin_value[session.save_path] = /home/%user%/tmp
php_admin_value[open_basedir] = /home/%user%/.composer:/home/%user%/web/%domain%/public_html:/home/%user%/web/%domain%/private:/home/%user%/web/%domain%/public_shtml:/home/%user%/tmp:/tmp:/var/www/html:/bin:/usr/bin:/usr/local/bin:/usr/share:/opt
php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f admin@%domain%
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /home/%user%/tmp
env[TMPDIR] = /home/%user%/tmp
env[TEMP] = /home/%user%/tmp
So you can add your directives using php_admin_value[DIRECTIVE] = VALUE.
To create a template, you can copy one of the existing templates and rename it using the format whatever-PHP-X_Y.tpl and assign that PHP template to your domain.
That template is used by Hestia to create the pool conf for your domain.
Example:
❯ cat /etc/php/8.3/fpm/pool.d/example.net.conf
; origin-src: deb/templates/web/php-fpm/default.tpl
;#=========================================================================#
;# Default Web Domain Template #
;# DO NOT MODIFY THIS FILE! CHANGES WILL BE LOST WHEN REBUILDING DOMAINS #
;# https://hestiacp.com/docs/server-administration/web-templates.html #
;#=========================================================================#
[example.net]
listen = /run/php/php8.3-fpm-example.net.sock
listen.owner = test
listen.group = www-data
listen.mode = 0660
user = test
group = test
pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s
pm.status_path = /status
php_admin_value[upload_tmp_dir] = /home/test/tmp
php_admin_value[session.save_path] = /home/test/tmp
php_admin_value[open_basedir] = /home/test/.composer:/home/test/web/example.net/public_html:/home/test/web/example.net/private:/home/test/web/example.net/public_shtml:/home/test/tmp:/tmp:/bin:/usr/bin:/usr/local/bin:/usr/share:/opt
php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f [email protected]
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /home/test/tmp
env[TMPDIR] = /home/test/tmp
env[TEMP] = /home/test/tmp
I also tried the method you suggested, but I ended up dropping it because a few directives weren’t being applied.
I’ve tried creating a custom PHP-FPM template using php_admin_value[DIRECTIVE] = VALUE under /usr/local/hestia/data/templates/web/php-fpm/.
However, it seems that some directives don’t behave as expected when set this way.
For example, setting: php_admin_value[xdebug.mode] = profile
does show up correctly in phpinfo() as xdebug.mode = profile, but the Profiler itself is still shown as disabled.
In contrast, when applying the same directives globally via a 99-*.ini file under /etc/php/8.5/fpm/conf.d/, everything works as expected and the profiler shows as enabled, but that applies globally, which I’d like to avoid.
).