Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)TO
Posts
5
Comments
133
Joined
2 yr. ago

  • I'll just start! Personally, I'm tinkering with my local network to create a subnet for my homelab.

    I want to set up Lemmy and Audiobookshelf next, but I want to tweak the infrastructure a bit before hosting more stuff.

    Before the firewall thing, I set up authentik and am integrating it in more services. Migration was mostly straightforward so far in Bookstack and Paperless. Also the proxy authentication is pretty cool, finally being able to ditch basic auth in Prometheus was cool.

  • I choose depending on whether I'll ever have to touch the files in the volume (e.g. for configuration), except for debugging where I spawn a shell. If I don't need to touch them, I don't want to see them in my config folder where the compose file is in. I usually check my compose folders into git, and this way I don't have to put the volumes into gitignore.

  • Recently set up cwa, mostly to have an easier way to get my books on my e-reader since koreader supports opds. It's been super easy so far and has a great interface, like it way better thenz calibre desktop.

  • Yes, discovering is easier on bigger instances. That's why some smaller instances subscribe to relays, where the "magazine" gets copied to every other instance on that relay.

    As soon as you follow accounts, you'll get every magazine in chronological order though.

  • you will have a much easier time setting up database and networking, running backups, porting your infrastructure to other providers, and maintaining everything, than with legacy control panels or docker compose.

    I really don't see this. Database? Same but needs a service. Networking? Services and namespaces instead of docker networks. Backups? Basically same as Docker but k8s has cronjobs so you can have it at the same place as your other stuff which is a good point. Porting infrastrutcture? Copy compose file, env files and volumes vs. copying all resources and pv.

    I am absolutely not against self hosting in k8s and if IP already had k8s running, I'd recommend it too. But I don't see the benefits for the scenario op described.

    You might be right with the better/more accessible docker docs everywhere being the main reason it's so popular, but it's also usually just one file that describes everything AND is usually the supported install method of many projects where helm charts are often third party and lack configurability.

    CNPG is cool, but then OP also needs to learn about operators and custom resources :) More efficient? Yes. More complex? Also yes.

    The biggest challenge for kubernetes is probably that the smaller applications don’t come with example configs for Kubernetes. I only see mastodon having one officially. Still, I’ve provided my config for Lemmy, and there are docker containers available for Friendica and mbin (though docker isn’t officially supported for these two). I’m happy to help give yaml examples for the installation of the applications.

    As said above, I agree it's one challenge, but added complexity is not to underestimate.

    Completely off topic: Your post did make me think about running my own cluster again though. I also work on k8s at my devops dayjob but with a cloud provider it's not the same than running your own ofc. I've also been thinking about tinkering with old smartphones in that potential cluster..

  • Don't you think recommending k8s to someone who just wants to run some services, which partly don't even have k8s support/helmcharts on the same machine is a bit too much? Compared to docker compose or whatever op is using, it's way more complex if you're not already familiar with kubernetes resources.

    I don't know much about k3s in particular admittedly, but I wouldn't recommend k8s for this unless op just wants to use it as a lab.

  • You need different Subdomains as you suggested in your first paragraph. And add a reverse proxy like nginx or caddy to the machine which then proxies the different subdomains to the respective services (e.g. lemmy.your.site to localhost:2222, mbin.your.site to localhost:3333).

    Theoretically, you could put a landing page behind some SSO/iam like authentik, and then link to the subdomains from the landing page, but eventually users will need be on the subdomain to use a specific site.

  • If you're selfhosting already, you know how to deploy it. Are those services available in the internet via some domain? Having an SSL certificate with automated renewal is quite important. Make sure to update the machine the service runs on regular.

    Backups! Having daily snapshots to be able to roll back if necessary is great. If you want to use your own hardware, I suggest Proxmox. If you want to rent a VPS, see if the cloud provider has something like that as well (will likely cost a little extra). Also, check the service's documentation on what data to back to in order to be able to restore on a new machine in case your server explodes. (3-2-1 rule). Shutting down the instance with no prior warning because of some error you can't recover from because of no working backup is the best way to spoil anyone's experience.

    If you use docker, make sure to have it behind a reverse proxy and configure your docker ports to be bound to localhost only so you don't accidentally expose your database to the internet.

    Think not only about technical deployment but also governance. Set instance rules and think how you want to do moderation. See if you have someone to help you with that.

    Go for it! Set it up, fiddle around for a while and when you get comfortable, invite your friends. Just be upfront that there might be an occasional downtime for maintenance (which you will advertise a day before or so) every now and then.

  • Yes, you get an email containing a link to your download when the requested build is done.

    This guy actually built an automated builder so people can easily request tailored images for their robots which is super cool.

  • Goals and Stretch Goals Primary Goals

     
            Accelerate development on Pixelfed (Web, Apple iOS and Android)
        Accelerate development on Loops (Web, Apple iOS and Android)
        Plan development on Sup (Apple iOS and Android)
        Expand the moderation, security, privacy and safety platforms
        Get Pixelfed/Loops/Sup translated into multiple languages
    
    
      

    Stretch Goal

     
            Full time development
        Hire additional developers
        Build a cloud/CDN platform for the Fediverse
        Register a Pixelfed Foundation as a legal entity (more details below)