I'd love to have this. The current solutions, already existing on cloudron (@girish) are actually not that mature. I remember you saying, (for the former app-name, hoarder) it could be a hassle to publicize that, but I'd strongly disagree, as this app is simple, easy to use use and allows for a one-stop solution for many use-cases.
Could you please take another look at it?
unfortunately not.
$ dig +trace +nodnssec ipv4.api.cloudron.io @127.0.0.150
;; communications error to 127.0.0.150#53: timed out
;; communications error to 127.0.0.150#53: timed out
;; communications error to 127.0.0.150#53: timed out
; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> +trace +nodnssec ipv4.api.cloudron.io @127.0.0.150
;; global options: +cmd
;; no servers could be reached
Ok, on running this command, no node-process shows up:
$ lsof -i :53
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 669 systemd-resolve 13u IPv4 17046 0t0 UDP localhost:domain
systemd-r 669 systemd-resolve 14u IPv4 17047 0t0 TCP localhost:domain (LISTEN)
unbound 20480 unbound 3u IPv4 164940 0t0 UDP localhost:domain
unbound 20480 unbound 4u IPv4 164941 0t0 TCP localhost:domain (LISTEN)
unbound 20480 unbound 5u IPv4 164942 0t0 UDP xum:domain
unbound 20480 unbound 6u IPv4 164943 0t0 TCP xum:domain (LISTEN)
It does still return a timeout. So here are the outputs of said commands (and one more):
$ dig +trace +nodnssec ipv4.api.cloudron.io @127.0.0.150
;; communications error to 127.0.0.150#53: timed out
$ systemctl status unbound.service
ā unbound.service - Unbound DNS Resolver
Loaded: loaded (/etc/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2025-11-25 09:32:52 UTC; 2 days ago
Process: 20475 ExecStartPre=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key (code=exited, status=0/SUCCESS)
Main PID: 20480 (unbound)
Tasks: 1 (limit: 76755)
Memory: 7.2M
CPU: 5.503s
CGroup: /system.slice/unbound.service
āā20480 /usr/sbin/unbound -d
Nov 25 09:32:50 xum systemd[1]: Starting Unbound DNS Resolver...
Nov 25 09:32:52 xum unbound[20480]: [20480:0] notice: init module 0: subnet
Nov 25 09:32:52 xum unbound[20480]: [20480:0] notice: init module 1: validator
Nov 25 09:32:52 xum unbound[20480]: [20480:0] notice: init module 2: iterator
Nov 25 09:32:52 xum unbound[20480]: [20480:0] info: start of service (unbound 1.13.1).
Nov 25 09:32:52 xum systemd[1]: Started Unbound DNS Resolver.
$ cat /etc/unbound/unbound.conf
# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
$ cat /etc/unbound/unbound.conf.d/cloudron-network.conf
# Unbound is used primarily for RBL queries (host 2.0.0.127.zen.spamhaus.org)
# We cannot use dnsmasq because it is not a recursive resolver and defaults to the value in the interfaces file (which is Google DNS!)
server:
port: 53
interface: 127.0.0.150
interface: 172.18.0.1
ip-freebind: yes
access-control: 127.0.0.1 allow
access-control: 172.18.0.1/16 allow
cache-max-negative-ttl: 30
cache-max-ttl: 300
# Prefer IPv4 outbound queries. Spamhaus often rejects queries from IPv6 addresses
# without this, unbound does not start on IPv6 only servers
do-ip6: no
# this setting only works with ubuntu 24 and unbound >= 1.19.2
# prefer-ip4: yes
# enable below for logging to journalctl -u unbound
# verbosity: 5
# log-queries: yes
# https://github.com/NLnetLabs/unbound/issues/806
remote-control:
control-enable: no
$ ls -al /etc/unbound/unbound.conf.d/
total 16
drwxr-xr-x 2 root root 4096 Nov 25 09:28 .
drwxr-xr-x 3 root root 4096 Nov 6 06:18 ..
-rw-r--r-- 1 root root 949 Nov 25 09:28 cloudron-network.conf
-rw-r--r-- 1 root root 190 Sep 7 2022 root-auto-trust-anchor-file.conf
@James Now I could do it. The result is this:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 669 systemd-resolve 13u IPv4 17046 0t0 UDP localhost:domain
systemd-r 669 systemd-resolve 14u IPv4 17047 0t0 TCP localhost:domain (LISTEN)
unbound 20480 unbound 3u IPv4 164940 0t0 UDP localhost:domain
unbound 20480 unbound 4u IPv4 164941 0t0 TCP localhost:domain (LISTEN)
unbound 20480 unbound 5u IPv4 164942 0t0 UDP xum:domain
unbound 20480 unbound 6u IPv4 164943 0t0 TCP xum:domain (LISTEN)
unbound 20480 unbound 13u IPv4 8207316 0t0 UDP Ubuntu-2204-jammy-amd64-base:64328->j.root-servers.net:domain
node 632203 yellowtent 24u IPv4 8210389 0t0 UDP localhost.localdomain:57067->localhost:domain
Not sure, how to read that, tbh. Does that help?
Thanks for the two of you @James @Joseph to help me with that.
$ dig ipv4.api.cloudron.io @127.0.0.150
;; communications error to 127.0.0.150#53: timed out
;; communications error to 127.0.0.150#53: timed out
;; communications error to 127.0.0.150#53: timed out
; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> ipv4.api.cloudron.io @127.0.0.150
;; global options: +cmd
;; no servers could be reached
For the record: my firewall is outbound open:
Hi @James - Thanks for your reply. Greatly appreciated.
I already did, as well as restarting the server. Both did not help, unfortunately.
Same here. I tried all steps from troubleshooting unbound (as described here: https://docs.cloudron.io/troubleshooting/#unbound).
I found the following line in the box.log:
box:services statusUnbound: unbound is up, but failed to resolve ipv4.api.cloudron.io . Error: queryA ETIMEOUT ipv4.api.cloudron.io at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/promises:294:17) { errno: undefined, code: 'ETIMEOUT', syscall: 'queryA', hostname: 'ipv4.api.cloudron.io' } undefined
Ping works, although:
$ ping ipv4.api.cloudron.io
PING ipv4.api.cloudron.io (165.227.67.76) 56(84) bytes of data.
64 bytes from prod.cloudron.io (165.227.67.76): icmp_seq=1 ttl=49 time=87.0 ms
64 bytes from prod.cloudron.io (165.227.67.76): icmp_seq=2 ttl=49 time=85.5 ms
I'd second this, as there is a growing need for private file-sharing, that is not overly complicated. Jirafeau is a bit too minimalistic, as per my opinion.
Just found automatisch.io - seems like a decent open source Zapier alternative. They do have some kind of docker-setup, apparently.
Sounds promising. Can someone please share how to install this app on my Cloudron? Thank you.
I actually have a problem to get any storage adapter to work:
Dec 15 16:49:03==> Ensure permissions
Dec 15 16:49:03==> Migrating database
Dec 15 16:49:04=> Healtheck error: Error: connect ECONNREFUSED 172.18.17.69:2368
Dec 15 16:49:04[2023-12-15 22:49:04] INFO Finished database init!
Dec 15 16:49:05[2023-12-15 22:49:05] INFO Finished database migration!
Dec 15 16:49:05==> Starting Ghost
Dec 15 16:49:05[2023-12-15 22:49:05] INFO Ghost is running in production...
Dec 15 16:49:05[2023-12-15 22:49:05] INFO Your site is now available on https://whatever/
Dec 15 16:49:05[2023-12-15 22:49:05] INFO Ctrl+C to shut down
Dec 15 16:49:05[2023-12-15 22:49:05] INFO Ghost server started in 0.423s
Dec 15 16:49:06[2023-12-15 22:49:06] INFO Database is in a ready state.
Dec 15 16:49:06[2023-12-15 22:49:06] INFO Ghost database ready in 0.705s
Dec 15 16:49:07[2023-12-15 22:49:07] ERROR Unable to find storage adapter s3 in ,/app/data/content/adapters/,/home/cloudron/ghost/versions/5.75.2/core/server/adapters/.
Dec 15 16:49:07
Dec 15 16:49:07Unable to find storage adapter s3 in ,/app/data/content/adapters/,/home/cloudron/ghost/versions/5.75.2/core/server/adapters/.
Dec 15 16:49:07
Dec 15 16:49:07Error ID:
Dec 15 16:49:0727753420-9b9c-11ee-acce-d91d06239c3f
Dec 15 16:49:07
Dec 15 16:49:07----------------------------------------
Dec 15 16:49:07
Dec 15 16:49:07IncorrectUsageError: Unable to find storage adapter s3 in ,/app/data/content/adapters/,/home/cloudron/ghost/versions/5.75.2/core/server/adapters/.
Dec 15 16:49:07at AdapterManager.getAdapter (/home/cloudron/ghost/versions/5.75.2/node_modules/@tryghost/adapter-manager/lib/AdapterManager.js:128:19)
Dec 15 16:49:07at Object.getAdapter (/home/cloudron/ghost/versions/5.75.2/core/server/services/adapter-manager/index.js:31:31)
Dec 15 16:49:07at Object.getStorage (/home/cloudron/ghost/versions/5.75.2/core/server/adapters/storage/index.js:14:27)
Dec 15 16:49:07at setupSiteApp (/home/cloudron/ghost/versions/5.75.2/core/frontend/web/site.js:85:71)
Dec 15 16:49:07at module.exports (/home/cloudron/ghost/versions/5.75.2/core/server/web/parent/frontend.js:22:58)
Dec 15 16:49:07at initExpressApps (/home/cloudron/ghost/versions/5.75.2/core/boot.js:248:68)
Dec 15 16:49:07at bootGhost (/home/cloudron/ghost/versions/5.75.2/core/boot.js:515:32)
Dec 15 16:49:07
Dec 15 16:49:07[2023-12-15 22:49:07] WARN Ghost is shutting down
Dec 15 16:49:07[2023-12-15 22:49:07] WARN Ghost has shut down
Dec 15 16:49:07[2023-12-15 22:49:07] WARN Your site is now offline
Dec 15 16:49:07[2023-12-15 22:49:07] WARN Ghost was running for a few seconds
Dec 15 16:49:17=> Healtheck error: Error: Timeout of 7000ms exceeded
Dec 15 16:49:27=> Healtheck error: Error: Timeout of 7000ms exceeded
The configuration is as per documentation on each adapter. Location of all adapters are: content/adapters/storage/s3. Tried different locations, though.
Anyone has an idea?
@girish I see that problem. Especially, as the quality of the storage adapter is questionable, at its best...
@robi Good point - thanks.
I am using ghost to blog. I prefer the interface over working with Wordpress. The interface, including the templates is clean and easy to use.
Since the team over at ghost decided not to build a media-manager, I prefer to not upload my media to the ghost installation itself, but to something externally.
Luckily ghost offers storage adapters for that. Sadly enough, most of them are outdated. Not even sure, they work.
The ones I found to be recent are:
The last one has been released just recently. That's great as it is cheap (starts at 1 USD / month) and has a built-in cdn, to allow for even faster page-speeds.
According to the documentation one has to add the relevant code at content/adapters/storage to make the adapter available.
Then, one has to add a snippet to the configuration, according to the documentation.
So, using the Cloudron file manager, it was quite easy to achieve:
storage underneath /content/adaptersDone.
My question to make that process a bit easier: Could we package up the storage-adapters to the ghost-base image to save the first two steps here?
Hope this helps as a guide, as well as a starting point for discussion 
Oh, interesting find. I have to check which version of node I have. Currently it seems to work fine.
Thanks for keeping us posted, here.
Adding to this, also: It is a developer tool: So the people using it, would definitely be aware of such a caveat, I guess.
I See, but that is also being said about Immich, http://immich.app. Yet, it is wonderful to use
@girish yep will give it a try. What about the networking graphs, or even the stacked ones? Is that a realistic feature to ask for? 