Comparison of tools and IDEs for NodeMCU

Here’s an evolving overview of tools and IDEs for NodeMCU. At the moment it’s my personal scratch pad for this post. I’ll eventually make it nice and shiny, I promise.

If you see your tool listed here with inaccurate information please get in touch with me so I have a chance to fix this.


Tool IDE Cloud IDE Web IDE Uploader Flasher Windows macOS Linux Technology
Esplorer X X X X Java
ESPresso X X X
“Stehlik IDE” X X X X Lua
ESPcut X X X X X
Asmodat ESP Lua Loader X X X
NodeMCU WebIDE X X X X Lua
ChiliPeppr NodeMCU X X X X CLI X X X X Python
esptool-ck CLI X X X C
Lua Loader X X Pascal
NodeMCU PyFlasher X X X X Python
NodeMCU Flasher X X Pascal
NodeMCU Tool CLI X X X X JS/Node.js CLI X X X X Python
luatool CLI X X X X Python

Types of tools

The categorization is a logical separation based on the feature set and the intended use of the tool. As you can see in the table above some tools offer features for several categories.


A “flasher” or “flashing tool” is responsible for transferring the NodeMCU firmware binary from a host system to the ESP8266 (or similar) device. In its most common form that means transferring data from a computer with USB connection over a USB cable and a USB-to-serial converter to the device. While “higher-order” modules like NodeMCU devkits, WeMos D1 mini, etc. usually have a USB-to-serial chip integrated and thus offer a USB connector the more basic modules like ESP-07, ESP-12, etc. need to be connected to an external converter.


The terms upload and download sometimes confuse inexperienced makers. The process of transferring/copying (Lua) code to a NodeMCU device is called uploading. Thus, a tool that supports that process is an “uploader”.

For a long time ESPlorer despite all its shortcomings has been the tool of choice in this category for many.


An IDE, by definition, must offer more than a limited set of features. It covers more than just a single use case. The heart of every IDE is a code editor, though. Below I further separate the available IDEs based on their deployment model.


This is (still) the default model if one talks about IDEs. You download it and run it on your computer. It allows editing Lua code and uploading that to a device. It may also offer flashing (and sometimes even building) new firmware to a device.


By “web” I mean code editing directly on the device through a web browser. This is achieved by first uploading the IDE code, one or several Lua files, to the device. Usually they then start some form of HTTP server which serves the HTML IDE GUI. Code changes are posted back to the device and stored on its file system.

–> see “Security concerns” below



–> see “Security concerns” below

Security concerns

Web and cloud IDEs must be carefully analyzed for security issues. Web IDEs running an HTTP server omit the first and most important line of defense: they operate as servers instead of clients. This should really be avoided if you release IoT nodes into the wild.

Cloud IDEs often get that right in that they operate on a publish / subscribe model. The code you write is pushed to a message queue on an external broker. The device is subscribed to the same message queue. It operates as a client and consumes & processes code updates asynchronously.

However, since you usually don’t have control over the messages exchanged between the message broker and your device this raises a whole set of new concerns. Furthermore, it makes quite a difference whether a public broker, one you might even have access to, or a closed / private / proprietary broker is used.

Leave a Reply

Your email address will not be published. Required fields are marked *