Feature Request: Package-level toggle to disable/hide manual database creation

mucahost

Hi Enhance Support Team,
I am writing to request a feature that allows server administrators to disable or hide the manual "Create Database" option on a per-package basis.
The Use Case & Problem:
For our WordPress-specific plans, we strictly limit the "Website" quota to 1. However, to allow users to utilize the native Enhance Staging feature, we must set the "Databases" limit to 2.
Unfortunately, users are actively abusing this second database quota. Instead of using it for a staging environment, they manually create the second database and install a completely separate live site inside a subfolder (e.g., domain.com/secondsite).
Why Current Workarounds Fail:

Setting DB limit to 1: This completely breaks the Enhance native staging feature.
Custom CSS: Hiding the button via Custom CSS applies globally. We cannot do this because we need users on our Node.js and Laravel packages to freely create and manage their databases.
Resource/Inode Choking: Relying on strict inode or PHP worker limits to prevent subfolder installations creates a poor user experience and increases our support ticket overhead.
Proposed Solution:
Please add a simple toggle in the Package Settings (e.g., "Allow manual database creation: Yes/No").
If set to "No", the user should not see the option to manually create a database in their portal, BUT the Enhance system should still be able to auto-provision that second database in the background when the user initiates the Staging creation process.
This would give hosting providers much better control over resource abuse while keeping the native staging functionality intact for specific packages.
Looking forward to your thoughts on implementing this.

Best regards.
Mahmud Sabuj

ferrokot

mucahost Unfortunately, users are actively abusing this second database quota. Instead of using it for a staging environment, they manually create the second database and install a completely separate live site inside a subfolder

Hello, it will be better first to test how it works...
As I tested it - Databases counting only for live env. Looks like staging can use unlimited DB amount (but I didn't test)

webdig

mucahost

Thanks for the discussion, everyone. I just did some deep testing, and I found a massive loophole that makes current limits quite useless for shared hosting providers.
Even if I set the Database limit to 0 (which successfully hides manual DB creation) and Website limit to 1, a user can still:

Go to their existing website's dashboard.
Use the internal 'Install WP' option to install another WordPress instance into a sub-folder (e.g., domain.com/second-site).
The system allows this because the auto-installer has 'app-provisioning' privileges that bypass the 0 database quota, and it doesn't trigger the website limit since it’s under the same domain.
This means a user can technically host unlimited WordPress sites on a single-site plan just by using sub-folders, and we have no way to stop the auto-installer from provisioning those extra databases.
We desperately need two things:
A way to disable/limit 'Sub-folder' or 'Nested' installations per package.
A 'Max Apps per Website' limit (e.g., if set to 1, the user cannot install a second WP/App under the same site container).
Without this, resource abuse is inevitable.

ferrokot

mucahost But you can also restrict nproc and cores and RAM for one of this website and after that this client will start to catch 500 errors or if this websites dont have traffic so you dont need to care about it.

here is no issue with applications - here is the issue with addon domain and alliases you can restrict the amount and place 0 addon domains and it should resolve the issue.

mucahost

ferrokot

This is not a good idea for clean hosting solutions 😃

Here is why:

Addon domains don't prevent sub-folder installs: Setting addon domains or aliases to 0 does absolutely nothing to stop a user from installing 10 different WordPress apps into domain.com/site1, domain.com/site2, etc. They don't need extra domains to do this.
The "Don't care if there's no traffic" approach is flawed: Even if those sub-folder sites get zero traffic, they are consuming disk space, inodes, and significantly increasing the size of server backups. Furthermore, it completely ruins the commercial model. Why would an agency upgrade to a 5-site plan if they can just host 5 different client development sites in subfolders on a 1-site plan?
Relying on 500 errors is bad UX: Choking resources (RAM/Cores) to the point where the client gets 500/503 errors just leads to a massive influx of support tickets ("My site is down/slow!").
As hosting providers, our goal is to prevent the creation of unauthorized apps natively in the UI, rather than letting them create a mess and punishing them with 500 errors later.
A simple toggle to disable nested/sub-folder app installations per package would solve this elegantly without causing support headaches.

nhybgtvfr

well, whatever you do, it never stops a client installing multiple wordpress installs anyway..
even if they are limited to a single database, they could still install multiple instances of wordpress all using the same database, just set each one to use their own table prefix.

perhaps the most effective option would be to use the existing limits..
the cumulative total of number of websites, staging websites, add-on domains and subdomains as a limit for the number of app installs allowed.
or create a new limit setting in the packages configuration for the allowed number of app installs.
that's probably going to be more effective, especially if that also limits the number of apps that get shown in the management toolkit in the enhance panel.

it still won't block multiple manual installs sharing a database, but that would have to be done manually and most clients wouldn't know how to do this.
some will, but the only way you're ever going to stop them is very tight limits on disk space / inodes.. or cpu/ram resources and that's going to cause more issues that it solves.

mucahost

nhybgtvfr

Spot on! You perfectly summarized the reality of shared hosting.
You are completely right about the manual installations using different table prefixes. However, as you noted, 95% of standard users don't have the technical know-how (or the patience) to manually upload files, edit wp-config.php, and mess with DB prefixes. Our primary concern is the 1-click auto-installer making it trivially easy to spin up unlimited separate sub-folder sites.
I completely agree with your conclusion: restricting resources to cause 500/503 errors just creates a massive support headache for us.
Your suggestion to 'create a new limit setting in the packages configuration for the allowed number of app installs' is the absolute silver bullet here.
If Enhance simply adds a ‘Max App Installs per Website' limit in the package settings, it instantly solves the problem. It stops the automated UI-level abuse, keeps the native staging feature functional, and avoids unnecessary support tickets.
I really hope the Enhance development team takes this specific approach into consideration!