[GH-ISSUE #170 ] [Feature]: Slicer integration (Proxy) #110

Author

Owner

@Tropaion commented on GitHub (Jan 29, 2026):

Before BambuLab introduced the shitty Bambu Connect system, bambu printers were support by OrcaSlicer, you could use it the same way as in the BambuSlicer. Directly upload the gcode and control the printer. Now, you can't do all that anymore.

It would be really nice for a way to replace that with bambuddy. So that the slicer can interact with the printer via bambuddy. OrcaSlicer supports LAN mode, so I can directly connect to the printer, but it works only locally.

I installed bambuddy with an reverse proxy, so I can access my printer from everywhere. It would be really nice if I could access the printer with the OrcaSlicer from anywhere too, which would be possible if bambuddy acts as an bridge and redirects the lan mode commands. Basically, it replaces the bambu lab cloud access.

I hope this was understandable.

@Tropaion commented on GitHub (Jan 29, 2026): Before BambuLab introduced the shitty Bambu Connect system, bambu printers were support by OrcaSlicer, you could use it the same way as in the BambuSlicer. Directly upload the gcode and control the printer. Now, you can't do all that anymore. It would be really nice for a way to replace that with bambuddy. So that the slicer can interact with the printer via bambuddy. OrcaSlicer supports LAN mode, so I can directly connect to the printer, but it works only locally. I installed bambuddy with an reverse proxy, so I can access my printer from everywhere. It would be really nice if I could access the printer with the OrcaSlicer from anywhere too, which would be possible if bambuddy acts as an bridge and redirects the lan mode commands. Basically, it replaces the bambu lab cloud access. I hope this was understandable.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 29, 2026):

Currently there are two possible ways to do that with Bambuddy:

Enable virtual printer in Bambuddy and send the file directly from the slicer to Bambuddy. You can configure what to do with the file after it was sent. This is no option, because it only works, if you are on the same LAN.
AFAIK Orcaslicer can handle post processing scripts. You could add a script that uploads the file via API call

@maziggy commented on GitHub (Jan 29, 2026): Currently there are two possible ways to do that with Bambuddy: 1. Enable virtual printer in Bambuddy and send the file directly from the slicer to Bambuddy. You can configure what to do with the file after it was sent. This is no option, because it only works, if you are on the same LAN. 2. AFAIK Orcaslicer can handle post processing scripts. You could add a script that uploads the file via API call

BreizhHardware commented

Author

Owner

@Tropaion commented on GitHub (Jan 29, 2026):

I know, that's why it is a feature request.
Virtual printer doesn't really make sense to use if it only works in LAN mode. The slicer can instead just directly connect via LAN mode to the printer (which works).

I think the easiest and nicest way would to make the LAN mode accessible via Bambuddy. The slicer directly support LAN mode, just set address of Bambuddy instead of the printer. Bambuddy "just" needs to redirect the data 1:1 to the printer.

I don't know how the LAN mode/the BambuLab environment exactly works, but I'm an programmer myself so I could help with it if you think it's doable and a useful future.

I would love it, because then I can completely remove myself from the bambu cloud.

@Tropaion commented on GitHub (Jan 29, 2026): I know, that's why it is a feature request. Virtual printer doesn't really make sense to use if it only works in LAN mode. The slicer can instead just directly connect via LAN mode to the printer (which works). I think the easiest and nicest way would to make the LAN mode accessible via Bambuddy. The slicer directly support LAN mode, just set address of Bambuddy instead of the printer. Bambuddy "just" needs to redirect the data 1:1 to the printer. I don't know how the LAN mode/the BambuLab environment exactly works, but I'm an programmer myself so I could help with it if you think it's doable and a useful future. I would love it, because then I can completely remove myself from the bambu cloud.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 29, 2026):

What's the desired network topology? Printers and Bambuddy are on the same LAN? Or not? How do you connect to the LAN? I need some more details.

@maziggy commented on GitHub (Jan 29, 2026): What's the desired network topology? Printers and Bambuddy are on the same LAN? Or not? How do you connect to the LAN? I need some more details.

BreizhHardware commented

Author

Owner

@Tropaion commented on GitHub (Jan 29, 2026):

Yes, printers and bambuddy are on the same LAN or better said, the printer must be reachable in LAN mode for bambuddy, like the normal use case now when adding a printer.

Bambuddy itself has to be reachable from outside via IP, domain or in my case vian reverse proxy and subdomain.

If you want to access from outside: Slicer access bambuddy via IP/Domain + Port where printer is emulated (for example bambuddy.com:8001 -> Printer 1, bambuddy.com:8002 -> Printer 2...). Now since bambuddy just redirects LAN mode to printer, Slicer does not know/detect bambuddy because for it, it looks like an lan mode normal printer.

The only issue I have with this setup is security. Since slicer also needs the lan mode acccess token, there is a bit of security, but I wouldn't call it secure. Easiest way is to only enable access for a limited time via the bambuddy UI or emulate the LAN mode access token and regularely change it (bambuddy acts catches the access token and handles security).

I hope it is somewhat understandable what I mean.

@Tropaion commented on GitHub (Jan 29, 2026): Yes, printers and bambuddy are on the same LAN or better said, the printer must be reachable in LAN mode for bambuddy, like the normal use case now when adding a printer. Bambuddy itself has to be reachable from outside via IP, domain or in my case vian reverse proxy and subdomain. If you want to access from outside: Slicer access bambuddy via IP/Domain + Port where printer is emulated (for example bambuddy.com:8001 -> Printer 1, bambuddy.com:8002 -> Printer 2...). Now since bambuddy just redirects LAN mode to printer, Slicer does not know/detect bambuddy because for it, it looks like an lan mode normal printer. The only issue I have with this setup is security. Since slicer also needs the lan mode acccess token, there is a bit of security, but I wouldn't call it secure. Easiest way is to only enable access for a limited time via the bambuddy UI or emulate the LAN mode access token and regularely change it (bambuddy acts catches the access token and handles security). I hope it is somewhat understandable what I mean.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Jan 29, 2026):

Got it! Interesting feature. If you are willing to help, please feel free. Otherwise I add it to the feature list to work on after the final release.

@maziggy commented on GitHub (Jan 29, 2026): Got it! Interesting feature. If you are willing to help, please feel free. Otherwise I add it to the feature list to work on after the final release.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Feb 3, 2026):

Available in 0.1.7

@maziggy commented on GitHub (Feb 3, 2026): Available in 0.1.7

BreizhHardware commented

Author

Owner

@Tropaion commented on GitHub (Feb 3, 2026):

Wow, that was really fast, didn't expect it. I will try it today.

I read that you implemented it with an proxy and tls termination. Will it work with an reverse proxy? I have one IP with many servers accessed by an reverse proxy which generates and manages all tls certificates (Caddy).

@Tropaion commented on GitHub (Feb 3, 2026): Wow, that was really fast, didn't expect it. I will try it today. I read that you implemented it with an proxy and tls termination. Will it work with an reverse proxy? I have one IP with many servers accessed by an reverse proxy which generates and manages all tls certificates (Caddy).

BreizhHardware commented

Author

Owner

@Tropaion commented on GitHub (Feb 8, 2026):

@maziggy I tried this right now. I configured the ports on my router to forward it to bambuddy, enabled proxy mode. I tried to enter my public ip in the slicer with the printer code, but I can't connect (tried BambuStudio and OrcaSlicer).

@Tropaion commented on GitHub (Feb 8, 2026): @maziggy I tried this right now. I configured the ports on my router to forward it to bambuddy, enabled proxy mode. I tried to enter my public ip in the slicer with the printer code, but I can't connect (tried BambuStudio and OrcaSlicer).

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Feb 9, 2026):

I would suggest to first test it without reverse proxy.

@maziggy commented on GitHub (Feb 9, 2026): I would suggest to first test it without reverse proxy.

BreizhHardware commented

Author

Owner

@Tropaion commented on GitHub (Feb 9, 2026):

@maziggy I wanted to use reverse proxy but I didn't because the Slicers do not support domain names (sadly, I will probably have modify the slicer code), only IP, where I used my public IP.

@Tropaion commented on GitHub (Feb 9, 2026): @maziggy I wanted to use reverse proxy but I didn't because the Slicers do not support domain names (sadly, I will probably have modify the slicer code), only IP, where I used my public IP.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Feb 9, 2026):

Well, then I need more details to debug. Please send a support package. In addition let me know your network setup (interfaces, ip addresses).

@maziggy commented on GitHub (Feb 9, 2026): Well, then I need more details to debug. Please send a support package. In addition let me know your network setup (interfaces, ip addresses).

BreizhHardware commented

Author

Owner

@Tropaion commented on GitHub (Feb 9, 2026):

My setup is:
Public IP -> Mikrotik Router (dst-nat for required ports to Bambuddy) -> Server-VLAN -> Bambuddy running in Proxmox LXC (Debian) (192.168.88.29) -> Printer (192.168.88.152)

NAT Rules:
 7    ;;; Bambuddy TCP Port Forwarding
      chain=dstnat action=dst-nat to-addresses=192.168.88.29 to-ports=990 protocol=tcp dst-address-list=PUBLIC-IP dst-port=990 log=no log-prefix="" 

 8    ;;; Bambuddy TCP Port Forwarding 2
      chain=dstnat action=dst-nat to-addresses=192.168.88.29 to-ports=8883 protocol=tcp dst-address-list=PUBLIC-IP dst-port=8883 log=no log-prefix="" 

 9    ;;; Bambuddy TCP Port Forwarding 3
      chain=dstnat action=dst-nat to-addresses=192.168.88.29 protocol=tcp dst-address-list=PUBLIC-IP dst-port=50000-50100 log=no log-prefix=""

systemd service:

[Unit]
Description=Bambuddy Backend API
After=network.target

[Service]
User=root
Group=root
WorkingDirectory=/home/bambuddy
AmbientCapabilities=CAP_NET_BIND_SERVICE

# Run uvicorn from the venv
ExecStart=/home/bambuddy/venv/bin/uvicorn backend.app.main:app --host 0.0.0.0 --port 8000

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Here is the support package:
bambuddy-support-20260209-095127.zip

I hope this is all you need.

@Tropaion commented on GitHub (Feb 9, 2026): My setup is: Public IP -> Mikrotik Router (dst-nat for required ports to Bambuddy) -> Server-VLAN -> Bambuddy running in Proxmox LXC (Debian) (192.168.88.29) -> Printer (192.168.88.152) ``` NAT Rules: 7 ;;; Bambuddy TCP Port Forwarding chain=dstnat action=dst-nat to-addresses=192.168.88.29 to-ports=990 protocol=tcp dst-address-list=PUBLIC-IP dst-port=990 log=no log-prefix="" 8 ;;; Bambuddy TCP Port Forwarding 2 chain=dstnat action=dst-nat to-addresses=192.168.88.29 to-ports=8883 protocol=tcp dst-address-list=PUBLIC-IP dst-port=8883 log=no log-prefix="" 9 ;;; Bambuddy TCP Port Forwarding 3 chain=dstnat action=dst-nat to-addresses=192.168.88.29 protocol=tcp dst-address-list=PUBLIC-IP dst-port=50000-50100 log=no log-prefix="" ``` systemd service: ``` [Unit] Description=Bambuddy Backend API After=network.target [Service] User=root Group=root WorkingDirectory=/home/bambuddy AmbientCapabilities=CAP_NET_BIND_SERVICE # Run uvicorn from the venv ExecStart=/home/bambuddy/venv/bin/uvicorn backend.app.main:app --host 0.0.0.0 --port 8000 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target ``` Here is the support package: [bambuddy-support-20260209-095127.zip](https://github.com/user-attachments/files/25179807/bambuddy-support-20260209-095127.zip) I hope this is all you need.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Feb 9, 2026):

The MQTT connection between Bambuddy and the printer is stale!

2026-02-08 20:45:15,870 WARNING [backend.app.services.bambu_mqtt] [00M[SERIAL]] Connection stale - no message for 64.4s

Let me check the logs more detailed once I finished my current task.

@maziggy commented on GitHub (Feb 9, 2026): The MQTT connection between Bambuddy and the printer is stale! >2026-02-08 20:45:15,870 WARNING [backend.app.services.bambu_mqtt] [00M[SERIAL]] Connection stale - no message for 64.4s Let me check the logs more detailed once I finished my current task.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Feb 9, 2026):

The stale MQTT warning is normal — your printer was off overnight and Bambuddy correctly detected it. It reconnected fine the next morning when you turned it on via HA.

The real issue: no slicer connections reached Bambuddy at all. The proxy is running, but there's zero evidence of any inbound connection attempts in the log. This points to a network/NAT issue, not a Bambuddy bug.

A few things to check:

Verify the proxy is listening — SSH into your LXC and run:
ss -tlnp | grep -E '990|8883'
Both ports should show LISTEN with the uvicorn/python process.
Test connectivity from outside — From a device outside your LAN, try:
openssl s_client -connect YOUR_PUBLIC_IP:990
openssl s_client -connect YOUR_PUBLIC_IP:8883
If these time out, your NAT rules aren't working.
LXC container capability — Port 990 is a privileged port (<1024). Inside a Proxmox LXC, CAP_NET_BIND_SERVICE may be restricted even if your systemd unit sets it. Check if Bambuddy fell back to a higher port or if there's a bind error in the older log files. Could you also send bambuddy.log.1 (the rotated log) so I can see the startup messages?
FTP behind NAT — This is the trickiest part. FTP PASV mode includes the server's IP address in the response. Behind NAT, this will be your LAN IP (192.168.88.29), which the remote slicer can't reach. This is a known limitation of FTP over NAT. A VPN (like WireGuard) to place the slicer on the same network would be the most reliable solution.

Please let me know. In the meantime I'll check if we can workaround the "FTP behind NAT" issue.

@maziggy commented on GitHub (Feb 9, 2026): The stale MQTT warning is normal — your printer was off overnight and Bambuddy correctly detected it. It reconnected fine the next morning when you turned it on via HA. The real issue: no slicer connections reached Bambuddy at all. The proxy is running, but there's zero evidence of any inbound connection attempts in the log. This points to a network/NAT issue, not a Bambuddy bug. A few things to check: 1. Verify the proxy is listening — SSH into your LXC and run: ss -tlnp | grep -E '990|8883' Both ports should show LISTEN with the uvicorn/python process. 2. Test connectivity from outside — From a device outside your LAN, try: openssl s_client -connect YOUR_PUBLIC_IP:990 openssl s_client -connect YOUR_PUBLIC_IP:8883 If these time out, your NAT rules aren't working. 3. LXC container capability — Port 990 is a privileged port (<1024). Inside a Proxmox LXC, CAP_NET_BIND_SERVICE may be restricted even if your systemd unit sets it. Check if Bambuddy fell back to a higher port or if there's a bind error in the older log files. Could you also send bambuddy.log.1 (the rotated log) so I can see the startup messages? 4. FTP behind NAT — This is the trickiest part. FTP PASV mode includes the server's IP address in the response. Behind NAT, this will be your LAN IP (192.168.88.29), which the remote slicer can't reach. This is a known limitation of FTP over NAT. A VPN (like WireGuard) to place the slicer on the same network would be the most reliable solution. Please let me know. In the meantime I'll check if we can workaround the "FTP behind NAT" issue.

BreizhHardware commented