• Can you show the diff with your previous WG config?
• Is 10.11.12.0/24 also on enp3s0?

I am able to connect and can ping 10.11.12.77, the IP address of the server, but nothing else

Including the wider internet, if you set your phone’s AllowedIPs to 0.0.0.0/0? This makes me think it’s a problem with the NAT, not so much wireguard. Also make sure ipv4 forwarding is enabled:

sysctl -w net.ipv4.conf.default.forwarding=1
sysctl -w net.ipv4.conf.enp3s0.forwarding=1

Reading this article might help! I know this is not what you asked, but otherwise, my approach to accessing devices on my LAN is to also include them in the WG VPN - so that they all have an IP address on the VPN subnet (in your case 10.11.13.0/24). Bonus points for excluding your LAN guests from your selfhosted subnet.

Yep I am using traefik -> nginx. I simply add the traefik tags to the nginx service. I didn’t include that in the example file to keep it simple.

As for the storage, I use SeaweedFS (has a CSI plugin, really cool, works well with nomad) but as a CSI volume it’s not suitable for backing postgres’ filesystem. The lookups are so noticeably slower that your Lemmy instance will be laggy. So I decided to use a normal host volume, so the DB writes to disk directly, and you can back that up to an S3-compatible storage with this (also cool). Could be SeaweedFS, AWS, Backblaze…

I think SeaweedFS is suitable for your pictrs storage though, be it through its S3 API (supported by pictrs) or through a SeaweedFS CSI volume that stores the files directly.

I hope that answers it! Do let me know what you end up with

Have you considered running your Lemmy instance on more than a single machine? If it is possible to run two lemmy containers anyway (ie, lemmy is not a singleton), why not run them on separate machines? With load balancing you could achieve a more stable experience. It might be cheaper to have many mediocre machines rather than a single powerful one too, as well as more sustainable long-term (vertical vs horizontal scaling).

The downside would be that the set-up would be less obvious than with Docker compose and you would probably need to get into k8s/k3s/nomad territory in order to orchestrate a proper fleet.

There are dozens of us!

• nomad fmt was applied already - granted it is not a small easy to read job file, it might be easier to split it up into separate jobs
• I will look into making this into a Pack - I have never built one because I have never shared my config like this before. I don’t know how popular they are among selfhosters either!

I think an easy first step would be to contribute a sample job file like this into the Lemmy docs website. Then people can adapt to their setups. I find there is a lot more to configure in Nomad than in Docker compose for example because you stop assuming everything will be in a single box, which changes networking considerably. There is also whether to use Consul, Vault etc.