Ah, I understand. It seems there should be two separate packages for distribution under linux: “catapult”, and “ignition”, where “catapult” is everything except the context, and “ignition” is only the context (but with a dependency on “catapult”). If you incorporate the “unpack the context” function in a command line version of gcu, traditional linux package management remains possible, and your linux fans will be happy 
The command line use of gcu is critical, anyways, as it’s very common for linux servers to not have X installed at all.
Related question: can ignition be passed one or more runtime parameters to specify alternate paths for end-user data? Specifically, the server/cluster config files, project files, and/or the license file(s)? I managed to separate the wrapper config, and put it in /etc/ignition, while the balance of the app is in /usr/share/ignition. For consistency, I’d like to also put the cluster config and license in /etc/ignition, and the per-project files in /var/ignition.
The use of a package manager in linux helps distinguish between files that are supplied from trusted upstream sources, files that are locally configured by server admin types, and files that are remotely created/updated by less trusted types. This is vital information when using security software like Tripwire, et al, and is most convenient when the categories are segregated by folder.