Repository navigation
Make EX_APP_CONTAINER_PREFIX configurable #523
Description
Describe why it is important and where it will be useful
If you have several Nextcloud instances on the same host. It would be good to be able to run several proxys that has its own prefix configured on the same host.
Right now it is nc_apps and it make it impossible to register two proxies on the same host (for development puproses, testing and simpler hosted solutions)
Describe your proposed solution
Either have this as a variable within the web interface or as an occ setting. Create a prefix for the current instance.
Describe alternatives you've considered, if relevant
No response
Additional context
No response
Reacted by Maxime LE HERICY, Alexander Piskun, Christian Wolf, Rodrigo Borges, traskat, RickStinson, Florian Storz, YANO Tetsuro and Dominik1236
Activity
oleksandr-nc commentedon Mar 26, 2025
This has been added to the roadmap, with no exact timeframe yet.
christianlupus commentedon Oct 16, 2025
@oleksandr-nc is there any news?
I might need it soon and I might give it a try to fix it myself (would open a PR if I solve it) but do not want to interfere with upstream work.
small1 commentedon Oct 16, 2025
Would this work?
In app_api/lib/DeployActions/DockerActions.php
Set the domainprefix with occ config:app:set app_api domainprefix --value= And if its not set use the constant with a fixed name.
This could if one is not carefull still break stuff if one has two instances with the same domainprefix. So probably needs to be a bit safer. But this could be a start.
christianlupus commentedon Oct 17, 2025
More or less yes, this is what I had partially in mind. I wanted make the configuration in the admin settings. But yeah. Plus some testing on a dev instance 😉.
small1 commentedon Oct 17, 2025
I have done tests on two hosts so far. I have no clue on how to make it for the ui. I know enough for backend stuff but not more :)
oleksandr-nc commentedon Oct 20, 2025
The idea is generally good, even excellent.
It's not guaranteed that we'll be able to backport it, as it is a new feature and not a bugfix, but we can include it in Nextcloud 33.
A UI isn't required for this; simple
occcommands will suffice, in my opinion.The DSP will have problems with rules, but we expect that by Nextcloud 33 everyone will be using HaRP, and adding support for it should be easy:
app_api/lib/DeployActions/DockerActions.php
Line 138 in 83d5152
appConfigthat enables that uncommented line when it is set(by default the behaviour should be as it is commented)street1983nk commentedon Sep 7, 2026
While writing up #1021 (cross-instance deletion, deliberately not a naming ticket) I read the code around this and noticed two things the plan above does not cover yet.
The commented-out
$instanceId = ''; // $this->config->getSystemValue('instanceid', '');exists six times inDockerActions.php(main: lines 136, 250, 905, 944, 983, 1030), and line 1030 sits in the removal path. Enabling only the deploy site would createnc_app_<instanceid>_<appid>but keep removingnc_app_<appid>, so containers and volumes would be orphaned instead of removed.buildExAppContainerName/buildExAppVolumeName(1349/1353) would need to move along too, sinceUnregister.php,ExAppsPageController.phpandAppAPIService.phpall build names through them.Good news on the HaRP side: it has been ready since v0.2.0.
haproxy_agent.pydeclaresinstance_id(line 199) and already buildsnc_app_<instance_id>_<name>plus the matching_datavolume name whenever the field is non-empty (lines 205 and 214). So on that path the remaining work really is just filling the field consistently on the server side.