Cloudron Forum

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.

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.

We have a number of cards in Wekan that represent templates for various business processes we have.

These templates encompass all the edge cases we need to consider, the information we need to gather, and are continuously improved as we have issues that come up where we could have avoided the issue by addressing something earlier in a templated process.

Today I was told one of these templates with dozen's of checklists and 165 checklist items was missing.

It appears that someone instead of making a copy of the template they accidentally moved the template and used it, deleting the unneeded checklists.

This appears to have happened over a month ago as we just happened to go through a period where we hadn't be doing this activity and our backups do not go back that far.

We backup everything locally and then sync that directory to the cloud and have limited storage available in the cloud even though locally we have more than enough space (looking forward to the multiple backup location feature so we can have more backups retained locally with only a subset in the cloud).

I was able to find an old backup that was not visible in cloudron that contained a backup of wekan from 3 months ago.

The backup was from a previous cloudron server that I had migrated from and was encrypted.

The app version has changed significantly since then and I believe we have done at least one cloudron update since then on the new server.

I was able to clone the app and then go through the import backup process on the cloned app and was shocked that after giving it the path and encryption password everything just worked.

It downloaded an old container image for the pervious version of the app, restored the data, and gave me access so that I could recreate the template that had been lost.

I wanted to share the praise here for cloudron as I fully expected that at best I would need to manually decrypt the file, find the mongodb backup, restore it to another mongodb instance, and then start rummaging through the data in the database to recreate what we needed but cloudron restored the app perfectly from an encrypted backup, from a separate server, and 3 month old app version.

Maybe I have low expectations but this kind of seamless restore feature of platforms always seems to fail for one reason or another and then maybe work after lots of troubleshooting and work arounds but this just worked as expected with no fuss.

10/10, thank you so much for this working so well.

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.

@jcalag The update has been released and I have installed it and the current bitwarden client works as expected again.

I have run the command sed -i 's/\r$//g' /app/data/fix_db.sh to fix the new line characters and then run bash /app/data/fix_db.sh again and it ran as expected. Disabled recover mode and confirmed things are back to working as expected.

Fyi, what I have ended up doing is creating a custom cloudron app with the postgresql feature and then hosting a nodejs app that communicates directly with the database to alleviate the need for generic direct access to postgresql.

@Lanhild If you want direct access to a postgresql database for testing and DB analysis stuff then you can use a custom app with the postgresql feature enabled and girish's post here to connect pgadmin to that custom app's postgresql instance.

@imatbagjagumilar If you still want to try this, the easiest way I can think of to accomplish these steps are as follows:

• In the cloudron portal navigate to System > Updates
• Now you should see the current update schedule and an edit hyperlink on the right to make changes to it
• Click Edit
• Take note of what your settings are currently as you will likely want to change them back after your app has been fully updated
• Make a change, like adding an additional hour of the day, but don't click save
• Press F12 to open the developer tools of your browser (I used a chrome based browser)
• Navigate to the network tab on in the developer tools
• Go back to the page and click Save
• Go back to Developer Tools network tab and you will now see two requests that have a name that starts with autoupdate_config
• Right click on the first one (it is the one that did a POST request), Navigate in the menu to Copy, and then click Copy as fetch
• Now in the developer tools click on the console tab and Paste in what you copied
• You should now have something like the following

fetch("https://SomeDomain.com/api/v1/updater/autoupdate_config?access_token=SomeToken", {
  "headers": {
    "accept": "*/*",
    "accept-language": "en-US,en;q=0.9",
    "cache-control": "no-cache",
    "content-type": "application/json",
    "pragma": "no-cache",
    "priority": "u=1, i",
    "sec-ch-ua": "\"Not;A=Brand\";v=\"8\", \"Chromium\";v=\"150\", \"Microsoft Edge\";v=\"150\"",
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": "\"Windows\"",
    "sec-fetch-dest": "empty",
    "sec-fetch-mode": "cors",
    "sec-fetch-site": "same-origin"
  },
  "referrer": "https://SomeDomain.com/",
  "body": "{\"schedule\":\"00 00 0,1,5,6,7,20,21,2 * * *\",\"policy\":\"platform_and_apps\"}",
  "method": "POST",
  "mode": "cors",
  "credentials": "include"
});

• Edit the line "body": "{\"schedule\":\"00 00 0,1,5,6,7,20,21,2 * * *\",\"policy\":\"platform_and_apps\"}", to be "body": "{\"schedule\":\"*/1 * * * *\",\"policy\":\"platform_and_apps\"}",
• In the console go to the end of what you pasted and press enter to run it
• Now if you look at the Updates cloudron page it should say it is doing updates Every day @ hourly which is the fastest that it can recognize but in reality it will be running every minute

After your fully updated, go back to the Updates screen and change it back to whatever update schedule you want.

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?

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.

I have opened up a request to get Spectre importer added as an app, please up vote if your still interested in that feature.

@jcalag Not out of the woods yet, still watching for an update to the cloudron app but hopefully we will have one soon.

PS, for those that hit this, if your user's have their master password memorized or accessible somehow they can log into the web version of vaultwarden to access the passwords in the mean time.

Also as another not great work around you can download the previous bitwarden client extension version 2026.6.1, expand assets and download the dist zip for your browser.

After extracting the zip somewhere I would disable the current version of the extension, then if using chromium based browser, enable developer mode for extensions and load an unpacked extension pointing it at the folder where you extracted the files.

This let me use the extension again for the time being but it is not easy to deploy at scale.

The Desktop application might also work, also available form that site, if you disable electron from updating but I haven't experimented with that yet.

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.

@ChristopherMag

The fix is to change REPO_INDEXER_PATH = indexers/repos.bleve to REPO_INDEXER_PATH = /app/data/appdata/indexers/repos.bleve.

Please go ahead and mark this as solved but I wanted to still post it in case it is useful for someone else.

Describing the problem led to the obvious solution :-).

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.

In case any one else is looking through this thread later, the best path forward in our case was to start using DigitalOcean's free DNS service and then change the domain configuration in cloudron from manual to DigitalOcean.

Our cloudron apps are hosted under a subdomain of the top level domain so we needed to setup both the top level domain and the subdomain in digital ocean with name server records for the subdomain defined at the top level domain. We also needed to change our domain registrar's setup so that they would point to DigitalOcean's name servers as authoritative for the domain.

All of this worked and has resulted in us being able to have a cloudron instance that is not reachable from the public internet in any way but is still able to use Let's Encrypt certificates for everything via cloudron's automatic certificate management.

If you go down this path please be sure to get things setup, change the domains configuration, sync dns, renew certificates, and reboot the cloudron server and if things are configured properly you should be able to see that the certificates being used switch from your manually loaded certificate to the Let's Encrypt certificate.

Ultimately this results in https connections between apps, like nextcloud and onlyoffice, working by default without work around needed to bypass certificate verification.

PS, anyone needing to do this, open the cloudron terminal for the app and then run the following:

cd src
python3 manage.py document_retagger -T

@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?

@timconsidine It looks like Apache Tika supports the document formats from the iWork suite like pages.

I tried to upload a .pages file to paperless-ngx with Tika and gotenberg configured and paperless popped up a failure message with the the error File type application/zip not supported.

I believe this signals.py file in the paperless-ngx project would need to add support for the various iWork software suite formats to resolve this error and get this working assuming you already have Tika and gotenberg setup and working with paperless-ngx.

You could probably open a github issue in the paperless-ngx repository on Github and see if they can assist with adding support fort his.

Relevant links:

• Download page which includes docker image instructions
• Docker hub image maintained by Camunda
• Relevant documentation on configuring LDAP authentication for integrated user management
  • The LDAP Identity and Administrator Authorization plugins are already included in the Docker image
• Administrator Authorization plugin which would be used to make Cloudron Admin's Camunda admins
• Process engine configuration needed for the Comunda process engine to use the Cloudron email relay
  • Email configuration is also mentioned here but it is in the context of new user email notifications which wouldn't be relevant if identity management is handled by Cloudron
• No state information for Camunda is in containers
• Docker container has runtime parameters to configure either MySQL or PostgreSQL database connection information
  • Documentation on other database parameters that can be passed to the container and example configuration using PostgreSQL
• Selenium based tests for the various applications in the distribution