I do this for sites where I don't care at all about security. One minor tip, that will protect against automated attacks if the password is cracked, is to add part of the website name into the password (e.g "mystrongp4ss!lemworld") .
A human could easily crack it, but automated systems that replay the password on different sites would probably not bother to calculate the pattern.
I also use KeepassXC and Synthing together and I am very happy with this combination.
One tip that I have, if you are worried about the security of the database file being shared, is to get 2 Yubikeys and use these, along with a strong passphrase, to protect the database file.
At $work we write closed source Rust but we do not use Kellnr.
Instead we use a mono-repo, using a workspace, that contains most of our applications and libraries.
Our setup is mostly OK but needs some workarounds for problems we have hit:
Slow cargo clean && cargo build, to speed this up we use sccache.
Very slow Docker builds. To speed these up we use cargo chef.
Slow CI/CD. To speed this up we use AWS instances as Github runners that we shutdown, but do not destroy, after use. This allows us to cache build dependencies for faster builds.
I am generally happy with our setup, but I am a fan of mono-repos. If it ever becomes to difficult to keep compiles times reasonable, I think that we would definitely look at Kellnr.
I had a second hand mid-range Samsung for about 6 months and then the USB port got destroyed. I was unable to replace the USB port so the phone is useless.
I bought a Fairphone 5 thinking that, if anything similar happened, I would NOT need to replace the phone and would save money in the long term.
Just to add to this point. I have been running a separate namespace for CI and it is possible to limit total CPU and memory use for each namespace. This saved me from having to run a VM. Everything (even junk) goes onto k8s isolated by separate namespaces.
If limits and namespaces like this are interesting to you, the k8s resources to read up on are ResourceQuota and LimitRange.
The manifest of my Kubernetes cluster is managed in a Git repository and is automatically deployed via a GitOps tool named Flux CD. When I push changes to the repository, such as adding a new application or upgrading Docker images, the deployment occurs within a few minutes.
This is the way.
Although I use Flux ImageUpdateAutomation instead of Renovate Bot. Did you consider using Flux to do auto updates? Are there any downsides that made you choose Renovate Bot instead?
Github page for the library: https://github.com/gmcgoldr/stackerror