Elasticsearch
-
Why not build it locally and deploy it?
(I wonder if the reluctance of deploying non-appstore comes from the difficulty of building an app or because it's seen as dangerous/unstable?)
@joseph 1) This approach is seperate to the common Cloudron usage
2) Updates are not automatically, but manually
3) Not everybody is able to build and install custom packages
4) It requires public space on docker.hub or a private instance of docker repo
5) the package is not optimized by the Cloudron maintainers
-
@Nicolas Indeed, current plan is to implement Elastic search as an addon and not as an app. This will help apps like Nextcloud etc have document search as well. I will move this port to Feature Requests since it's a platform level change.
If you want to use this right away, there are two approaches:
- use an external elastic search (i.e install it on a separate server and have the LAMP app access that)
- alternately, create a cloudron package and install elastic search as an app. You can install this package on
elastic.domain.comand then your app can use it directly.
@girish Perhaps the Nextcloud Talk High Performance Backend as well as the Elasticsearch could be installed together onto the same server, somehow.
There is also Manticore:
https://forum.cloudron.io/topic/9753/manticore-search-oss-fast-database-for-search-alternative-for-elasticsearch -
Updated Elastic to v9.1.5
https://git.due.ren/andreas/elasticsearch-cloudron/releases/tag/v9.1.5 -
Updated: https://git.due.ren/andreas/elasticsearch-cloudron/releases/tag/v1.0.17
- Plugins: bundle analysis-icu in the image so language-specific analyzers (incl. German) work out of the box and no longer hit runtime install failures on Cloudron’s read-only FS.
- Stability: revamped heap management to respect ES_JAVA_HEAP, custom jvm.options.d, and cgroup limits
-
@nichu42 This is honestly not super stable yet, I'm only using it for some nextcloud purposes and haven't tested it thoroughly.
-
@andreasdueren do you know if it's multi-tenant ? I think it makes sense to make elasticsearch as an addon (instead of an app). That way apps can come pre-installed/pre-configured with it. Apps and addons are very similar packaging wise. There is just some automation on top of it for backups and upgrades.
What's needed for addons is: an automated way to create (say) a username/password on the fly for a specific app. (The platform then injects these as env var in the container). If ES supports multiple stores (db/index or whatever it's called in ES world), then this username/password pair has to limit access to specific store i.e one app cannot access another app's store.
-
@andreasdueren do you know if it's multi-tenant ? I think it makes sense to make elasticsearch as an addon (instead of an app). That way apps can come pre-installed/pre-configured with it. Apps and addons are very similar packaging wise. There is just some automation on top of it for backups and upgrades.
What's needed for addons is: an automated way to create (say) a username/password on the fly for a specific app. (The platform then injects these as env var in the container). If ES supports multiple stores (db/index or whatever it's called in ES world), then this username/password pair has to limit access to specific store i.e one app cannot access another app's store.
@girish I'd love to be able to use Eleasticsearch on Cloudron so we can have full text search on Nextcloud (because I keep thinking of moving my Nextcloud away Cloudron and search is one of the reasons why - high performance backends and other shiny features that come as standard in the AIO package being other reasons)...
...so I was intrigued by you question and didn't know the response. ChatGPT say:
Right — so what Girish is asking about hinges on whether Elasticsearch supports secure multi-tenancy, meaning:
can multiple apps share a single ES instance safely, with each app isolated to its own dataset (index or namespace) and credentials?Here’s how that works in Elasticsearch:
Multi-tenancy in ElasticsearchElasticsearch does not natively provide hard multi-tenant isolation in the open-source (Basic) tier. All indices in a cluster are accessible to any client that can authenticate, unless you’re running a commercial licence (Elastic’s “Gold” or higher) with role-based access control (RBAC) via Elastic Stack Security (formerly X-Pack).
However, you can approximate multi-tenancy in several ways:
1. Single cluster, per-app indices (no true isolation)
- Each app gets its own index (e.g.
app1_*,app2_*). - Credentials: You can create separate API keys or users per app if you’re using Elastic Stack Security.
- Without X-Pack security, you can’t restrict one user to only their own indices.
Simple to manage
No isolation without paid security features
2. Single cluster, per-app namespaces with RBAC (requires paid Elastic licence)
- You create roles limiting each user to their own index patterns (e.g.
role_app1 → indices: app1_*). - Then create a user per app and assign its role.
True logical isolation
️ Requires enabling security features (which are part of Elastic’s commercial licence, not open source)
3. Separate Elasticsearch instances per app
- Each app gets its own single-tenant ES container.
- Cloudron would manage these automatically as separate addons (like how Postgres addons work).
Strong isolation, no need for commercial features
More resource usage, less efficient
4. OpenSearch alternative
If you switch to OpenSearch (the fully open-source fork of Elasticsearch 7.10), it includes fine-grained access control (FGAC) and multi-tenancy features under the Apache 2.0 licence.
That makes it more suitable for Cloudron’s addon model, since you can:- Create tenants
- Restrict users to specific indices
- Use internal user databases or LDAP for auth
- Do all this without paid licensing
Summary (for Girish / Cloudron dev context)Option Isolation Licensing Suitable for Addon Model? Notes Elasticsearch OSS None Open source 
No way to restrict users per index Elasticsearch (with X-Pack Security) Yes Commercial
️Technically possible, but licence issue Multiple ES containers Full Open source 
More resource-heavy OpenSearch Yes Open source 

Best fit for Cloudron addon use-case
RecommendationIf the goal is to package Elasticsearch as a Cloudron addon shared by multiple apps with per-app credentials:
-
Use OpenSearch, not Elastic’s OSS build.
-
Implement addon hooks to:
- Create an index pattern per app (
app_<id>_*) - Create a user + password via the OpenSearch security API
- Assign permissions for that index pattern
- Inject credentials into the app container’s env vars
- Create an index pattern per app (
That way, the model matches existing Cloudron addons like PostgreSQL: single shared service, isolated logical databases per app.
Would you like me to sketch a quick pseudo-flow (in YAML or JSON) showing how Cloudron could auto-provision an OpenSearch user/index when an app requests the addon?
- Each app gets its own index (e.g.
-
Now I'm wondering if Nextcloud can be configured to use OpenSearch instead of Eleasticsearch!
And it sounds like the answer is yes!
Excellent question — and you’re right to wonder!
Here’s the situation as of late 2025:
Nextcloud and OpenSearch Compatibility
The good news:
Yes — Nextcloud can use OpenSearch instead of Elasticsearch for full-text search.OpenSearch is a drop-in fork of Elasticsearch 7.10, and Nextcloud’s full-text-search ecosystem (the core Full Text Search app plus back-ends like Full Text Search – Elasticsearch Platform) works with any API-compatible engine — which OpenSearch still is.
Nextcloud’s own documentation and issue tracker confirm that OpenSearch works if you’re running:
- Nextcloud ≥ 23
- OpenSearch ≥ 1.0
- The app Full text search – Elasticsearch Platform version ≥ 1.9.0 (latest is fine)
️ How to configure Nextcloud to use OpenSearch-
Install OpenSearch
(either via Docker, Cloudron addon, or standalone service) -
Enable the required Nextcloud apps
fulltextsearchfulltextsearch_elasticsearch(this works with OpenSearch too)
-
Set connection details in
config.php'fulltextsearch' => [ 'elasticHost' => 'http://localhost:9200', // your OpenSearch endpoint 'elasticIndex' => 'nextcloud', 'elasticUser' => 'yourusername', 'elasticPassword' => 'yourpassword', ],or via
occcommands:sudo -u www-data php occ config:app:set fulltextsearch elasticHost --value="http://opensearch:9200" sudo -u www-data php occ config:app:set fulltextsearch elasticIndex --value="nextcloud" -
Index content
sudo -u www-data php occ fulltextsearch:index
️ Things to watch out for- TLS/HTTPS: Nextcloud’s app requires valid HTTPS certificates if the OpenSearch endpoint is remote.
- Authentication: If you enable OpenSearch security, provide credentials via the above config keys.
- Version mismatch: Some users report minor compatibility warnings in logs (harmless) because OpenSearch identifies itself differently, but functionality works.
SummaryFeature Elasticsearch OpenSearch Works with Nextcloud FTS 

Open Source (Apache 2.0)
(Elastic 2.0)
Multi-tenant security
Paid feature
Built-inBest choice for Cloudron addon
️
So yes — Nextcloud can happily talk to OpenSearch, making it the perfect backend for a Cloudron-style addon that multiple apps (including Nextcloud) could use securely.
Would you like me to show how that addon provisioning could look (so Nextcloud would automatically get its own OpenSearch index and credentials when installed)?
-
@girish I'd love to be able to use Eleasticsearch on Cloudron so we can have full text search on Nextcloud (because I keep thinking of moving my Nextcloud away Cloudron and search is one of the reasons why - high performance backends and other shiny features that come as standard in the AIO package being other reasons)...
...so I was intrigued by you question and didn't know the response. ChatGPT say:
Right — so what Girish is asking about hinges on whether Elasticsearch supports secure multi-tenancy, meaning:
can multiple apps share a single ES instance safely, with each app isolated to its own dataset (index or namespace) and credentials?Here’s how that works in Elasticsearch:
Multi-tenancy in ElasticsearchElasticsearch does not natively provide hard multi-tenant isolation in the open-source (Basic) tier. All indices in a cluster are accessible to any client that can authenticate, unless you’re running a commercial licence (Elastic’s “Gold” or higher) with role-based access control (RBAC) via Elastic Stack Security (formerly X-Pack).
However, you can approximate multi-tenancy in several ways:
1. Single cluster, per-app indices (no true isolation)
- Each app gets its own index (e.g.
app1_*,app2_*). - Credentials: You can create separate API keys or users per app if you’re using Elastic Stack Security.
- Without X-Pack security, you can’t restrict one user to only their own indices.
Simple to manage
No isolation without paid security features
2. Single cluster, per-app namespaces with RBAC (requires paid Elastic licence)
- You create roles limiting each user to their own index patterns (e.g.
role_app1 → indices: app1_*). - Then create a user per app and assign its role.
True logical isolation
️ Requires enabling security features (which are part of Elastic’s commercial licence, not open source)
3. Separate Elasticsearch instances per app
- Each app gets its own single-tenant ES container.
- Cloudron would manage these automatically as separate addons (like how Postgres addons work).
Strong isolation, no need for commercial features
More resource usage, less efficient
4. OpenSearch alternative
If you switch to OpenSearch (the fully open-source fork of Elasticsearch 7.10), it includes fine-grained access control (FGAC) and multi-tenancy features under the Apache 2.0 licence.
That makes it more suitable for Cloudron’s addon model, since you can:- Create tenants
- Restrict users to specific indices
- Use internal user databases or LDAP for auth
- Do all this without paid licensing
Summary (for Girish / Cloudron dev context)Option Isolation Licensing Suitable for Addon Model? Notes Elasticsearch OSS None Open source 
No way to restrict users per index Elasticsearch (with X-Pack Security) Yes Commercial
️Technically possible, but licence issue Multiple ES containers Full Open source 
More resource-heavy OpenSearch Yes Open source 

Best fit for Cloudron addon use-case
RecommendationIf the goal is to package Elasticsearch as a Cloudron addon shared by multiple apps with per-app credentials:
-
Use OpenSearch, not Elastic’s OSS build.
-
Implement addon hooks to:
- Create an index pattern per app (
app_<id>_*) - Create a user + password via the OpenSearch security API
- Assign permissions for that index pattern
- Inject credentials into the app container’s env vars
- Create an index pattern per app (
That way, the model matches existing Cloudron addons like PostgreSQL: single shared service, isolated logical databases per app.
Would you like me to sketch a quick pseudo-flow (in YAML or JSON) showing how Cloudron could auto-provision an OpenSearch user/index when an app requests the addon?
@jdaviescoates said in Elasticsearch:
Use OpenSearch
Not sure if it's 100% compatible with nextcloud. I guess the only way to be sure would be to package and test it.
- Each app gets its own index (e.g.
-
There is mixed data on compatability.
OpenSearch […] will not work.
opensearch is not supportedd
For anyone reading this post for solution, I am currently using OpenSearch for FullTextSearch with NextCloud using this project : - https://github.com/fairkom/nextcloud_opensearch