Hi @jason10, I guess that depends on what development setup that your colleague is trying to achieve.
There’s no Debian version that’ll be close to balenaOS because balenaOS isn’t based on Debian, but instead built with Yocto. But if your colleague wants a dev experience where they write code on a console, then manually start a program, they can do a few things:
a) Run a Debian that’s close to whatever base image you use for your containers. So, say your Dockerfile uses
FROM balenalib/intel-nuc-debian:stretch or something like that, then you can just install Debian Stretch on the NUC and the environment will be close to the one that your app will run on. Though it might make sense to install a kernel that matches the one used by balenaOS (which you can check with
b) Run a development balenaOS image, and instead of using local mode, push a “development environment” container with your code’s git repo, which runs systemd or a dummy script to keep the container running. That way you can use ssh to run a console into this development environment, in which you can run the program to test, and commit/push changes when you want to persist them. You can also move the git repo and any other relevant state to a volume to make it persistent if the container is restarted. And you can make this development container close to the actual production image you’ll use except for the dummy start script and having the git repo instead of just the built code or binaries. You can even start an X server in the container and use the NUC as a full GUI environment.
That being said, has your colleague tried the beta “livepush” functionality of local mode? https://www.balena.io/docs/reference/cli/#--live--l It’s a new feature that does some smart things to keep a local folder synchronized with what’s running in the container. If this still doesn’t work for them, we’d love to hear the feedback from your colleague on the kind of development environment they’d like to have.