If you spin up a Lemmy instance and subscribe to a community, all new posts and comments inside that community will be mirrored to your instance. As I’m subscribed to around 100 different communities, that was a LOT of traffic without me doing anything. That’s why I’ve given up on self-hosting Lemmy just for myself and went back to using lemmy.ml.

However, I do self-host a GoToSocial server just for myself. It’s probably not necessary as mastodon.social isn’t going anywhere anytime soon, but if you’re on a smaller instance, it might be worth it. Also, you get to show off your own domain name. And, while other instances may block yours, your content stays online as long as YOU want it to. There’s no way for an external moderator to delete posts on your own server.

People can find you via Boosts from others or by searching for your @username@domain.com.

Maintaining my GoToSocial so far consisted of simply getting WatchTower to update the Docker container. Migration of data to a new version happens automatically. (Well, there was one accident where some pre-release version got released under the latest tag and I had to use the development branch for a few days … but that was an accident from the GtS-team and shouldn’t happen again.)

Once my DS415+ (with the C2000 fix) finally dies, I’ll most probably go with a Terramaster F4-423. They have an internal USB-port with their OS which you can replace and install a custom OS to it. And it’s basically just an Intel NUC with a storage controller in a nice package. So, pretty much compatible with the usual OSes and NAS softwares.

The usual ones are RoundCube and SnappyMail (which is a fork of deprecated RainLoop). I’m hosting SnappyMail to access my Dovecot when no other mail client is handy.

Was that an answer from ChatGPT?

Yes, I’ve set WATCHTOWER_RUN_ONCE and run it manually (letting it download and automatically apply the updates) when I find time. In the rare case something breaks, I can fix it immediately or roll back the broken container by setting the label to the previous version.

How does it compare to Adminer?

I’ve just set WatchTower to one-shot runs and whenever I have some time to fix eventual issues, I start the WatchTower container, it’ll pull any updates and stop again. No need to mess with my compose files (all set to latest) and no need for pull requests or similar.

UberSpace. Managed hosts, but you get SSH access and they have a manual for the basics as well as user-contributed guides for specifics.

It’s ran by nerds and the only limit is your allotted disk space (10GB by default). Unlimited email accounts, unlimited aliases, etc.

“Pay what you can afford” model starting at 5€/month.

Be aware that some countries make you liable for what people post on your forum.

Also, have you looked at Discourse? There are some nice apps that work with it and make the experience on mobile slightly better.

If I interpret this toot correctly, there wasn’t a direct commit from a sanctioned region, but one developer was in one of those regions for a short while quite some time ago. And he may have been flagged because of this.

MacBook Pro: mbp.domain.com
Raspberry Pi 2: rpi2.domain.com
Raspberry Pi 3: rpi3.domain.com
Raspberry Pi 4: rpi4.domain.com
Raspberry Pi 5: rpi5.domain.com
(Yes, I have one of each.)
Synology DS415+: ds415.domain.com
Phone: iphone.domain.com
Watch: watch.domain.com
AppleTV: appletv.domain.com
Nintendo Switch: switch.domain.com

Unless you’re using outdated server software, there’s nothing inherently insecure with exposing ports to the Internet. Be it port 80 or 443. Just keep everything up to date and maybe add fail2ban to stop people poking around.

Or just something as simple as using a SMB/CIFS share for your data. Instead of mounting the share before running your container, you can make Docker do it by specifying it like this:

services:
  my-service:
    ...
    volumes:
      - my-smb-share:/data:rw

volumes:
  my-smb-share:
    driver_opts:
      type: "smb3"
      device: "//mynas/share"
      o: "rw,vers=3.1.1,addr=192.168.1.20,username=mbirth,password=supersecret,cache=loose,iocharset=utf8,noperm,hard"

For type you can use anything you have a mount.<type> tool available, e.g. on my Raspberry this would be:

$ ls /usr/sbin/mount.*
/usr/sbin/mount.cifs*  /usr/sbin/mount.fuse3*       /usr/sbin/mount.nilfs2*  /usr/sbin/mount.ntfs-3g@  /usr/sbin/mount.ubifs*
/usr/sbin/mount.fuse@  /usr/sbin/mount.lowntfs-3g@  /usr/sbin/mount.ntfs@    /usr/sbin/mount.smb3@

And the o parameter is everything you would put as options to the mount command (e.g. in the 4th column in /etc/fstab). In the case of smb3, you can run mount.smb3 --help to see a list of available options.

Doing it this way, Docker will make sure the share is mounted before running the container. Also, if you move the compose file to a different host, it’ll just work if the share is reachable from that new location.