OrcaSlicer Fork Brings Back Bambu Network After Auth Backlash

Last week, Bambu Lab triggered a firestorm by requiring cloud authentication for local network printing. Now, a community fork of OrcaSlicer has emerged to restore full local control—and the 3D printing world is watching closely.

The Bambu Network controversy

OrcaSlicer is a popular open-source slicer for Bambu Lab printers. It communicates with the printer over the local network, offering a feature set beyond Bambu's own software. On December 20, Bambu Lab announced a firmware update that would require all print jobs—even those sent over LAN—to go through their cloud servers for authentication. The backlash was immediate and severe.

Now, a group under the FULU Foundation has forked OrcaSlicer to remove those cloud checks entirely. The fork, hosted at github.com/FULU-Foundation/OrcaSlicer-bambulab, is based on a pre-controversy commit. It effectively restores the local-only workflow that Bambu Lab had originally supported.

"This looks to be a clone of the prior state of the repository that caused all the Bambu drama earlier this week," one commenter wrote on Hacker News.

Bambu Lab's original announcement is still visible on their blog (archived). It lists "Critical Operations That Require Authorization" including binding the printer, remote video access, and all print initiation, even via LAN. The company later backpedaled on the LAN requirement, but the damage was done.

Why the Hacker News community erupted

The Hacker News thread (now at 247 points and 102 comments) captures deep frustration. Commenters point to a pattern of trust erosion. One wrote:

"A lot of the distrust toward Bambu is because they originally announced cloud auth would be required even for printing locally in LAN mode, and only backpedalled on that when they saw the backlash."

Others questioned Bambu Lab's motives: "What is Bambu’s motivation here? What do they get for damaging their credibility like this? Just usage data? Training a model on everyone’s STL files?" The community is clearly skeptical, and the fork is an explicit act of defiance.

The significance of the OrcaSlicer fork

This incident is a textbook case of what happens when a hardware company tries to lock down a device that users bought to own. Bambu Lab makes excellent printers—I've used them myself—but they've now burned a significant amount of trust. The fork isn't just about software; it's a statement that the user community will not accept arbitrary restrictions on their own hardware.

Bambu Lab's original security concerns might be valid—people do leave printers unsecured on local networks. But the solution they chose (mandatory cloud auth) was tone-deaf. They could have offered optional encryption or local authentication. Instead, they centralised control, which undermines the open, tinker-friendly ethos of the 3D printing world.

The fork itself is straightforward: it rolls back the cloud auth check and restores direct local communication. But it also raises the question of how sustainable this approach is. Bambu Lab controls the printer firmware, not the slicer. They could update the firmware to reject non-authenticated connections, sparking an arms race. For now, the fork works, but it's a fragile victory.

What this means for IoT and maker developers

If you develop tools for IoT devices, take note: users will fight for local control. Building an ecosystem that depends on your cloud will create resentment, not loyalty. Smart companies offer local-first options with optional cloud features.

For 3D printing enthusiasts, this fork is immediately useful. To use it, download the latest release from the FULU Foundation's repository, install it, and select your Bambu printer over the local network. The code change is minimal—essentially bypassing the auth token request. Here's a simplified Python example of what that looks like:

# Original Bambu Connect required a cloud token
import requests

def send_gcode(gcode, printer_ip):
    token = get_cloud_token()  # New requirement
    headers = {"Authorization": f"Bearer {token}"}
    requests.post(f"http://{printer_ip}:8899/upload", data=gcode, headers=headers)

The fork removes the token step entirely:

# Forked version: direct local connection
def send_gcode(gcode, printer_ip):
    requests.post(f"http://{printer_ip}:8899/upload", data=gcode)

Of course, this removes authentication entirely—a trade-off. If you're on a trusted network, it's fine. For security, consider segmenting your printers onto a dedicated VLAN.

Should you run the fork?

If you own a Bambu Lab printer and value the ability to print without an internet connection or company servers, yes—this fork is your lifeline. If you're a developer working on IoT products, this is a cautionary tale about pushing cloud-only models. If you're not in the 3D printing space, watch it as an example of how quickly user trust can evaporate when a company overreaches.