Currently if you want to automatically import bank transactions into Cloudron hosted Firefly III you need to run and manage an instance of Spectre importer.
There is a docker image for this application maintained by the application's developers which will hopefully make integrating this easier.
Having the ability to host Spectre importer and Firefly III self hosted on Cloudron would allow it to work as a replacement to services like Mint.
I need to run a copy of some database engine where I can create custom tables, access the data from multiple tools like Excel, n8n, NocoDB, and Redash.
I would prefer Postgresql but MySQL would probably work fine for me as well.
In the past I would have run a Microsoft SQL Express instance but most everything else we use has now been standardized on Cloudron and I would rather use that platform instead of having to setup a separate self maintained system.
Cloudron hosts both of these databases along with MongoDB already internally accessible to specific apps that would like to use them but I would like to consume them as first class apps themselves that are not related to any other app or container running on cloudron.
I have a feeling I could probably make a very simple cloudron app that simply proxies the connection to the database exposed to that app but it would be really nice to have this as a directly supported scenario when, as in this case, the app I really want to use is the database itself.
I have opened up a request to get Spectre importer added as an app, please up vote if your still interested in that feature.
For anyone wanting to get this up and running quickly if you have docker running on another system you can run the following:
docker run -d --restart unless-stopped -p 3000:3000 gotenberg/gotenberg
docker run -d --restart unless-stopped -p 9998:9998 apache/tika
And then add the following to your paperless.conf:
# Tika
PAPERLESS_TIKA_ENABLED=true
PAPERLESS_TIKA_ENDPOINT=http://<DockerHostnameOrIPGoesHere>:9998
PAPERLESS_TIKA_GOTENBERG_ENDPOINT=http://<DockerHostnameOrIPGoesHere>:3000
After this you can upload xlsx, docx, etc. to paperless-ngx.
In my testing if the Docker host running the Tika and Gotenberg containers goes down paperless-ngx keeps working fine but you won't be able to upload additional xlsx/docx/etc. documents until you restart the containers which works out fine as the reliability of paperless-ngx being accessible is way more important than this one feature working for us.
For anyone else coming later, if you need to modify these files to test out for instance a code fix you would use the CLI tool to run cloudron debug --app app.domain.com, open a web terminal to the app, edit whatever files you need to in /app/code, and then run /app/pkg/start.sh from within that web terminal to manually start the app and test your change.
You can exit debug mode, which will delete your changes, by going to the app's settings in cloudron, Repair, and clicking the Disable Recovery Mode button.
This may be something that I just need to learn better but I tried to manually update apps over the last few days by clicking the update button for the individual app tiles and each time it would start and then look like it finished but no update took place.
I eventually figured out today that this was due to the mount point where backups are sent not being available and after fixing that updates complete as expected but before this point they were failing silently when manually triggered.
I am not sure where I would look to see the reasons the update failed as the app's logs don't show anything and the Cloudron event log shows the update being triggered but doesn't show anything indicating that the update failed and subsequently why it failed.
I just watched the BayLISA presentation on Cloudron and saw it mentioned that they do Selenium tests of the applications on each release so I have updated my original post to include a link to Camunda's own maintained selenium based web application tests.
This is something I need as well, working on rolling out PaperlessNGX to replace an existing storage system and need to be able to store office documents as well so that all documents related to an entity are together.
It looks like Tika and Gotenberg both have docker containers available.
Do we need to have separate Tika and Gotenberg apps like we have OnlyOffice and Collabra Online as a separate apps though they are not usable on their own and are used by NextCloud for handling office documents?
We have begun to use paperless-ngx and one of the most compatible ways for various scanners to integrate with that software is for the folder that paperless-ngx watches (they call it the consume folder) to import documents from gets exposed as an SMB share and then whatever scanner or scanner software is pointed at that share when documents are scanned.
In our case we use cloudron so the instructions online about exposing the consume folder as an SMB share I believe are not something that can be done in cloudron.
It would be really helpful for this app to be able to expose a path as an SMB share (preferably SMBv3 or higher with user account credentials being pulled from Cloudron) so that we could integrate paperless-ngx with our scanners, in our case various models of Fujitsu ScanSnap.
Relevant links:
@nebulon Do I need to make a second post or add this somewhere else to get the MongoDB button in the web terminal fixed?
@subven Thanks for the help, using mongosh with everything else the same worked perfectly, cron jobs updated and things working as expected again aside from the MongoDB button not doing what it should 
.
@subven Gotcha, working on using mongosh instead now.
If this is now the correct way to access Mongo then the MongoDB button in the webterminal needs to be updated to use that as currently when clicked it still tries to use mongo.
Steps to reproduce:
MongoDB button
mongo -u "${CLOUDRON_MONGODB_USERNAME}" -p "${CLOUDRON_MONGODB_PASSWORD}" ${CLOUDRON_MONGODB_HOST}:${CLOUDRON_MONGODB_PORT}/${CLOUDRON_MONGODB_DATABASE} into the terminalEnterbash: mongo: command not foundThis occurs with the latest version of wekan which has the new Cloudron base image to 4.0.0.
I am guessing that the mongo binary is not present in the 4.0.0 base image.
I have confirmed that the first version of Paperless-NGX with the 4.0.0 base image is also missing the mongo binary.
Currently this is causing cron jobs which use this binary to now fail when they would have succeeded in the past.
@marcusquinn Interesting, generically what your saying is that instead of asking cloudron to expose an app's storage out to other clients we can have the storage an app is using be hosted somewhere else in the first place that would already be accessible to other clients and have the app map that external storage location into its own files system.
Looking at cloudron volumes it looks like volumes can be CIFS, EXT4, Filesystem, Filesystem (Mountpoint), NFS, SSHFS, and XFS and so any external storage offering including cloud hosted ones like Hetzner's Storage box that exposes its storage via CIFS, NFS, or SSHFS could be directly added as a volume which could then be mounted inside the application.
In the case of paperless-ngx I could create a CIFS share on a local windows file server, then add that as a volume, then map that volume inside the storage tab of the app.
I looks like one other wrinkle is that the storage tab of an app doesn't allow you to arbitrarily map a volume to any location you want in the app's file system but only map to /media/{volume name} so you have to be able to reconfigure what path's an app is using for certain things to make use of an external volume or you have to move all of an app's data to an external volume.
Will test out reconfiguring paperless-ngx to point its consume directly at a mounted volume at /media/{volume name} which should resolve our specific near term need for a features like this.
We have begun to use paperless-ngx and one of the most compatible ways for various scanners to integrate with that software is for the folder that paperless-ngx watches (they call it the consume folder) to import documents from gets exposed as an SMB share and then whatever scanner or scanner software is pointed at that share when documents are scanned.
In our case we use cloudron so the instructions online about exposing the consume folder as an SMB share I believe are not something that can be done in cloudron.
It would be really helpful for this app to be able to expose a path as an SMB share (preferably SMBv3 or higher with user account credentials being pulled from Cloudron) so that we could integrate paperless-ngx with our scanners, in our case various models of Fujitsu ScanSnap.
For anyone wanting to get this up and running quickly if you have docker running on another system you can run the following:
docker run -d --restart unless-stopped -p 3000:3000 gotenberg/gotenberg
docker run -d --restart unless-stopped -p 9998:9998 apache/tika
And then add the following to your paperless.conf:
# Tika
PAPERLESS_TIKA_ENABLED=true
PAPERLESS_TIKA_ENDPOINT=http://<DockerHostnameOrIPGoesHere>:9998
PAPERLESS_TIKA_GOTENBERG_ENDPOINT=http://<DockerHostnameOrIPGoesHere>:3000
After this you can upload xlsx, docx, etc. to paperless-ngx.
In my testing if the Docker host running the Tika and Gotenberg containers goes down paperless-ngx keeps working fine but you won't be able to upload additional xlsx/docx/etc. documents until you restart the containers which works out fine as the reliability of paperless-ngx being accessible is way more important than this one feature working for us.
For anyone else coming later, if you need to modify these files to test out for instance a code fix you would use the CLI tool to run cloudron debug --app app.domain.com, open a web terminal to the app, edit whatever files you need to in /app/code, and then run /app/pkg/start.sh from within that web terminal to manually start the app and test your change.
You can exit debug mode, which will delete your changes, by going to the app's settings in cloudron, Repair, and clicking the Disable Recovery Mode button.
@girish I thought that you could run the command without first cd'ing into the src directory but when running it again today I found out that was incorrect.
I have edited my post above to first include cd src and then python3 manage.py document_retagger -T.
Could you please update the documentation as what I originally posted doesn't work for some reason, python throws an exception if you don't cd first?
This is something I need as well, working on rolling out PaperlessNGX to replace an existing storage system and need to be able to store office documents as well so that all documents related to an entity are together.
It looks like Tika and Gotenberg both have docker containers available.
Do we need to have separate Tika and Gotenberg apps like we have OnlyOffice and Collabra Online as a separate apps though they are not usable on their own and are used by NextCloud for handling office documents?