Don't do it. Customers hate it when you don't deliver clean operating system packages for the platform they run and they consider anything less unprofessional. I'm talking about enterprises and governmental institutions, not web companies.<p>Think of the consequences: while you might find "Docker" cool, by delivering your software as a "Docker" image, you are now forcing your would-be customers to come up with a "Docker" infrastructure just to be able to run your software. You would create an artificial dependency, because for OS packages they need neither additional software nor knowledge to install and run yours.
I’m thinking about doing this for my optionally self hosted SaaS. I plan to provide docker images, jar files and maybe some OS packages for common distros but I am still undecided on where to host them as the core jar files are closed source.<p>The ultimate selling point for doing this is to make it as easy as possible to get started using the product. Docker images on docker hub are the lowest friction method to run the app. (I target developers so assuming they know docker is OK)
we at croit.io do deliver our software as a ready to run docker container. In the last 2 years, no problem at all. Customers easily understand it and we got no complaints so far. Best decision ever :)
if you do it, consider releasing the image in a container format that can be executed by runtimes apart from docker (e.g. <a href="https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users" rel="nofollow">https://developers.redhat.com/blog/2019/02/21/podman-and-bui...</a> )
All the time. Docker containers are such a great distribution format. More specifically, typically a Dockerfile itself or Dockerfile along with the image as opposed to just the image (but sometimes just the image).<p>And convince them of what exactly?