So, after several attempts at experimenting with various hardware setups and FBX images, I have come to the conclusion that I would like to attempt to keep things pertaining to my FBX install (mostly) simple, safe, readily expandable, and fault tolerant, using hardware I already have.
The idea I had for doing this is to install/setup FBX in a systemd-nspawn container to a USB SSD drive, with the SSD drive being formatted to btrfs. I am using RaspiOS Bullseye on the RPi4 on SD for the system OS, mainly for compatibility, since Debian is not yet fully developed for the RPi4; this is primarily due to non free hardware/firmware issues. For more info, see: https://raspi.debian.net/. After that, I will (hopefully) be able to migrate my existing FBX install/setup to the new hardware.
I have a few questions about this before I get too involved:
- Can I run a Debian-Freedombox image in a systemd-nspawn container on a USB SSD formatted to btrfs in RaspiOS, leaving the stock filesystem intact on the SD card? (SD cards are cheap, and I have backup images ready if it fails)
- Can someone please instruct me on how to do this?
- Does anyone know of a “good” guide to follow to achieve this goal?
- What “Gotcha’s” might/will I need to address to make this happen?
- Are bridge-utils or reverse proxy software necessary for networking security?
Thanks for replies in advance! 
Update 12-18-2021:
So I have it working, Yeah!
“You are running Debian GNU/Linux 11 (bullseye) and FreedomBox version 21.4.4. FreedomBox is up to date.” Unfortunately, without “true” btrfs yet. I have it on a btrfs partition, on an external hdd mounted at /var/lib/machines, but this is not adequate for snapshots, or for the FBX spawn to recognize the filesystem for the storage module features.
Answering questions #2, and #3, I found a good guide at Setting up containers with systemd-nspawn | by Julian Harttung | Medium for setting up the container, but there is at least one thing I did differently - When invoking the container build command, I used the following: sudo debootstrap --include=systemd-container bullseye /var/lib/machines/freedombox http://deb.debian.org/debian/, I omitted the architecture statement, because on the first run I didn’t, I used --arch=armhf, and the freedombox installation did not complete, with ssh, sshd, apache, and LDAP only being half configured after install.
To answer my question #5, yes, bridge-utils are necessary, in order to create a separate external network connection through bridging, so that the FBX spawn can be seen as a separate device from the host on the network.
Update 12-24-2021: So after a week on this project, I have found that while Systemd-Nspawn is great for development and testing work, it is not suitable for secure production due to some feature limitations.
“Modern systemd-nspawn is a versatile and full-featured tool you can use for a variety of different Linux use cases, but its primary purpose is to serve as a tool for developing and testing.”
which can be found at Container Time » Linux Magazine.
So, looks like I’ll be looking for another solution…