Cloudron Forum

We are packaging another nostr relay for cloudron, the repo is here: https://git.nostrdev.com/stuff/cloudron-orly

This relay includes an embedded neo4j database. This requires enabling some additional ports.

The first deploy seems to be working smoothly.

However the second aborts as follows:

user@ft:~/git/cloudron-orly$ cloudron install -l mleku.ft.hn --image git.nostrdev.com/stuff/cloudron-orly@sha256:4e1fae78b22ce572d07b1c566b97623d948c98935e3c3de06f4b3ddd2e0adf30 
Port NEO4J_BROWSER_PORT: 7473
Port BOLT_BROWSER_PORT: 7687
Failed to install app: 409 message: Conflicting tcp port 7473

It seems to be possible to deploy in spite of this error if removing the "defaultValue" from the "tcpPorts" config. But then the UI appears borked.

Is there any way to have the tcpPort assigned (to the first available port, perhaps inside of a range) during the initial deploy?

How to deploy multiple instances of an app, that uses additional ports, using the CLI?

Hi guys

The latest instance of core is in the playground: https://git.cloudron.io/playground/bitcoin (yes, it's a dependency for btcpay server)

It's true that the entire blockchain is always downloaded (consuming bandwidth) but you don't need more than your pruned size setting in terms of disk storage.

The package also contains instructions to allow you to set a volume, so that the blockchain is not part of your backups.

Happy to jump on a call to assist if needed

we use desec.io, they're great, just be warned that you might hit rate limits if migrating a large cloudron instance to a new IP

any reason you can't just run your Bitcoin node on your cloudron instance? it's prunable, which means it won't take loads of space.

The rpc user/ pass definitely needs to be in the bitcoin.conf, it also needs to be salted/hashed, see: https://github.com/jlopp/bitcoin-core-rpc-auth-generator

If you install bitcoin core, the btcpay server will automatically use your local (cloudron) instance

we didn't test the install against a remote server but your config looks good. Your IP is a regular IP right, not a domain?

  rpc_user: "bitcoin"
  rpc_password: "pass"
  rpc_host: "172.28.0.2"
  rpc_port: 8332
  node_endpoint: "172.28.0.2:8333"

The nbexplorer thing is internal to btcpay server (this was the hardest part about setting up the container)

Does your remote btc core instance have rpc enabled? something like this in your bitcoin.conf file:

rpcauth=bitcoin:pass

The problem is that fiat is constantly being debased / inflated, such that money spent today becomes worthless after a few years

Agreed that we should not use cloudflare, not just from the single-point-of-failure perspective, but also to protect user privacy

We would like to see a cloudron reseller who accepts Bitcoin for payment

It appears the turn server is no longer used as an addon in SFU - could this explain why the app just does not work for many of our participants for several months now?

https://git.cloudron.io/packages/mirotalksfu-app/-/commit/05013ccfb0cbd9342433783e8ffe7c3fb14fa600

done! we would like to add that the packaging team should prioritise the custom app installer over btcpay server (as we can easily deploy apps using the package installer from that point onward)

Authentication would be good. Probably not a good idea to normalise the act of entering admin creds onto another cloudron instance, it's an invitation for bad actors

If this app were available in the cloudron app store, it would make cloudron significantly, even exponentially more useful - as it would open up an entire universe of apps that the main cloudron team cannot / would not support.

The difference between iOs "walled garden" and the Android "sideload option". Android is far more ubiquitous as a result.

Obviously it comes with risks, and they should be well highlighted, however for those who understand and accept those risks a tool like this is just fantastic for enabling a plethora of new use cases on cloudron

If this app were deployed, we would also be incentivised to package up more apps, because the audience would be much much bigger

please do it! I would say it's even higher priorirty than our own app submissions (as we could easily use this tool to deploy them in the meanwhile)

@timconsidine I'm sure this is totally safe but would still prefer not to enter creds on a third party domain

Where is the repo?

found it: https://git.cloudron.io/timconsidine/cloudron-customapp-installer

I see that it requires docker to do the manual setup, is there a public image available?

This tool really ought to be on the main app store, it looks really handy!!

That web app looks cool! Is it self-hostable? Thanks for adding btcpay..

Remember that BTCPay also requires BTC Core (or Knots), or at least access to an instance somewhere

We suspect this is an issue with the host machine

You can test by running the following (will reset on next boot):

sudo sysctl fs.inotify.max_user_instances=512  # Or higher, e.g., 1024
sudo sysctl fs.inotify.max_user_watches=524288  # Increase this too if needed

For permanent fix:

• Edit or create /etc/sysctl.conf

insert / update:

fs.inotify.max_user_instances=512
fs.inotify.max_user_watches=524288

Then apply:

sudo sysctl -p

We updated the btcpayserver repo today to use the latest version (2.2.0) and fixed a CSP issue in the nginx.conf

True. In the meantime, we tell anyone and everyone about how and why they should move to Cloudron.

We had that issue and decided that we simply wouldn't reply to anyone contacting us from a gmail address

They clearly have no interest in freedom, and we don't want our comms being indexed on google servers.

We're a development team focused on helping clients build applications and solutions in the freedom tech / Bitcoin / Nostr space - https://nostrdev.com

We don't use Amazon, Facebook, Microsoft, or Google - and Cloudron is fantastic for this. It's also a really good option for hosting our client projects - we can just deploy them as containers, with their own URLs, no need to spin up / pay for additional machines.

We're contributing back - current submissions include:

• Bitcoin Core
• BTCPay server

Upcoming contributions include:

• Strfry (Nostr) relay
• Blossom (file) server
• SIGit - for secure and private document signing . https://sigit.io
• Trackstr - self hosted time tracker, an alternative to other "activity trackers" such asHubstaff or Trackabi. DM for details, we are looking for testers.

Our wish - that the Cloudron team would accept payment in Bitcoin. Maybe now they have their own payment gateway, they will reconsider

Desec is great but we hit issues when doing a restore onto a new IP address - we were locked out of desec.io due to rate limiting

We had a chat with the support and they suggested that cloudron could consider using their batch api to reduce the number of requests

But as we need to be able to recover without being locked out (out of hours) we switched to hetzner DNS instead.

TLDR; desec.io are great, the support is very good, however their rate limiting is somewhat aggressive and may catch you out in a bind.