vaultenv VS nixos

Having secrets in an external system (like Hashicorp Vault) and then using [vaultenv](https://github.com/channable/vaultenv) to inject these during `helm install/upgrade`. So you end up with something like `vaultenv ... -- helm install --set config.myvar=${VAULTENV_INJECTED_ENV_VALUE}` (or similar). Point is I use vaultenv to run helm with secrets injected as env vars only during the helm run, and use helm's `--set` flag to set individual secrets. This can get tedious if you have many secrets as you have to specify each of them individually with --set. Usually I wrap this in a Makefile or a shell script for easier invoking.

> Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.

Channable uses Consul, Vault, etc. for dynamic configuration and it works with Nix just fine.

You don't have to use static configuration files with Nix. Either fetch dynamic stuff using the Consul, Vault, etc. APIs at runtime or use a tool like vaultenv [1] or similar if you don't want this logic in your application code.

Put those tools in your systemd service before launching your app, and you're good to go.

(NB: I was DevOps teamlead at Channable while a part of this work was being done. Sad that I won't be able to see the final picture.)

[1]: https://github.com/channable/vaultenv

I don't know. Have been using colorbuddy for ages now and it has always done exactly what I want. I don't need the "instant reaload" that lush advertices, doing :source on the colorscheme file, does the same for me to preview changes instantly. This is my theme, in case you need something to start with: - https://github.com/pinpox/nixos/blob/main/home-manager/modules/nvim/lua/config/pinpox-colors.lua

I use this to serve a directory temporarily.

I can't remember why I put that workaround in there, might not be needed any more. The above config is part of my dotfiles, I use my Bose blueutooth headphones by connecting them via the blueman-applet if the don't pair automatically

Here is an example from my config : I'm using an external flake called "matrix-hook", which is a little tool I wrote and have put in a separate flake. It get's included here. I am then passing self to each of the nixosConfigurations here, this allows me to import the module from the external flake in the configuration.nix of the host where I want to use it.

Yep, I have two different modules with defaults for server and for desktop. Host-specific settings are set in the according /machines//configuration.nix file. Most stuff is modularized into modules that can be reuesed and enabled at will.

Yep, I'm using the toJSON function already. The problem I had, was that not all applications use JSON as configuration format. Also the nix code gets very long, if you have to write the whole template as a string, which I find quite unreadable. Mustache is a pretty simple frequently used templating language, here is an example template that get's rendered by the nix code above.

My system uses a uniform colorscheme defined here. Configs for all applications I use read that and use the same colors. The wallpapers are randomly generated by a tool I wrote, it also automatically matches the colorscheme. Icons and symbols are colored the same way for awesomeWM.

In case you are interested I use this and this to generate colorschemes, awesome config and a matching wallpaper

Check out wezterm it has replaced tmux for me. Very active development, fast and just the right amount of features for my taste. It is configured in Lua, so if you are doing that for neovim already, it's another plus. I use it in combination with awesomeWM. My (not very special) config is here if you need something to start with.