I’m not sure how this would work, but what about the concept of cross-instance communities? For users it would be a bit like a multi-reddit where you group various communities together into one aggregate list but when posting content you’d have to choose which instance it lands on. Mods would have to agree on a set of rules (and you’d have some communities split off due to differences), but otherwise it seems somewhat plausible.

That would be one way to solve the problem of every instance having a version of one specific type of community.

Ansible vault. All my config files and scripts are deployed with Ansible. Usually they are pushing those into a file or environment variable but if you scope permissions narrowly and don’t run services/containers as root you should be somewhat safe. If someone has filesystem access you’re already in big trouble.

Instead I’d focus on keeping your attack surface as small as possible. Keep services behind a VPN or segment public facing services to a separate VLAN or docker network.

There is a community Ansible module for the Uptime-Kuma API that I’ve been trying to get working so I can trigger the maintenance window when I run my playbook to update services but I haven’t quite figured it out yet.

I’m in the same boat though, I start updating containers and my slack channel blows up for like five minutes straight.

I’ve got Uptime-Kuma internally for watching all my internal services and then I’ve got one running on a VPS that watches all the external services and public endpoints.

Such a great project and so easy to use…

FreeDNS requires you to log in to their website once a month or so to keep your DNS name active or they will revoke it. DuckDNS doesn’t require that. It’s free and it works. I set it up forever ago and never have to touch it, with FreeDNS I was risking losing my name or having my services go down if I missed their nag email.

ansible-nas

Wow, yeah this is exactly the sort of roles/playbooks that I’ve been building. I’m definitely using this as a source before starting my own from scratch. Thanks for sharing.

I’m actually doing both right now since I had quite a huge compose file that I haven’t converted to ansible yet. The biggest frustration I have is that there doesn’t seem to be an ansible module that works with compose v2 (the official plugin) which means I’m either stuck on the old version of compose or I have to use shell commands to run stuff like ‘docker compose up -d’.

One nice thing I’ve gained though is for services like Plex. I have an ‘update’ playbook that I use and it will check to see if Plex is actively streaming before updating the container which isn’t something I could do easily with compose.

Hahaha, I’ve been using ChatGPT in the exact same way. It requires a bit of double-checking but it really speeds things up a lot.

I’ve started replacing my docker compose files with pure ansible that is the equivilent of doing docker run. My ansible playbooks look almost exactly like my compose file but they can also create folders, set config files or cycle services when configs are updated.

It’s been a bit of a learning process but it’s replaced a lot what was previously documentation with code instead.

I’d recommend Duck DNS over Free DNS these days.

And Wireguard over OpenVPN.

But yes, this is the easiest free way to stand up a solid website. Only other thing I’d add is to put sites and services behind a reverse proxy. Typically I’ve used Nginx but I’m quickly becoming a Caddy convert.

I should have learned Ansible earlier.

Docker compose helped me get started with containers but I kept having to push out new config files and manually cycle services. Now I have Ansible roles that can configure and deploy apps from scratch without me even needing to back up config files at all.

Most of my documentation has gone away entirely, I don’t need to remember things when they are defined in code.

Converting my environment to be mostly containerized was a bit of a slow process that taught me a lot, but now I can try out new applications and configurations at such an accelerated rate it’s crazy. Once I got the hang of Docker (and Ansible) it became so easy to try new things, tear them down and try again. Moving services around, backing up or restoring data is way easier.

I can’t overstate how impactful containerization has been to my self hosting workflow.

Replying to confirm that this works and went very smoothly! If you can see my profile picture, it’s on S3 instead of disk now.

I’m using pure ansible to deploy my containers (instead of docker compose) so I had to figure out how to start the pictrs container without actually starting pictrs so that I could run the migration. I ended up stopping the container and then running this to perform the migration:

docker run --name pictrs-migration \
  --user 991:991 \
  -v /my-pictrs-path/:/mnt \
  --rm \
  asonix/pictrs:0.4.0-rc.14 \
  pict-rs \
    migrate-store \
    filesystem \
    object-storage \
        -e https://my-s3-endpoint \
        -b my-s3-bucket-name \
        -r my-region \
        -a my-key-id \
        -s my-key-secret

Then I used ansible to redeploy the container with volume mount removed and the new s3 environment variables.

Super easy!

Thank you for sharing this. I’m going to try to go through this migration shortly.

Right now I’m running my instance on a fairly lean VPS so being able to lighten the CPU load and not have to pre-allocate disk space is super useful.

This is mostly my strategy too. Most of the time I don’t have any issues, but occasionally I’ll jump straight to a version with breaking changes. If I have time to fix I go find the patch notes and update my config, otherwise I just tag the older version and come back later.

I’ve recently been moving my containers from docker compose into pure ansible though since I can write roles/playbooks to push config files and cycle containers which previously required multiple actions on docker compose. It’s also helped me to turn what used to be notes into actual code instead.

I’m seeing it from my own selfhosted Lemmy instance!

I picked a domain by trying to figure out which top level domains were cheap and then just seeing what stupid stuff was available.