



Fair enough.
I decided against web/network-based password managers for my personal needs since the additional attack surface is a concern. A Keepass database file synced across machines strikes a good balance for me (requires password + keyfile to open). It’s also simple to backup and protect.
So yeah, for you use case, I’d recommend Aegis Authenticator.


No, I’m not interested in a password manager, thank you
Ok. But since you already use a password manager (right?), why not use its built-in TOTP management. Why do you need yet-another-separate app?
If I really had to, I’d recommend Aegis.
But I’ll still recommend using a password manager (I use KeepassXC on desktop and KeepassDX on Android).


As for the prices… well the rig I bought for ~1500€ in september is now up to ~2200€ (once-in-a-decade investment). It’s not a beast but it works, the primary use case was general computing and gaming, I’m glad it works for local AI, but costs for a dedicated, performant AI rig are ridiculously high right now. It’s not economically competitive yet against commercial LLM services for complex tasks, but that’s not the point. Check https://old.reddit.com/r/LocalLLaMA/ (yeah reddit I know). 10k€ of hardware to run ~200-300B models, not counting electricity bills
Any recommendations for a good XMPP web client?
See my requirements in other comment.
I’m in the same boat, running a Gitlab Mattermost instance for a small team.
Gitlab has not announced yet what will happen with the bundled Mattermost, but I guess it will be dropped entirely, or be hit by the new limitations (what will hit us the hardest is the 10000-most-recent messages limitation, anything further than that will be hidden behind a paywall - including messages sent before the new limitations come in effect - borderline ransomware if you ask me)
I know there are forks that remove the limitation, may end up doing that if the migration path is not too rough.
I used to run a Rocket.Chat instance for another org, became open-core bullshit as well. I’m done with this stuff.
I have a small, non-federated personal Matrix + Element instance that barely gets any use (but allows me to get a feeling of what it can do) - I don’t like it one bit. The tech stack is weird, the Element frontend receives constant updates/new releases that are painful to keep up with, and more importantly, UX is confusing and bad.
So I think I’ll end up switching this one for a XMPP server. Haven’t decided which one or which components around it precisely. I used to run prosody with thick clients a whiiille ago and it was OK. Nextcloud Talk might also work.
My needs are simple, group channels, 1-to-1 chat, posting files to a channel. ideally temporary many-to-many chats, decent web UI.
Voice capabilities would be a bonus (I run and use a mumble server and it absolutely rules once you’ve configured the client, but it doesn’t integrate properly into anything else, and no web UI), as well as some kind of integration with my Jitsi Meet instance. E2E encryption nice but not mandatory. Semi-decent mobile clients would be nice.
For now, wait and see.


unattended-upgrades doesn’t do that unless you explicitly specify Unattended-Upgrade::Automatic-Reboot "true"; in the config. Check /usr/share/doc/unattended-upgrades/README.md.gz
The main configuration file is /etc/apt/apt.conf.d/50unattended-upgrades, maybe you put your config in the wrong place?
here is mine
I use firewalld as generic firewall and fail2ban as IPS/anti-bruteforce solution (blocks IPs using firewalld’s ipsets)
I have copied the latest git revision c67b943aa894b90103c4752ac430958886b996b2 from https://gitlab.tt-rss.org/tt-rss/tt-rss to my gitea instance which is mirrored to https://gitlab.com/nodiscc/tt-rss and https://github.com/nodiscc/tt-rss.
I don’t intend to make changes or bugfixes (it’s working fine), but I will try to keep it compatible with the PHP version in Debian stable, since I’ve been using it for years and would really like to keep doing so.


A full-blown samba domain is extremely overkill if you don’t have a fleet of windows machines.
You can get centralized user management with a simple LDAP server or similar, no need for a domain.
Also, snapshots-based backups have limited uses (can’t easily restore only a single file, eats quite a bit of storage). The only times where I actually needed backups were because I fucked up a single application or database, don’t want to rollback the whole OS/data drive for that.
https://lemmy.world/post/34029848/18647964
- Hypervisor: Debian stable + libvirt or PVE if you need clustering/HA
- VMs: Debian stable
- podman if you need containerization below that
You can migrate VMs live between hosts (it’s a bit more work if you pick libvirt, but the overhead/features or proxmox are sometimes overkill, libvirt is a bit more barebones, each has its uses), have a cluster-wide L2 network, use a machine as backup storage for others… use VM snapshots for rollback, etc. Regardless of containerization/orchestration below that, a full hypervisor is still nice to have.
I deploy my services directly to the VM or as podman containers in said VMs. I use ansible for all automation/provisioning (though there are still a few basic provisioning/management to bootstrap new VMs, if it works it works)




I’m not sure of any formal name
Cloudflare turnstile
If you needs are simple, write a simple playbook using the proxmox ansible module https://docs.ansible.com/ansible/latest/collections/community/general/proxmox_kvm_module.html
Terraform/Opentofu provides more advanced stuff but then you have to worry about persistent state storage, the clunky DSL… used it when acsolutely needed, you can do 90% of this stuff with the proxmox ansible module.
If you need to make your playbook less verbose, move the logic to a role so that you can configure your VMs from a few lines in the playbook/host_vars. Mine looks like this (it’s for libvirt and not proxmox, but the logic is the same)
# playbook.yml
- hosts: hypervisor.example.org
roles:
- libvirt
# host_vars/hypervisor.example.org.yml
libvirt_vms:
- name: vm1.example.org
xml_file: "{{ playbook_dir }}/data/libvirt/vm1.example.org.xml"
state: running
autostart: yes
- name: vm2.example.org
xml_file: "{{ playbook_dir }}/data/libvirt/vm2.example.org.xml"
autostart: no
- name: vm3.example.org
xml_file: "{{ playbook_dir }}/data/libvirt/vm3.example.org.xml"
autostart: no
- name: vm4.example.org
xml_file: "{{ playbook_dir }}/data/libvirt/vm4.example.org.xml"
autostart: no
disk_size: 100G
turn that monitor off and save power?


apache can do load balancing as well https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html
I’d pick something that you already use across your stack, to minimize the number of different integration/config styles/bugs…


Not saying this is impossible, you just need to have these questions in mind, and the answers written down before you start charging people for the service, and have the support infrastructure ready.
Or you can just provide the service for free, best-effort without guarantees.
I do both (free services for a few friends, paid by customers at $work, small team). Most of the time it’s smooth riding but it needs preparation (and more than 1 guy to handle emergencies - vacations, bus factor and all that).
For the git service I can recommend gitea + gitea-actions (I run the runners in podman). Gitlab has more features but it can be overwhelming if you don’t need them, and it requires more resources.
The blurb is my own submission, since it was not so evident how the article was related to self-hosting. I am not the author of the blog post. I am a maintainer of awesome-selfhosted.