IMO, shipping OCI images doesn't tether your backend to Docker anymore than shipping IDE configurations in your Git repository tether you to an IDE. You could t

IMO, shipping OCI images doesn't tether your backend to Docker anymore than shipping IDE configurations in your Git repository tether you to an IDE. You could tightly couple some feature to Docker, but the truth is that most of Docker's interface bits are actually pretty standard and therefore things you could find anywhere. The only real reason why Docker can't be "done" the way it is on Linux elsewhere is actually because of the unusual stable syscall interface that Linux provides; it allows the userlands ran by container runtimes to run directly against the kernel without caring too much about the userland being incompatible with the kernel. This doesn't hold for macOS, other BSDs, or Windows (though Windows does neatly abstract syscalls into system libraries, so it's not really that hard to deal with this problem on Windows, clearly.) Therefore, if you use Docker 'idiomatically', configuring with environment variables, communicating over the network, and possibly using volumes for the filesystem, it doesn't make your actual backend code any less portable. If you want to doubly ensure this, don't actually tether your build/CI directly to Docker: You can always use a standard-ish shell script or another build system for the actual build process instead.