I wonder why there’s no admin instruction on how to upgrade a chatmail relay safely. I found this post but from a DevOps perspective this is far from ideal. Let me explain why:
The last official release (1.9.0) is from December 2025. But following the official instructions you always clone the “bleeding edge” main branch from GitHub and never any of the releases. So what are the releases for then?
I see that there is constant development in the chatmail repository, which is really great. But I don’t think deploying a “work in progress” repository to my production server is a good idea. In this case the recommendation “Make sure you review the changelog for any changes that need action from you.” (from the linked post) would mean I have to check all commit messages and changes and “predict” if it’s a good idea to to a redeployment or not.
Are there any thoughts on whats best practice here?
I ask especially because I repeatedly experienced some kind of “edit race condition bug” where the edit of a message on one of my devices was only synced to e.g. the phone but not to another machine which was offline during the edit. So my idea was to update the chatmailrelay first before opening a bug report.
It would be really nice to have Debian stable releases of the package. Debian stable servers are popular because they get excellent security support and are extremely low-maintenance. This would fit really well with the design goals of the software. The disadvantage of Debian stable is that new features are only added every two years or so, but for a standards-based mailserver this should not be a big problem.
I’m not a developer but as the author of the linked post and relay operator, what I meant was not to check the git commit history, but rather the file seen at relay/CHANGELOG.md at main · chatmail/relay · GitHub
There is nothing wrong if you update only when a new release is out.
Sure, but from a relay operator perspective this sounds a bit strange to me.
Currently “new” relay operators who are following the official documentation are deploying the “bleeding edge main branch” to their servers and “existing” relay operators should only update when there’s a new release? Most likely all of us are not on a “point release” currently but on the main branch from the time when we (re)deployed the server.
Would really love to see some official guidelines on this. Not to prevent errors/problems in the first place (which I did not have till know – knocking on wood ) but to ensure we as relay operators are offering a consistent and reliable service to our users.
chatmail relay contributor here. i’ve been working on some docs as i’ve had time (which is not much lately). if you want to discuss further details, my dc link is here
the lack of newer pointed releases and an updated guide/docs has been a painpoint for a while. we’ve all been iterating fast and haven’t given this the attention it deserves.
from a practical stance, i’ve yet to have a bad deployment or regression from main branch. of course don’t take my word on it, but so far i’ve not really seen regressions.
To also share my “findings” as a chatmail relay operator with the community – these are my points:
1. Can I safely run apt update; apt upgrade; apt autoremove at any time?
@ccclxxiii already answered that (the answer is: yes) and I think this is an important thing to mention this in the docs. So server admins can take care of updates like they do regularly.
2. WHEN should I redeploy?
I could redeploy as soon as the main branch changes. But that’s often the case so this would mean I’m a bleeding edge user and increase the risk of regressions or a broken deployment.
I also don’t know where to watch for new releases. Normally I subscribe to GitHub / Git releases and start deploying updates as soon as I get notified about it (and reading the CHANGELOG which brings me to the next point). But as the official docs are recommending to “pull the main branch” these releases don’t make much sense to me from a server admin perspective.
3. WHERE is the changelog?
Yes for the versioned releases on GitHub there IS a changelog. But for the main branch there isn’t (apart from Git commit messages). So as a admin I don’t know what I’m (re)deploying. This definitely should be taken care of.
4. WHAT am I running?
As there’s no versioning I run some kind of “black box”. I deployed it some day and it works since then but I have absolutely NO idea what version the used software parts are on. As a server admin I would like to have some command like cmdeploy version which gets me all versions of the software used internally (if available). So if I get to know there’s a zeroday in some component I don’t have to dig deep into my chatmail relay to see if I’m affected. I indeed could also just “wait” until “the devs” do something about it or notify me (would not know where and how). But as a trustworthy and caring server admin I want to to proactive instead of reactive work.
5. WHERE should I look for up-to-date information?
I can read the forum (and I think this is already a good “dev-to-admin” channel. But apart from that it would be helpful to have e.g. a Delta Chat channel I can subscribe to as a chatmail relay admin to be notified about issues or new updates.
For all admins reading this: There already are Chatmail operator groups. Don’t know who is managing the access to those groups but if you want access you can contact @ccclxxiii I think.
) but to ensure we as relay operators are offering a consistent and reliable service to our users.