Yep, that's how we do it.

And (in context of your other post) actually, if you don't actually want the ISOs and are creating appliances that are closely based on ours, then another aprroach might actually be to just create your own buildtasks script?! (Instead of tweaking common).

Whilst we use buildtasks to create the various different builds, it leverages TKLpatch (it predates TKLDev and was the only way to public share build code prior to TKLDev). So assuming that you wanted to create a modified Core, you could create your own patch (in buildtasks/patches/custom-patch/) then include it in bt-container. I'd add it just below this line:

tklpatch-apply $rootfs $BT/patches/container

E.g. so it would look something like this (note the new line in the middle):

[...]
tklpatch-apply $rootfs $BT/patches/container
tklpatch-apply $rootfs $BT/patches/custom-patch
$BT/bin/rootfs-cleanup $rootfs
[...]

Then create the LXC build of your "patched" custom Core container like this:

./bt-container core-16.1-buster-amd64

No plan at present, but you could certainly build it yourself.

There are 2 ways you could go.

The first is to just start with one of them (i.e. Redis or Nginx) and install the software from the other. This is often the most direct path to getting what you want. Although unless you're familiar with Linux/Debian/etc, it's easier said than done and whilst fine for a "one off", if you want to reuse it later, then it's probably not ideal. I won't cover that any further here, but happy to discuss that at some point if you're interested.

The other option would be the "fairly easy" path you suggest (really easy if you are comfortable with Linux/Debian/bash/git/etc). This post will focus on this path. A high level view of a suggested process would look something like this:

1. Install TKLDev to a VM (not a container - download the ISO from the TKLDev app page; I suggest building Core first to ensure that everything is working as expected. Please see the how to build ISOs with TKLDev doc page for more details.
2. Clone the buildcode for both Nginx and Redis (clone both into /turnkey/fab/products).
3. Merge the 2 build code trees into one (this is the bit that is likely a bit tricky; but shouldn't be too hard - I'll give more specific notes below). I would recommend creating a new directory (in /turnkey/fab/products - perhaps /turnkey/fab/products/nginx-redis) and merge the code there (leaving the cloned repos as they are).
4. Convert new directory to a git repo and push back to GitHub (I can then give pointers on your code and help you trouble shoot any issues).
5. Build to ISO. If you want to test the ISO before building to LXC, then once again, follow the docs. Alternatively (or after successfully testing) (re)build the ISO using buildtasks. Namely the '[bt-iso'. E.g. './bt-iso nginx-redis'.
6. Build LXC container. After building the ISO, then run the bt-container script. E.g. './bt-container nginx-redis-16.0-buster-amd64'.
7. Upload LXC container to Proxmox. The container should be found in /mnt/builds/container/ and can be uploaded direct to your Proxmox server like this: 'scp /mnt/builds/container/debian-10-turnkey-nginx-redis-16.0-1_amd64.tar.gz root@PVE_SERVER:/var/lib/vz/template/cache/' (where PVE_SERVER is your Proxmox server's IP or FQDN).

A mid-lever overview of merging the build code would probably go something like this:

1. Copy overlay directory from both repos to new dir (copy one, then copy the other to the same path, so they are merged).
2. Copy any/all conf scripts from conf.d directory into your new dir. Be sure to rename any that have the same names (i.e. all the scripts from both appliances should be together in the conf.d dir). In fact, perhaps just call one 'nginx' and the other 'redis'!?
3. Merge the plans. I.e. copy the plan/main file from one appliance, then copy paste the contents of the other into it; skip/remove any duplicate lines.
4. Merge the Makefiles. Pretty much same as merging the plans.
5. Create a changelog. Something like this (note that this is a plain text file, but the layout/formatting is important):

   turnkey-nginx-redis-16.0 (1) turnkey; urgency=low
   
     * Initial release.
   
    -- Your Name <you@email.com>  Fri, 29 Oct 2021 13:34:39 +1100
   

6. Ensure all of your code is committed and push back to GitHub (so others can access it and we can look to add it as an official app).

Obviously there are lots of details missing from that, but I wanted to give you an overview of what will likely be required. I'm happy to provide more detailed info if/when required.

The other thing you could do is take the easy option and just run both (as separate servers). Sure there's a bit of redundancy, but the LXC overhead is pretty low so you probably won't even notice.