I’m trying to reduce the public attack surface on my HestiaCP server and would like to configure phpMyAdmin so that it is accessible only via the management port (8083) and not via the public HTTPS port (443).
Port 8083 is restricted at the Vultr firewall to my office IP only
Port 443 is open publicly for hosted websites
What I attempted:
Renamed /etc/apache2/conf.d/phpmyadmin.inc to disable public access.
This removed https://domain.com/phpmyadmin
However, it also broke phpMyAdmin access from inside the Hestia panel (8083).
Created a custom NGINX proxy template and added:
location ^~ /phpmyadmin { return 404; }
This successfully blocks public access on 443
But the “phpMyAdmin” button inside the Hestia panel still opens the 443 URL, so it gets blocked there as well.
What I am trying to achieve:
No public access to https://domain.com/phpmyadmin
phpMyAdmin accessible only through: https://server:8083 (Hestia management interface)
Keep default Hestia behavior intact without breaking updates
My understanding now is that the Hestia panel button redirects to the public 443 URL rather than serving phpMyAdmin internally on 8083.
Is there a supported or recommended way to:
Serve phpMyAdmin directly through the management port (8083), or
Configure Hestia so the panel does not rely on the public alias?
Appreciate any clarification on whether this is possible within the current architecture or if phpMyAdmin is intentionally designed to work only via the web stack (443).
That’s not possible. phpMyAdmin runs on Nginx or Nginx+Apache2, which are the same services serving your websites. Hestia uses a separate, independent Nginx instance (running by default on port 8083) just to serve the Control Panel.
You can modify the phpmyadmin.inc file so it only allows access from your office ip.
For Nginx only edit /etc/nginx/conf.d/phpmyadmin.inc and add this:
For Nginx+Apache2 edit /etc/apache2/conf.d/phpmyadmin.inc and add this:
<RequireAll>
Require ip Here.Your.Office.IP
</RequireAll>
In context:
# phpMyAdmin default Apache configuration
Alias /phpmyadmin /usr/share/phpmyadmin
<Directory /usr/share/phpmyadmin>
<RequireAll>
Require ip Here.Your.Office.IP
</RequireAll>
Options FollowSymLinks
DirectoryIndex index.php
Include /etc/apache2/snippets/restrict-pma.conf
<IfModule mpm_event_module>
# Use www.conf instead
<FilesMatch \.php$>
SetHandler "proxy:unix:/run/php/www.sock|fcgi://localhost"
</FilesMatch>
</IfModule>
</Directory>
# Disallow web access to directories that don't need it
[...]
You should also made the changes in the templates used by Hestia to create phpmyadmin.inc files:
For Nginx is here /usr/local/hestia/install/deb/nginx/phpmyadmin.inc
For Nginx+Apache2 /usr/local/hestia/install/deb/pma/apache.conf
You’re out of luck, after Hestia updates, you’ll have to modify the templates again. However, you can create a hook to be executed by Hestia after updates to re-apply the changes (those phpMyAdmin templates are rarely updated, but it’s something to be aware of).
First of all, thank you for the detailed explanation — that really helped clarify the architecture.
I just want to better understand the design decision behind this.
From a security perspective, exposing phpMyAdmin through the same public web stack (443) as hosted websites increases the attack surface, even if authentication is required. My initial expectation was that database management would be tied to the management port (8083), since that port is already restricted and intended for administrative access.
So my question is:
Is serving phpMyAdmin via the public web stack an intentional design choice?
Is this considered acceptable from a security best-practice standpoint?
Am I overthinking the risk here, or is it reasonable to want phpMyAdmin isolated from public web traffic?
I’m trying to determine whether my concern is justified or if this is simply standard hosting panel architecture.
Why not? You are also exposing the websites, webmail and other services.
Every public service is a potential risk, there is no doubt about that. If you think it’s better to block access, then go ahead and do it.
Keep in mind that not all users or customers managed by Hestia may have access to the control panel. By doing it this way, they will always be able to manage their databases under their own domains.
This is not a security measure, but you should change the alias so it cannot be accessed using phpmyadmin (and avoid using pma as an alias as well ). This will help prevent many bots from attempting to brute-force access.
First of all, thank you for the detailed explanations and for taking the time to clarify the architecture. I really appreciate it.
For context, this server is not used for shared hosting — we do not allow clients direct access to the control panel or to phpMyAdmin. It’s a single-operator environment where we manage everything internally.
As part of testing, I created a custom proxy template and blocked /phpmyadmin at the NGINX level. That successfully removed public access, but I now understand why it also affects how the panel opens phpMyAdmin (since it relies on the public web stack).
My goal wasn’t to redesign Hestia, just to reduce unnecessary exposure in our specific use case. Given your explanation about multi-tenant design, it makes sense why phpMyAdmin is exposed through the web stack by default.
Thanks again for the clarification — this helped me understand the reasoning behind the implementation much better.
). This will help prevent many bots from attempting to brute-force access.