B
OK! I switched to configure it myself, and edited app/data/config.production.json and it works for me.
I'm unclear why this Ghost instance doesn't work and my others do, but I'm glad I can now toggle this switch -- it means none of the mail is going through Cloudron at all.
bump on this -- @nebulon @jdaviescoates, what does changing the setting in the Cloudron settings for a Ghost install do?
"Do not configure app's mail delivery settings
The app's mail delivery settings is left alone. You can configure it inside the app."
I think what this means that I can just edit the config file manually?
"mail": {
"transport": "SMTP",
"from": "Z-Space News <newsletter@example.com>",
"options": {
"host": "whatever",
"port": "2525",
"auth": {
"user": "newsletter@example.com",
"pass": "somepass"
}
}
Going to try it! Wish me luck!
you're right, there's the hidden portal settings where support email is, seems things have been shuffled.
I'm not running inbound mailboxes for any of the Ghost installs -- the working ones also have just Mailgun setup for outbound relay and use the regular ghost.app@example.com (with mailgun as smtp relay) and they work.
Yes, I read the setup and have 2 working installs of Ghost.
Yes, I have the IP address whitelisted.
The main difference here is technically I am ghost.example.com, with example.com domain linked to Cloudron, so the emails are attempting to send from example.com.
Is the 550 error from Mailgun? Or from somewhere else?
@nebulon I'm asking where / how you configure email within Ghost if I disable it from Cloudron? I have mailgun set, do I just go into Terminal and set other things there?
I have example.com where the Ghost install is hosted. I have mail.example.com setup on Mailgun and it works for the two working Ghost installs.
Sorry for what I am sure is an incredibly common post.
I have two Ghost installs that work, and one that doesn't.
There also seem to be some changes that aren't reflected in the docs at all -- no more confirmation emails etc when you change the from / reply to within Ghost itself, and there is no "support" email address anymore -- just a sender, and an optional reply-to address, per newsletter you have set up.
The one Ghost install that doesn't work gives me this:
[2025-05-14 04:08:13] ERROR Failed to send email. Reason: Mail command failed: 550 Authenticated user newsletter@example.com cannot send mail as newsletter@mail.example.com.
May 13 21:08:13
May 13 21:08:13 Failed to send email. Reason: Mail command failed: 550 Authenticated user newsletter@example.com cannot send mail as newsletter@mail.example.com
May 13 21:08:13 2025-05-14T04:08:13Z
May 13 21:08:13 "Please see https://ghost.org/docs/config/#mail for instructions on configuring email."
May 13 21:08:13 2025-05-14T04:08:13Z
And in the front end, "Failed to send magic link email"
I have outbound mail for this domain using a relay to use Mailgun SMTP settings, the same Mailgun that delivers the newsletters (which works fine, because it uses the API).
This user is "newsletter@mail.example.com" as the smtp login for Mailgun.
I have masquerading enabled.
Under the Cloudron Ghost app settings, I have "Use Cloudron Mail", I have "newsletter@example.com" set.
I have tried various different versions of this but right now I don't understand the error I'm getting. I tried a whole bunch of other things, all my other Ghost installs work fine with similar setups.
Part 2:
I note that only Ghost in Cloudron has this new option that I have seen:
Do not configure app's mail delivery settings
The app's mail delivery settings is left alone. You can configure it inside the app.
What does this do? What will it use to send the magic link email if I choose this option? Will this solve all my problems??? 
I think this is only for Ghost Pro at the moment. I have the same loading error. Interested to see when / if it is enabled for self hosters.
Hey all, thanks for recent notes. Still a good idea, probably need to find a developer who can do the packaging first.
There is an option to get email notification when apps go down.
I’ve been having degraded (yellow / restarting) core services - Postgres, MySQL, etc
Is there a way to get email notifications when those core services go down?
And — anyone have documentation on using Grafana or Prometheus to show stats for the Cloudron box where they are installled that might do something similar?
Well, apparently the only way to "fix" this, is to docker stop the yellow services Mail / Mongo / Postgres / MySQL and then restart them in the dashboard and they start up succesfully, and then you can start other apps that have been stopped.
@nebulon working on doing that. But I like have a handful of Surfer sites and one Ghost site that really needs to stay up. If Ghost or Surfer is the issue then I'm really in trouble.
Mail / Mongo / Postgres / MySQL are all at "starting" / showing as yellow...without any errors in their logs.
Box is responsive enough to work with a bit.
Hostinger CPU usage stats show stuff still pretty maxed out.
top at load average: 7.16, 9.80, 7.10
yellowtent seems to be spiking node processes over 100% CPU usage.
Happened again. Not sure what caused it, 3 days ago, had to manually kill everything with docker stop, then slowly bring things back up. Postgres definitely down. Brought things up again slowly and everything was fine.
This morning, things started dying again. Had to kill some things with docker stop, then managed to hit stop on linkding, mastodon, and nextcloud which seemed to be culprits.
Rebooted, database services struggling to come up fully. Various apps that rely on databases enter not responding.
Last week, capturing spikes and then bringing it down and it's fine, and then this morning everything gets pinned to 100%
Zoom in of load last 24 hours. I'm in there killing things again and it's just starting to shed load:
Snapshot of top
OK, I finally worked on this AGAIN and remembered how messed up this is conceptually.
username: groupname@domain
password: (any one of the passwords of the people that have access)
This is also makes Freescout work for me https://forum.cloudron.io/topic/12976/connection-could-not-be-established-with-host-mail-domain-com-connection-timed-out-110/43
A single "username" having multiple passwords is what messes me up every time.
@jdaviescoates it does not. Is +apple a setup thing in Cloudron? I've never heard of it.
So, I'm getting back to this, and logging into third party clients (notably Mail.app on MacOS), currently does not work.
email: groupname@otherdomain
user: boris@domain
password:
Mail app says "account already exists", presumably because I'm using the same user / pass.
I can put whatever I like under email address. Changing username to organizers@dwebyvr.org doesn't work.
(works fine in Snappy mail)
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E6
verify return:1
depth=0 CN = *.commonscomputer.com
verify return:1
---
Certificate chain
0 s:CN = *.commonscomputer.com
i:C = US, O = Let's Encrypt, CN = E6
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Dec 9 07:12:07 2024 GMT; NotAfter: Mar 9 07:12:06 2025 GMT
1 s:C = US, O = Let's Encrypt, CN = E6
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
Server certificate
(several more screenfuls of certs and things)
read R BLOCK
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot (Ubuntu) ready.
@girish said in Connection could not be established with host mail.domain.com [Connection timed out #110]:
openssl s_client -connect <mailsever>:993 -crlf
Since I'm using the localhost settings that HD said, I used this (note host name and alt port):
openssl s_client -connect mail:9393 -crlf
Got this response:
CONNECTED(00000003)
40A74365227F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:354:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 293 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---