Run Octoprint Locally Without Server


Hi there, I am working on a research project which involves error detection and prevention of 3D printers over an industrial communication standard (OPC UA), I would like to use the full octoprint functionality but without the server, ie run a python script which queries and extracts information.

I understand that you can do this already by running octoprint locally and using a REST api to access the information and upload files etc.

Has someone developed a solution where you can run octoprint without the server, as querying the server through HTTP is inefficient as we just need to be able to access the information locally, not on any other clients.




Why not run this as OctoPi on a Raspberry Pi 3B...

...and don't talk to the web interface?

Write a client to talk to the REST API and you're done.


would the client still not be communicating through HTTP? I wish for a client to connect with the raspberry pi through OPC UA so only need the information locally on the raspberry pi to put into the OPC UA nodes.

I have written a client which uses the REST API to extract the information from octoprint, but still has to communicate through HTTP? which takes time, ideally just gathering and extracting through octoprint purely through serial communications would be ideal.

Or have I got my logic abit wrong?



"OctoPrint without the server" is like saying "fondue without the cheese", in my humble opinion. But I am rather opinionated now that I'm older.

I can't honestly speak for foosel but my take on OctoPrint is that it's a fairly robust service which offers an HTTP/HTTPS interface for both browsers and web API clients. It's also a pretty awesome platform which allows upgrades in place, the development and addition of plugins of all kinds. It's quite good at interfacing with Marlin- and Repetier-based printer boards. It houses an embedded Cura slicer and Gcode visualizer. The wealth of existing web-based plugins allow IoT solutions too easy to even mention.

But all this is a framework that's rather tightly involved with that webserver, at least that's my take on it.

Python is definitely involved. I doubt that you can strip away haproxy, the webserver, the Plugin Manager and all the other plugins and have it still function. But foosel's the last word on that one.

The OPC-UA is 14 documents at over 1200 pages in length. Inside my head is a little chart that I go by and it reasonably suggests that nothing will ever succeed that requires 1200 pages to describe it in the world of open source. I haven't really thought about it until now but the chart should be labeled KISS.

You might consider using the Python language to spin up your own project, talk to a printer controller board and present itself as an OPC-UA node. Start from scratch. Scaffold something which connects into the network and which talks "Marlin" to a printer board.

npmjs for OPC = zero hits
github python opcua code = perhaps 25


I wrote an OPC-UA node server which will query the printer's API and respond via this interface.


Cheers for your help and the discussion really appreciate it, because my project isnt solely focused on the OPC UA end I think I will continue with the API route.

I'll have a look at the OPC UA node server.



I'm still confused as to what you want to use and what not and what you want to achieve in the first place :thinking: What's your end goal here, what kind of functionality from OctoPrint do you want to utilize, and which bits do you want to get rid of precisely?

OctoPrint pretty much is the server. The UI is pretty much "only" a whole ton of JS interacting with it (and I've in fact been meaning to extract that into its own bundled plugin). If you strip away the server you are left with nothing.

If all you need is an embeddable GCODE sender, take a look at pronterface, they have a library component. But I'm unclear on whether you even want that. So more details please :wink:

Hah! Can I quote you on this! :smiley:


Yes, you may. :wink:

Imagine an industrial space like this:

Each of the stations is a node which runs OPC-UA.


Imagine an interface that looks like that and a REST-ish interface begins at that point. Other machines could query /UA/brosename/version and fetch back 1.3.9rc2 in this case if it were OctoPi as the endpoint.

The purpose would be to automate a line of 3D printers, automated pulling equipment, automated finishing equipment, conveyors, etc.

The companies behind this are Honeywell and others with deep pockets. I don't see any reason why the open source world should be providing this solution to industry because industry doesn't freely give back; they always charge and it's never cheap.


An embeddable GCODE senders is pretty much what I require, I'll look into it.

Cheers for the discussion!!


Just to clarify this is for a university project, but yea you are right that is the end goal.