Docker support

Thanks to the folks at Lioness, we now have a Dockerfile for the Compute project! :whale:

To try it out, follow these steps (assumes you’re running Windows Server 2019)…

  1. Make sure you’re up to date with the latest code
  2. Follow part 1. of the “Deploying Rhino Compute” guide to set up core-hour billing
  3. Open PowerShell/cmd.exe, navigate to the project’s root directory, and run these two commands to build the image and then spin up a container
> docker build --isolation process -t rhino-compute .
> docker run -p 8080:80 rhino-compute

Compute is now accessible on localhost:8080!

:warning: This information is intended for those who are already familiar with Docker, Windows containers and container orchestration. If you’re starting from scratch then I’d suggest beginning with running Compute on a Windows Server VM and go from there!


Process isolation

The Rhino installer will fail if the Docker image is built using “hyperv” isolation; we must use “process” isolation instead. The Docker file is written to work on Windows Server 2019, but can be easily modified.

February 11, 2020 security update

Microsoft’s February 11, 2020 security update has caused problems building the Compute docker image. Make sure your host OS is up to date (or at least includes the February 11, 2020 security update) and update the base images by adding the --pull flag when building (you only need to do this once).

docker build --pull --isolation process -t rhino_compute .

Is there another way to accomplish your goals?

Hi @will,
Thank you for this, it’ll be a huge time saver if I can get it to work for me.
I’m having an issue at the last step of the build. Seems like nuget restore is the culprit.
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore
Do you have any ideas?

Sorry if this sounds like a stupid question, i know what docker does but i fail to see how the perf of a vm deployment could help in using Rhino for design or productivity.

Surely it’s not computationally efficient. Installing Rhino takes minutes - i fail to see how this will economically interesting for any IT admin (how big can a studio be? (i guess this is what i dont know…).

Thanks for enlightening my ignorance. Im a sysadmin (win) in a large mixed IT environment.


I guess one use case could be automatic production chains where CAD or 3D geometry is important and can be fully or predominantly automated, maybe with a simple checklist user interface, for instance automatic production drawings for standard windows with bespoke dimensions.

The Rhino geometry part of this work could be one part of a larger ordering, manufacturing and delivery pipeline all running on Docker. The computational overhead for running in a docker be worth paying for integration in the wider pipeline, scalability, reproduceability of the system…

This is all hypothetical - I have no insider knowledge. :slight_smile:



@xavier.bury, this is specifically intended for deploying Compute or other server-side workflows that use the Rhino.Inside® technology (non-GUI implementations only).

Thanks for the answers. I didn’t know there was a non-gui version of Rhino. Learning everyday…

Hi @mkarimi, it looks like we broke the docker build a while back when we switched from packages.config to PackageReference for this project. Good news is that we now have a new Dockerfile. Please give it a try and let me know if you have any problems!


Thank you @will
This is what we were finding ourselves too, that one base image can build compute.sln and another one can install Rhino.
Great work! Thanks for sharing.

I also think you don’t really need to install or use nuget to restore the packages. You can just use /restore with msbuild.

RUN msbuild ./src/compute.sln /t:build /restore /p:Configuration=Release

1 Like

Another question @will if you don’t mind.
Is there a version of this link that gets you the latest version of Rhino WIP available?

If not, what’s your suggestion for updating Rhino in the Docker image? I believe Rhino compute will stop working once the WIP version is outdated right?

Hey @mkarimi, thanks for the /restore tip!

We don’t have a permalink to the latest Rhino WIP installer, unfortunately. This “bug” will be fixed by releasing Rhino 7! We’re working hard to get it ready. :slight_smile:

I don’t use Docker for but my process using Amazon EC2 is to launch a new instance using the current image, update Rhino, check it’s working correctly and then create a new image and deploy it to the cluster. I do this once per month which, at worst, gives us a couple of weeks to fix any bugs before the build expires. I’d like for it to be more streamlined (something that I’m sure Docker can help with!), but our server is just a proof-of-concept and I’m not a cloud expert. :wink:

1 Like

Just to be clear, the “update Rhino” part is done manually right?

Yes. I’m using regular Windows VMs so this means logging in remotely, stopping the compute service, downloading and installing the new Rhino WIP and finally restarting the service.

1 Like

I am getting a similar error of: ‘Unable to load the service index for source [C:\src\compute.sln]’ while build the dockerfile. Do you get the same issue on the latest build? I can build Rhino Compute normally using VS…

I never that issue, quick search for the error suggests it may be a firewall issue.

1 Like

Yep I ended up with the same search yesterday. It doesn’t provide a solution though…It seems the issue is docker specific. There are a few issues on github with that problem…

Ok so this is the solution.

As it turns out, Docker for Windows uses the network adapter with the lowest Id. When this adapter is deactivated, your container cannot connect to the internet.


Follow instructions here to change it if you encounter this problem. Sorry not relevant with RhinoCompute

1 Like

Ok sorry for spamming but after I build the docker image, when I run it I get:

[20:57:50 INF] Compute, Rhino 7.0.20084.11445
[20:57:50 INF] Configuration Result:
[Success] Name compute.geometry
[Success] ServiceName compute.geometry
[20:57:50 INF] Topshelf v4.1.0.172, .NET Framework v4.0.30319.42000
[20:57:50 INF] Launching RhinoCore library as ContainerAdministrator
[20:57:53 ERR] An exception occurred
System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
   at Rhino.Runtime.InProcess.RhinoCore.InternalStartup(Int32 argc, String[] argv, StartupInfo& info, IntPtr hostWnd)
   at Rhino.Runtime.InProcess.RhinoCore..ctor(String[] args, WindowStyle windowStyle, IntPtr hostWnd)
   at compute.geometry.OwinSelfHost.Start() in C:\src\compute.geometry\Program.cs:line 99
   at Topshelf.ServiceConfiguratorExtensions.<>c__DisplayClass2_0`1.<WhenStarted>b__0(T service, HostControl control)
   at Topshelf.Builders.DelegateServiceBuilder`1.DelegateServiceHandle.Start(HostControl hostControl)
   at Topshelf.Hosts.ConsoleRunHost.Run()

Any ideas? Again Rhino compute runs fine on my machine without docker.

Ah, I think the version of Rhino 7 WIP in the Dockerfile had expired. I’ve just updated the docker file to download the installer for the latest release instead.

Hmm…I thought of that and changed the Dockerfile, but it still doesn’t work. Could it be the license? I’ve done the process of retrieving it some time ago…