Feel free to provide at least some documentation in your question so to help more people in sharing some useful answers

I mark this question as resolved since it has at least one answer. Feel free to provide more information to help other people to add other answers later :)

I wish to repeat my earlier request that the issue would remain open and visible.

For reasons explained, I feel that the issue is broadly relevant to a potential cohort of a user base, and I regret any reasons for the earlier characterization as the request being spam or attempting to promote other software.

The published overview of the application appears to express ambiguity over compatibility with shared hosting environments. Some remarks in the current discussion have cast more serious doubt on compatibility at least specifically with cPanel.

I believe the broader issue may be expressed as forming into several components, as follows:

1. What are the causes of current incompatibility with shared hosting environments, such as cPanel and Plesk?
2. Is resolution of such incompatibility feasible, in terms of any required design changes or feature degradation, due to limitations of such environments?
3. If deployment in cPanel and Plesk would be possible, would an installation script for Softaculous make application deployment easier for those targeting such environments?

I'm going to open this question's visibility, and also answer your questions here - in the hopes we can put this issue behind us.

1. Why won't Phorge work in shared hosting?

Phorge is a big piece of software, and needs access to background processes (daemons), file management, and mysql management.
It's also not easy to manage/operate.
It's not impossible that it will work in shared hosting, but it's not likely and few people have been willing to make the effort.

2. Is resolution of such incompatibility feasible, in terms of any required design changes or feature degradation, due to limitations of such environments?

Realistically, no.
Or, more correctly, we don't want to make architectural changes to Phorge in order for it to work in limited environments.

3. If deployment in cPanel and Plesk would be possible, would an installation script for Softaculous make application deployment easier for those targeting such environments?

That's a moot point - it's not possible.

I understand the objections, and the realistic constraints.

For the record, at least some of the general issues to which you may have alluded are ones that have been addressed through various patterns that preserve compatibility with shared hosting.

For example, background tasks may be handled in many cases as cron jobs, which is supported by such environments.

One database per application deployment (i.e. installation instance) is a standard design pattern, which should be generally respected.

I use the example of Nextcloud as a large and complicated project that operates in such environments without sacrifice of features.

• background tasks: Phorge needs a "traditional service" that runs forever after its startup
• databases: Phorge for scalability reasons needs 60+ databases :) :) :) circa one database for each component (like one for Ponder, one for Diffusion, one for Maniphest, etc.)

I recognize that Phorge is a community effort inherited from an earlier commercial product. I am reluctant to make comments that may seem critical.

Nevertheless, the design constraints you have mentioned strike me as rather alarming.

In general, a periodically invoked process is capable of the same operations as a persistent one. Process persistence may be more convenient for design, but even persistent processes may be destroyed arbitrarily. It is essential that a process may resume necessary operations simply by reading the application persisted state.

Modern database management systems are highly scalable. They support immense table sizes, and no particular reason occurs for table count to be limited for a database schema more than for database cluster. Meanwhile, administrative permissions to an entire database system granted to a application is a security and stability risk that should be concerning to any developer or administrator. The need for an application to interact with an arbitrarily high count of separate databases within the same cluster or host is not one that appears, to my knowledge, in other applications.

About Daemon

Yeah you are describing a problem that is affected by a system administrator decision, not by a limitation of the underlying system.

The current situation is: the current daemon is just a lot of fast and efficient (and the demon has no design deficit in "persistence") For example, if a developer submits a git commit, they see it published as soon as possible (seconds, or even milliseconds). This would not happen that fast with a cron-job.

But, of course if you would like to create a "one-shot daemon call" that executes only a very-limited number of operations and then dies, so to be suitable to be called from a cron-job, that is just a Task to be created. But this involves some work.

Or, just create a normal systemd daemon (or whatever init system you use) - with limited privileges and user scope etc.

About databases

Again you are describing something limited by the system administrator, and not by the system itself.

It is probably possible to create a configuration that takes any database name from the queries and convert them to a "table prefix". Also this, feel free to request that and work on it. Or pay somebody to implement that, etc.

Or, just use a normal MariaDB installation, that allows to create an user that can work on any "phabricator_%" database. Or, you can adopt a scalable RDF provider, etc.

You should be more reluctant to make critical comments, especially as you're obviously not familiar with the project or its history (hint: it was never a commercial product).

Phorge is designed for large organizations, in which the ops limitations you're thinking of are not a concern. In those environments, running many small databases is easier then one large one - and in all environments, running many small databases is much faster then a single large one.

A git commit is a user-initiated event that may be processed synchronously. It is unclear why interaction with a daemon would be necessary to support a suitable user experience.

Your representation of a database administrative policy seems to me as inverted. One database per application deployment is the accepted pattern. Database management systems, as well as administrative policies and frameworks, and various other kinds of components, assume that the pattern would be followed, because agreement on the pattern is the reason why all such components would succeed in operating compatibly. Breaking the pattern breaks compatibility, and naturally may lead to an administrative nightmare.

The database is the concept within the database management system that encapsulates all the data used by a single application deployment. The schema is the concept describing the data structure used by a single application. Each deployment maps to a single database within a cluster. Such is the design of the database management system.

Please understand that you are a stakeholder of interests that are just different from the current situation, and not necessarily because we don't know what we are doing :)

To have that situation to work on that limited environment, you need some work. That is.

For me, the larger observation is that because the general dependencies are aligned to the LAMP environment, an opportunity emerges for the project to be adapted as suitable for the shared hosting space. In principle, such adaptations are not dependent on removing features that support large-scale deployments on dedicated systems or more capable environments. Rather, such adaptations may simply support a greater variety of deployment cases.

The more particular observation is that it appears the application design is largely being determined by a premise that MySQL carries a design flaw, of not scaling properly for larger table counts, except if the tables are separated into distinct databases on the same cluster. The premise may be correct, but it strikes me as doubtful. If it were accurate, then I would expect it to attract far more attention than any I have noticed.