Control Your Ender 3 Over the Network with OctoPrint on a Raspberry Pi

How many times have you sliced a model, copied it to a microSD card, walked across the room, pushed the card into the printer, and then walked back to your computer because you forgot to check the temperature? That little loop is invisible until somebody points it out, and then you cannot unsee it. OctoPrint on a Raspberry Pi deletes it: the job goes from your slicer straight to the machine over the network, and the printer becomes something you can watch, control and stop from the next room or from the other side of the city.

This is part 5 of five, and it is the one that changes how you use the printer rather than what the printer is. Part 1 printed the upgrades the machine could make for itself. Part 2 replaced the mainboard with a BIGTREETECH SKR Mini E3 V2.0. Part 3 added a BLTouch probe, and part 4 compiled the firmware that ties those two together. Everything before this point improved what the printer does with a file. This one improves how the file gets there.

A confession about the order, because it matters for how you read this: OctoPrint was one of the earliest things I added to my Ender 3, long before I ever opened the electronics bay. It sits at the end of the series by topic, not by date. The happy consequence is that you do not need any of the previous four parts to do this one. A completely stock Ender 3 gets exactly the same benefit.

What actually changes when the printer joins the network

#

The microSD card is not just an inconvenience. It is a disconnect. As long as the file travels on a card, the printer has no idea what your computer knows, and your computer has no idea what the printer is doing. Everything you want to know (is it still going, did the first layer take, how much time is left) requires you to physically go and look.

Putting a Raspberry Pi between the two closes that gap, and four things change at once:

1. Jobs travel over the network. Slice, click print, done. No card, no walking, no “did I copy the new version or the old one?”
2. You get a real terminal. Sending G-code by hand becomes trivial, which turns every calibration command in this series (M119, M303, M851, M500) into something you type instead of something you fight the LCD knob for.
3. You can watch it. A camera pointed at the bed means you can check on a six-hour print without standing next to it.
4. You can stop it. This is the one that pays for the whole project, and I will come back to it.

None of this makes prints better by itself. It makes the loop around printing shorter, and a shorter loop is what makes you willing to iterate at all.

What you need

#

• A Raspberry Pi. I use a Raspberry Pi 4. OctoPrint is not a demanding piece of software and it runs on more modest boards, but a Pi 4 leaves comfortable headroom for the web interface and a camera stream at the same time.
• A microSD card for the Pi. Mine is a 16 GB card. The OctoPi image itself is small, so 16 GB is plenty for the system and for the G-code files you keep on hand. Before you pick a size, read the timelapse section further down, because that is the one feature that will eat a card alive, and 16 GB is exactly where I ran out of room.
• A proper power supply. A Pi 4 wants 5 V at 3 A over USB-C. An underpowered Pi throws undervoltage warnings and behaves strangely in ways that look like software bugs, which is a miserable way to spend an evening.
• A USB cable from the Pi to the printer. Check which connector your board actually has before you order one, since it differs between the stock Creality board and the aftermarket 32-bit boards.
• A USB webcam, optional but strongly recommended. Mine is a generic USB webcam with no brand I can remember and no fixed mount at all. It sits wherever it can see the bed. It has still been the most useful part of this whole setup, which tells you how low the bar is here.
• Your printer’s network situation sorted. The Pi can join over Wi-Fi or Ethernet. Mine runs over Wi-Fi, which is what puts the printer wherever the printer makes sense rather than wherever the router is, and it is configured before the Pi ever boots. Ethernet is the alternative if your machine happens to sit near a switch.

Step 1: Flash OctoPi

#

There are several ways to end up with OctoPrint running. I took the simplest one: OctoPi, the official Raspberry Pi image that ships OctoPrint already installed and configured, flashed straight to a microSD card. No manual Python install, no containers, no dependency archaeology.

Use the Raspberry Pi Imager:

1. Choose your Pi model.
2. Under Choose OS, go to Other specific-purpose OS → 3D printing → OctoPi, and take the stable build.
3. Choose your microSD card.

Now the step that saves you from ever plugging a keyboard and monitor into the Pi. Before writing the image, open the Imager’s advanced options (the gear icon) and configure, at minimum:

• The hostname, which is how you will reach the machine.
• SSH enabled, with a password you actually chose.
• Wi-Fi SSID, password and country, so the Pi joins your network on its very first boot.

That last one is the whole trick. A Pi flashed this way is a headless device: you write the card, put it in, power it on, and two or three minutes later it is simply on your network waiting for you. This is the same headless-first habit that makes running any small home server pleasant instead of tedious.

Then plug the Pi into the printer over USB, power both on, and open OctoPrint in a browser. Two ways to find it:

http://octopi.local     # the mDNS name, if your network resolves it
http://192.168.1.50     # or the Pi's address on your own LAN

That address is an example, not my network. To find yours, open your router’s admin page and look at the DHCP client list, or run ipconfig (Windows) or ip addr (Linux) on a machine already connected to see which range your network uses. Consider giving the Pi a DHCP reservation in the router while you are in there, so its address never moves and your bookmark keeps working.

On first load OctoPrint runs a setup wizard: create an account, set the printer profile (bed size, heated bed, number of extruders), and you are in.

Step 2: Connect the printer over USB

#

In the Connection panel on the left of the OctoPrint interface, you pick a serial port and a baud rate. AUTO for both usually works on the first try, and OctoPrint remembers the pair it found.

If you would rather be explicit, the port shows up as a Linux device name, typically /dev/ttyUSB0 or /dev/ttyACM0 depending on the USB-to-serial chip on your board, and the baud rate for a stock Marlin build is 115200, the same BAUDRATE value quoted in part 4.

There is one firmware setting that decides whether USB works at all on the BIGTREETECH SKR Mini E3 V2.0:

#define SERIAL_PORT 2

On that board the USB port is wired to the STM32’s second serial peripheral, so port 2 is what your computer (or your Pi) talks to. Part 4 covers it in context rather than me repeating it here.

Worth being clear about the chronology, though, because it is easy to assume these two upgrades belong together: my printer ran OctoPrint against the stock Creality board for a long time before that board was ever swapped. The two are completely independent. Any board that exposes a USB serial port will talk to a Pi, and the SERIAL_PORT question only arises if you are compiling your own firmware for a board that has more than one.

When the connection succeeds, the temperature graph starts moving and the control tab comes alive. At that point you own a full G-code terminal: type M119 and read the endstop states, run M303 for a PID autotune, send M500 to save. Everything the previous parts of this series ask you to send over a serial monitor, you can now send from a browser tab.

Step 3: From Cura straight to the printer

#

This is the part that removes the microSD card from your life, and it takes about two minutes.

In Cura, open the Marketplace and install the OctoPrint Connection plugin (maintained by fieldOfView). Restart Cura, then go to Preferences → Printers, select your Ender 3, and click Connect OctoPrint.

Cura needs an API key to talk to OctoPrint. You have two routes:

• Press the “Request…” button in the plugin and approve the request in the OctoPrint web interface. This is the route I would recommend, because it issues an application key scoped to Cura instead of handing over your master key.
• Or paste the key manually, which you generate in OctoPrint’s own settings.

Treat the API key like a password. It grants control of your printer to whatever holds it. Do not paste it into a forum post when you are asking for help, do not commit it to a repository, and crop it out of any screenshot before you publish one. Nothing in this post shows one, not even a fake, precisely because a plausible-looking key is exactly the thing people copy without thinking.

Press Connect after entering or requesting the key. That last click matters: the plugin only stores the key once you connect with it.

From then on, Cura’s print button becomes Print with OctoPrint, and the sliced job is uploaded and started without a card ever entering the picture.

I still upload manually sometimes, and that is fine. When I slice on a different computer, or when I already have a G-code file that did not come out of my usual Cura setup, I just drag it into OctoPrint’s file list in the web interface and press print there. The plugin is the convenient path, not the only one, and it is worth knowing both because the manual upload works from any device with a browser, including a phone.

Step 4: The camera, and the feature that actually earns its keep

#

Plug a USB webcam into the Pi and OctoPrint picks up the stream on its own. Mine, again, is a generic webcam with no mount, propped wherever it can see the bed. I never printed a bracket for it and I never bought a better one, and it has still changed how I print.

Here is why, and it is not the reason people expect.

The value is not the novelty of watching plastic come out of a nozzle. It is that a failing print announces itself visually long before it announces itself any other way. When the part detaches and the nozzle starts dragging it around, or when the first layer clearly did not stick, you can see that in three seconds from a phone. And then you can do the thing that actually matters: cancel the print remotely.

That combination, live view plus remote abort, is the honest justification for the camera. A print that fails at hour one of six either wastes five hours of filament and machine time or it does not, and the only difference is whether somebody was able to look and press stop. I have done exactly that from outside the house more than once, and it has never once felt like a gimmick.

About Octolapse

#

OctoPrint can record a timelapse out of the box. Octolapse is the plugin that takes it further: it moves the print head out of the frame before each snapshot, so the finished video shows the model rising smoothly out of the bed with no nozzle whipping across the shot. It is the effect behind essentially every satisfying 3D printing timelapse you have ever seen.

I am going to be straight with you about this one, because I would rather be useful than impressive: I have the capability and I do not use it. The reason is storage. A timelapse means saving a frame for every layer and then rendering a video out of them, and my 16 GB card simply does not have the room for the frames and the finished files at the same time. So the feature sits there, available, unused.

That is not a criticism of Octolapse. It is a sizing decision I made without thinking it through: 16 GB is a comfortable card for running OctoPrint and a cramped one for filming it. That is exactly the kind of thing worth knowing before you buy your microSD card rather than after. If timelapses are part of why you want this project, plan the storage first.

Step 5: Watching it from outside the house

#

Everything above works on your local network. The moment you leave, it stops, and that is where remote access comes in.

You could do this with port forwarding and a reverse proxy, and I run exactly that kind of setup for other services. For a 3D printer specifically I would think twice. OctoPrint’s own documentation is unusually blunt about this, and it is right: exposing a machine that applies heat to plastic directly to the open internet is not a risk worth taking for convenience. A relay service, where the Pi opens an outbound connection to a provider and you reach it through them, avoids opening a single port on your router.

Update, 2026: I switched tools for this. When I set this printer up in October 2020 I used AstroPrint, following CrossLink’s video “Access OctoPrint from ANYWHERE with AstroPrint” (April 2020), which is the guide I genuinely worked from at the time. A few months ago, in 2026, I moved to OctoEverywhere, and that is what runs on my Pi today. To be fair to AstroPrint: it is still around and still being maintained, so this was a move on my part, not an escape. The steps below describe the tool I currently use; the AstroPrint route is recorded here as history, not as an instruction.

The current path, if you want to follow what I actually run:

1. In OctoPrint, open Settings → Plugin Manager → Get More, search for OctoEverywhere, and install it. It is in the official OctoPrint plugin repository.
2. Restart OctoPrint when it asks.
3. Follow the plugin’s link to create an account and link your printer to it.
4. Open the portal from your phone or any browser, anywhere.

What you get, per the project’s own description, is remote access to the full OctoPrint interface (plugins included), webcam streaming, and print notifications, on a free tier, without any port forwarding. The bit I care about is that the remote view is the same interface as the local one, so the cancel button is exactly where my thumb already expects it.

What this does not fix

#

I want to be honest about the boundaries of this upgrade, because “network-connected printer” sounds more transformative than it is.

You still walk over to the printer. Somebody has to pop the finished part off the bed, clear the skirt, wipe the surface and start the next job. OctoPrint eliminates the trip before the print, not the one after it.

A networked printer does not improve a bad first layer. Not one millimetre. If your bed is not level and your Z offset is wrong, OctoPrint will faithfully deliver a beautiful file to a machine that then prints it badly, and now you can watch it happen in high definition. That problem belongs to the BLTouch and the firmware, which is exactly why those are separate posts.

A camera is not failure detection. It only helps when somebody looks. It buys you the ability to catch a failure, not the guarantee.

Keeping those straight is, I think, the most useful engineering habit this project taught me. Each upgrade solves one specific problem well, and the temptation to expect a good tool to fix an unrelated problem is where a lot of wasted weekends come from.

Update, June 2026: the install aged out, and I had to reflash

#

Read this before you cut power to your Pi. This post is dated 2020, and the install it describes ran quietly for years. In June 2026 it died. The story is short, the fix is reproducible, and the lesson at the end is the one thing here that will save you a weekend.

What happened. After a power-off, the OctoPrint web interface simply never came back. The root cause was EXT4 filesystem corruption on the microSD card, caused by an unclean shutdown that had interrupted an in-place update months earlier. The damage had been sitting there quietly ever since, waiting for a reboot to expose it.

The first thing that brought the printer back was forcing a filesystem check on boot. You do that from another computer, by mounting the card’s boot partition and adding one parameter to /boot/cmdline.txt:

fsck.mode=force

That is a genuinely useful trick to know, and it worked. It is also a patch rather than a repair: it fixes the damage it can reach and tells you nothing about what else the interrupted write left behind.

Why reflashing was the right answer anyway. My original card had been built on Raspberry Pi OS Buster with Python 3.7, and both of those had long since reached end of life. The current OctoPi image is built on Bookworm with Python 3.11. An OctoPi install ages out from underneath you even when nothing goes wrong, so a card that had already corrupted itself was not worth nursing. Worth noting for your sake: this post never pinned an OctoPi version, it tells you to take the stable build in the Imager, so the instructions above did not go stale. Only my particular install did.

What the migration actually took. This is the reader-useful part, and it is the difference between an afternoon and a weekend:

1. Take an OctoPrint backup first. OctoPrint exports its own .zip from the web interface, and I pulled one off the sick install before touching anything else. If your Pi still answers at all, do this before you do anything clever.
2. Reflash the same card. I had no spare on hand, so the card that failed is the card that runs today, written fresh with the current stable OctoPi build from the Imager.
3. Restore from the backup. Settings, G-code files and plugins all came back out of that .zip, and I did the restore over Ethernet rather than Wi-Fi.

The lesson, stated plainly: always use OctoPrint’s own Shutdown command before cutting power to the Pi. Not the switch, not the plug. An SD card interrupted mid-write is exactly how this failure starts, and the interruption that killed mine happened months before the symptom appeared. Backups and a Shutdown click cost seconds; the alternative cost me an evening of diagnosis and a full rebuild.

I would rather leave this here than quietly rewrite the post as though nothing had happened. Hardware that runs for nearly six years earns a maintenance story, and treating that story as another thing to learn is more useful than pretending the setup was perfect.

Where this goes next

#

Two things are on my list, and both point outward from the printer itself.

Moving timelapse storage off the Pi. The storage limit that keeps Octolapse unused is not really a printer problem, it is a “this small computer has a small card” problem, and I already run a home server built from an old laptop whose whole purpose is holding files. Pointing the frames and rendered videos at network storage instead of at the Pi’s card is the obvious fix, and it is a nice illustration of how a home lab compounds: a machine you built for one reason quietly solves a problem you had somewhere else.

Home Assistant. Bringing the printer into the same automation layer as the rest of the house is the natural next step, and it is the piece I would build out properly rather than sketch here.

Five parts in, the Ender 3 that arrived as a kit is quieter, levels itself, runs firmware I compiled, wears parts it printed for itself, and now lives on the network. Not one of those steps required a skill I had when I started, which is really the point. Curiosity, a couple of guides open on a second screen, and a willingness to treat each failure as the next thing to learn will take you through every one of them.

Start wherever your own printer annoys you the most. That is always the right first upgrade.