Virtual Printer¶

Send prints to Bambuddy directly from Bambu Studio or OrcaSlicer — even when your real printer is busy, offline, or doesn't exist yet.

Install Bambuddy How it works

Overview¶

The Virtual Printer feature allows Bambuddy to emulate one or more Bambu Lab printers on your network. This enables you to send prints directly from Bambu Studio or OrcaSlicer to Bambuddy, even without a physical printer connected.

You can create multiple virtual printers, each with its own dedicated IP address, mode, printer model, and access code. Each virtual printer runs completely independent services (FTP, MQTT, SSDP, Bind).

When enabled, each virtual printer:

• Can be discovered automatically via SSDP (same LAN) or added manually by IP (VPN, remote, Docker bridge)
• Accepts print jobs over secure TLS connections (MQTT + FTP)
• Archives prints directly, queues them for review, or adds them to the print queue
• Works with the same workflow as sending to a real Bambu Lab printer
• Runs on its own dedicated bind IP with independent services

Modes¶

The virtual printer supports four modes:

The first three are server modes — Bambuddy runs its own FTP/MQTT servers and receives files locally. Proxy mode is different — Bambuddy uses transparent TCP proxying to forward traffic to a real printer, with end-to-end TLS between the slicer and printer for most protocols.

Required Ports¶

Each virtual printer uses these ports on its dedicated bind IP:

Certificate Installation¶

Step 1: Locate the CA Certificate¶

The Bambuddy CA certificate is at:

• Native install: virtual_printer/certs/bbl_ca.crt
• Docker: Extract with docker cp bambuddy:/app/data/virtual_printer/certs/bbl_ca.crt ./bambuddy-ca.crt

Step 2: Append the Bambuddy CA Certificate to Slicer¶

The slicer's printer.cer file contains PEM certificates. You need to append the Bambuddy CA certificate to this file.

Open printer.cer in a text editor and:

1. Go to the end of the file
2. Paste the entire contents of bambuddy-ca.crt after the last -----END CERTIFICATE-----
3. Save the file
4. Fully restart the slicer (Cmd+Q on macOS, not just close the window)

Certificate file locations:

./Bambu_Studio_linux_*.AppImage --appimage-extract
# edit squashfs-root/usr/share/Bambu Studio/resources/cert/printer.cer
./squashfs-root/AppRun

sudo cp bbl_ca.crt /usr/local/share/ca-certificates/bambuddy-ca.crt   # extension MUST be .crt
sudo update-ca-certificates

sudo cp bbl_ca.crt /etc/pki/ca-trust/source/anchors/bambuddy-ca.crt
sudo update-ca-trust

sudo trust anchor --store bbl_ca.crt

Certificate Persistence¶

The CA certificate is generated once and persists across Bambuddy restarts. If you switch between Docker and native installations, share the certificate directory to avoid regenerating:

volumes:
  - ./virtual_printer:/app/data/virtual_printer

Multiple Bambuddy Hosts¶

Each Bambuddy installation generates its own unique CA certificate.

Option 1: Share the CA (Recommended)

Copy the certs/ directory from one host to all others:

# Copy certs from host1 to host2
scp -r host1:/path/to/virtual_printer/certs/ host2:/path/to/virtual_printer/

Then restart Bambuddy on host2. All hosts will use the same CA, so one certificate in the slicer works for all.

Option 2: Update Certificate When Switching Hosts

Each time you switch to a different Bambuddy host:

1. Extract the CA from the new host
2. Open the slicer's printer.cer file
3. Remove the old Bambuddy CA (if present) and append the new one
4. Fully restart the slicer

Tailscale Integration (Optional)¶

What this gives you¶

Secure remote access, per VP: every Tailscale-exposed VP becomes reachable from any tailnet device (laptop at work, phone on LTE, another site) over a private, end-to-end WireGuard-encrypted tunnel — without port forwarding, DDNS, reverse proxies, or exposing anything to the public internet. The slicer connects to the VP's 100.x.x.x exactly like it would a real printer on the LAN.

How it works¶

A small Go sidecar (bambuddy-tsd) runs alongside Bambuddy and embeds Tailscale's tsnet library. For every VP with the Tailscale toggle on, the sidecar:

1. Registers a node in your tailnet using the auth key from Settings → Virtual Printer → Tailscale auth key (one-time setup; reused across VPs).
2. Receives the assigned 100.x.x.x IP and bambuddy-<vp-name>.<tailnet>.ts.net hostname.
3. Forwards Tailscale-side traffic on the standard Bambu protocol ports (8883 MQTT, 990 FTPS, 322 RTSPS, 6000 file transfer, 2024–2026, 50000–50100) to a per-VP loopback target inside Bambuddy.

The sidecar is shipped inside the Docker image and as a separate binary in sidecar/tsd/bin/ for native installs. No host tailscaled, no --operator setup, no TUN device wrangling — userspace networking via tsnet handles all of it.

Setup — one-time installation auth key¶

1. Generate a reusable auth key at login.tailscale.com/admin/settings/keys. "Reusable" matters — Bambuddy uses one key to register every VP node. Tag the key as you see fit (e.g. tag:bambuddy).
2. In Bambuddy, go to Settings → Virtual Printer → Tailscale auth key, paste the key, click Save. The value is encrypted at rest using the same Fernet key as TOTP/OIDC secrets (MFA_ENCRYPTION_KEY).

That's it. The key is reused for every Tailscale-exposed VP across the lifetime of the installation. Re-issue and re-paste when it expires.

Setup — per VP¶

For each VP you want reachable over Tailscale:

1. On the VP card, flip Tailscale integration on.
2. Within a few seconds, the card shows the assigned 100.x.x.x (bambuddy-<name>-<id>.<tailnet>.ts.net) with a copy button.
3. Paste that 100.x.x.x into your slicer's Add Printer dialog.
4. (One-time) import Bambuddy's CA into the slicer if you haven't already.

Building the sidecar — native installs only¶

Docker users get the sidecar baked into the image automatically; no action needed.

For native (non-Docker) installs:

cd sidecar/tsd
make build       # produces bin/bambuddy-tsd

Bambuddy resolves the binary in this order: the BAMBUDDY_TSD_PATH env var → the co-located <repo>/sidecar/tsd/bin/bambuddy-tsd → bambuddy-tsd on $PATH. Restart the Bambuddy service after building so it picks up the binary.

When Tailscale is the right choice¶

Troubleshooting¶

Toggle flips on but the VP card doesn't show a Tailscale IP¶

The sidecar couldn't register the node. Check the Bambuddy log for entries from virtual_printer.manager and virtual_printer.tsd_client. Usual causes:

• Auth key not set — Settings → Virtual Printer → Tailscale auth key is empty. The error log says: "No Tailscale auth key configured."
• Auth key expired or single-use — Tailscale rejected the registration. Generate a new reusable key and paste it again.
• Sidecar binary missing — log line: "bambuddy-tsd binary not found; per-VP Tailscale nodes are disabled." Build with make -C sidecar/tsd build (native) or rebuild the Docker image.

How can I see the sidecar's view of the world?¶

bambuddy-tsd exposes its RPC over a Unix socket. From inside the same machine that's running Bambuddy:

# Locate the socket — defaults to <DATA_DIR>/tailscale/tsd.sock
ls /opt/bambuddy/data/tailscale/tsd.sock     # native
docker exec bambuddy ls /app/data/tailscale/tsd.sock  # Docker

# List currently registered nodes
curl --unix-socket /path/to/tsd.sock http://unix/nodes | jq

Node shows "offline" in the Tailscale admin console¶

The sidecar may have crashed or lost network. Check Bambuddy's log for "bambuddy-tsd exited unexpectedly" — that's the trigger. Restart Bambuddy; the sidecar comes back up and re-registers the nodes from the persisted state in <DATA_DIR>/tailscale/vp_<id>/. The same Tailscale identity is reused (auth key only needed on first registration).

Removing a VP doesn't remove it from the tailnet¶

Today, deleting a VP in Bambuddy tears down the running node but doesn't revoke the device entry in your tailnet admin. Remove it manually at login.tailscale.com/admin/machines. (A future release will tear down both.)

Slicer still shows "untrusted cert" / "failed to connect"¶

Expected if you skipped the CA import. Both Bambu Studio and OrcaSlicer trust only their bundled BBL CA store for printer-MQTT connections — system-trusted certs are rejected. Import Bambuddy's CA into the slicer as described above, then connect to the per-VP Tailscale IP.

FQDN copy button shows "Failed to copy"¶

navigator.clipboard is only available in secure contexts (HTTPS or localhost). On plain HTTP Bambuddy falls back to a legacy document.execCommand('copy') path. If both fail (very old browser, hostile extension), select the hostname manually and copy with Ctrl/Cmd-C.

Platform Setup¶

Choose your platform below for specific setup instructions.

Linux (Native Installation)¶

Port 990 is a privileged port. The process needs CAP_NET_BIND_SERVICE to bind to it.

For systemd services, add to the service file:

AmbientCapabilities=CAP_NET_BIND_SERVICE

For manual runs, grant the capability to the Python binary:

sudo setcap cap_net_bind_service=+ep $(readlink -f $(which python3))
    ```

**Firewall rules (if using UFW):**

```bash
sudo ufw allow 3000/tcp  # Bind/detect
sudo ufw allow 3002/tcp  # Bind/detect
sudo ufw allow 2021/udp  # SSDP
sudo ufw allow 8883/tcp  # MQTT
sudo ufw allow 990/tcp   # FTPS
sudo ufw allow 6000/tcp  # File transfer tunnel
sudo ufw allow 322/tcp   # RTSP camera (X1/H2/P2)
sudo ufw allow 2024:2026/tcp  # Proprietary slicer ports (A1/P1S)
sudo ufw allow 50000:50100/tcp  # FTP passive data

Firewall rules (if using firewalld):

sudo firewall-cmd --permanent --add-port=3000/tcp  # Bind/detect
sudo firewall-cmd --permanent --add-port=3002/tcp  # Bind/detect
sudo firewall-cmd --permanent --add-port=2021/udp  # SSDP
sudo firewall-cmd --permanent --add-port=8883/tcp  # MQTT
sudo firewall-cmd --permanent --add-port=990/tcp   # FTPS
sudo firewall-cmd --permanent --add-port=6000/tcp  # File transfer tunnel
sudo firewall-cmd --permanent --add-port=322/tcp   # RTSP camera (X1/H2/P2)
sudo firewall-cmd --permanent --add-port=2024-2026/tcp  # Proprietary slicer ports (A1/P1S)
sudo firewall-cmd --permanent --add-port=50000-50100/tcp  # FTP passive data
sudo firewall-cmd --reload

Docker (Linux)¶

Docker requires host networking for SSDP discovery to work.

docker-compose.yml:

services:
  bambuddy:
    image: ghcr.io/maziggy/bambuddy:latest
    container_name: bambuddy
    network_mode: host  # Required for SSDP discovery
    cap_add:
      - NET_BIND_SERVICE  # Required for virtual printer proxy (port 990)
    volumes:
      - bambuddy_data:/app/data
      - bambuddy_logs:/app/logs
    environment:
      - TZ=Europe/Berlin
    restart: unless-stopped

volumes:
  bambuddy_data:
  bambuddy_logs:

Firewall rules (if using UFW):

sudo ufw allow 3000/tcp  # Bind/detect
sudo ufw allow 3002/tcp  # Bind/detect
sudo ufw allow 2021/udp  # SSDP
sudo ufw allow 8883/tcp  # MQTT
sudo ufw allow 990/tcp   # FTPS
sudo ufw allow 6000/tcp  # File transfer tunnel
sudo ufw allow 322/tcp   # RTSP camera (X1/H2/P2)
sudo ufw allow 2024:2026/tcp  # Proprietary slicer ports (A1/P1S)
sudo ufw allow 50000:50100/tcp  # FTP passive data

Firewall rules (if using firewalld):

sudo firewall-cmd --permanent --add-port=3000/tcp  # Bind/detect
sudo firewall-cmd --permanent --add-port=3002/tcp  # Bind/detect
sudo firewall-cmd --permanent --add-port=2021/udp  # SSDP
sudo firewall-cmd --permanent --add-port=8883/tcp  # MQTT
sudo firewall-cmd --permanent --add-port=990/tcp   # FTPS
sudo firewall-cmd --permanent --add-port=6000/tcp  # File transfer tunnel
sudo firewall-cmd --permanent --add-port=322/tcp   # RTSP camera (X1/H2/P2)
sudo firewall-cmd --permanent --add-port=2024-2026/tcp  # Proprietary slicer ports (A1/P1S)
sudo firewall-cmd --permanent --add-port=50000-50100/tcp  # FTP passive data
sudo firewall-cmd --reload

Docker (macOS / Windows)¶

Use bridge networking with port mapping:

services:
  bambuddy:
    image: ghcr.io/maziggy/bambuddy:latest
    container_name: bambuddy
    cap_add:
      - NET_BIND_SERVICE
    ports:
      - "${PORT:-8000}:8000"           # Web UI
      - "3000:3000"                    # Bind/detect
      - "3002:3002"                    # Bind/detect (alt port)
      - "990:990"                      # FTPS
      - "6000:6000"                    # File transfer tunnel
      - "8883:8883"                    # MQTT
      - "322:322"                      # RTSP camera (X1/H2/P2)
      - "2024-2026:2024-2026"          # Proprietary slicer ports (A1/P1S)
      - "50000-50100:50000-50100"      # FTP passive data
    volumes:
      - bambuddy_data:/app/data
      - bambuddy_logs:/app/logs
    environment:
      - TZ=Europe/Berlin
      # Required for FTP passive mode behind Docker NAT:
      # Set to your Docker host's LAN IP
      #- VIRTUAL_PRINTER_PASV_ADDRESS=192.168.1.100
    restart: unless-stopped

volumes:
  bambuddy_data:
  bambuddy_logs:

Unraid¶

1. Set Network Type to host in container settings
2. No additional configuration needed — the FTP server binds directly to port 990

Synology NAS¶

1. Use Host Network in Container Manager
2. No additional configuration needed — the FTP server binds directly to port 990

TrueNAS SCALE¶

1. Use Host Network when creating the app/container
2. No additional configuration needed — the FTP server binds directly to port 990

Proxmox LXC¶

1. No special configuration needed — the FTP server binds directly to port 990
2. Ensure the LXC container runs Bambuddy as root or with CAP_NET_BIND_SERVICE

Configuration¶

Creating a Virtual Printer¶

1. Complete the platform setup above first
2. Go to Settings in Bambuddy
3. Scroll to the Virtual Printer section
4. Click Add Virtual Printer
5. Set a Name for this virtual printer
6. Choose your Mode: Immediate, Review, Print Queue, or Proxy
7. Choose the Printer Model to emulate
8. Set an Access Code (exactly 8 characters) — not needed for Proxy mode
9. Enter a Bind IP — a dedicated IP address for this virtual printer
10. Click Create, then toggle it to Enabled

You can create multiple virtual printers, each with its own mode, model, and bind IP. They appear as separate printers in your slicer.

Dedicated Bind IP¶

Each virtual printer requires its own dedicated IP address. This IP is used for all services (FTP, MQTT, SSDP, Bind) and must be unique across all enabled virtual printers.

For example, if you want to run 3 virtual printers:

You add these extra IPs as interface aliases (secondary addresses) on your network adapter. The commands below are temporary — see the persistence section for each platform to keep them across reboots.

Adding Interface Aliases¶

ip -br addr show
# Example output: eth0  UP  192.168.1.100/24

sudo ip addr add 192.168.1.101/24 dev eth0
sudo ip addr add 192.168.1.102/24 dev eth0
sudo ip addr add 192.168.1.103/24 dev eth0

ip addr show eth0
# Should show inet 192.168.1.100/24, 192.168.1.101/24, etc.

sudo apt install netplan.io

ls /etc/netplan/
# Usually 01-netcfg.yaml, 01-network-manager-all.yaml, or 50-cloud-init.yaml

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      addresses:
        - 192.168.1.101/24
        - 192.168.1.102/24
        - 192.168.1.103/24

sudo netplan apply

sudo apt install ifupdown

auto eth0:1
iface eth0:1 inet static
    address 192.168.1.101
    netmask 255.255.255.0

auto eth0:2
iface eth0:2 inet static
    address 192.168.1.102
    netmask 255.255.255.0

auto eth0:3
iface eth0:3 inet static
    address 192.168.1.103
    netmask 255.255.255.0

sudo ifup eth0:1
sudo ifup eth0:2
sudo ifup eth0:3

sudo dnf install NetworkManager

sudo pacman -S networkmanager
sudo systemctl enable --now NetworkManager

sudo nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.1.101/24"
sudo nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.1.102/24"
sudo nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.1.103/24"

# Apply (brief reconnect)
sudo nmcli con up "Wired connection 1"

ip addr add 192.168.1.101/24 dev eth0
ip addr add 192.168.1.102/24 dev eth0

echo "ip addr add 192.168.1.101/24 dev eth0" >> /boot/config/go
echo "ip addr add 192.168.1.102/24 dev eth0" >> /boot/config/go

sudo ip addr add 192.168.1.101/24 dev eth0
sudo ip addr add 192.168.1.102/24 dev eth0

apt install iproute2

net0: name=eth0,bridge=vmbr0,ip=192.168.1.100/24,gw=192.168.1.1
net1: name=eth1,bridge=vmbr0,ip=192.168.1.101/24
net2: name=eth2,bridge=vmbr0,ip=192.168.1.102/24

pct set 100 -net1 name=eth1,bridge=vmbr0,ip=192.168.1.101/24
pct set 100 -net2 name=eth2,bridge=vmbr0,ip=192.168.1.102/24

Printer Model Selection¶

Choose which Bambu printer model the virtual printer should emulate:

Network Interface Override¶

Adding to Bambu Studio / OrcaSlicer¶

Automatic Discovery¶

1. Ensure the virtual printer is enabled and running
2. In Bambu Studio/OrcaSlicer, go to Device tab
3. Click Refresh or wait for discovery
4. The virtual printer "Bambuddy" should appear
5. Click to add it, entering the access code when prompted

Manual Addition (Bind with Access Code)¶

If automatic discovery doesn't work (VPN, remote, bridge mode):

1. In Bambu Studio, go to Device → Add Printer
2. Select Add printer by IP (or Bind with access code)
3. Enter the IP address of your Bambuddy server
4. Enter the access code (8 characters)
5. The printer will be added to your device list

Sending Prints to Bambuddy¶

Server Modes (Immediate / Review / Print Queue)¶

1. Slice your model as usual
2. Select "Bambuddy" from the printer dropdown
3. Click the Send button (next to the Print button)
4. The file will be transferred to Bambuddy

What Happens Next:

• Immediate: The file is automatically archived
• Review: The file appears in Pending Uploads for you to review, assign to a project, add notes, or queue for printing
• Print Queue: The file is archived and added to the print queue as an unassigned job

Print Queue mode: Force color match¶

When Print Queue mode is selected, two toggles appear on the VP card:

• Auto-dispatch (on by default) — controls whether the queued job starts automatically or sits as manual_start until you click Start.
• Force color match (off by default — opt-in) — when on, Bambuddy parses the per-slot filament requirements out of the sliced 3MF at upload time and pins them onto the queue item. The scheduler then refuses to dispatch onto a printer that does not have the exact filament type and colour loaded.

Why this is opt-in. Without Force color match, the scheduler still validates filament type when the job is "Any [model]" assigned (so a PLA job won't auto-dispatch onto a printer with only PETG loaded), but it does not check colour — the first available printer of the target model wins. This matches Bambuddy's behaviour before the toggle existed; turning it on is strict enough that it can leave a job sitting in the queue if no printer has the right colour loaded, which is sometimes what you want and sometimes not.

When to turn it on. If you have multiple printers of the same model and care about colour accuracy — e.g. you don't want a job sliced for matte white PLA running on a printer that has black PLA loaded just because it happens to be free first.

When to leave it off. If your fleet runs the same colour on every printer of a given model, or you reload colour by hand and want the queue to keep moving regardless.

Per-VP setting (so different virtual printers can have different policies if you have a "best-fit" VP and a "first-available" VP). The default for new and existing virtual printers is off — no behaviour change for upgraders.

Live target-printer mirror in non-proxy modes¶

If you set a target printer on an Immediate / Review / Print Queue VP, the slicer sees the target printer's live state through the VP — AMS slots, FTS / dual-extruder routing, k-profiles, nozzle / bed / chamber temperatures, lights, and camera. AMS load / dry / calibration commands the user issues from the slicer pass through to the real printer. The slicer behaves as if it were directly connected to the real printer for reads and device management, while file uploads still terminate at Bambuddy and feed the queue / archive / review workflow. No second MQTT session is opened on the printer — the bridge fans out from Bambuddy's existing per-printer subscription, so the firmware in-flight budget is not affected.

This is what makes it possible to slice an FTS / dual-extruder file with the VP selected as the active device — Studio reads the target printer's nozzle diameters, AMS contents, and FTS ID through the VP and bakes the right values into the .3mf. The earlier guidance "don't slice with the VP active" no longer applies when the VP has a target printer set.

Setup: in Settings → Virtual Printer, set the target printer for each Immediate / Review / Print Queue VP. The bridge starts automatically.

Access-code requirement for camera. The slicer authenticates the camera RTSPS stream with whatever access code is stored in its profile for the device it bound to. For the camera to authenticate against the real printer, the VP's access code must match the target printer's LAN access code. Set them equal in Settings → Virtual Printer, then re-add the VP in the slicer so it picks up the new code. MQTT and FTP work either way; only the camera path needs the match because RTSPS auth happens between the slicer and the real printer's broker.

If you don't want a live mirror. Leave the target printer unset, or use the VP without binding it to a real printer at all. The slicer will see synthetic stub state and you set filaments manually — the original "file receiver" behaviour, useful when you want to slice for a class of printer without picking a specific one yet.

If you want the slicer to be in continuous live contact with a real printer — including for slicing-time hardware fields — use Proxy Mode, not a server-mode VP.

Proxy Mode¶

In Proxy mode, you use the slicer normally — slice, select the printer, and click Print or Send just like you would with a local printer. Bambuddy relays everything to the real printer transparently.

Proxy Mode — Remote Printing¶

What is Proxy Mode?¶

Unlike the server modes that archive files locally, Proxy Mode forwards your print jobs directly to a real Bambu Lab printer. Bambuddy acts as a secure relay between your slicer and your printer.

How It Works¶

1. Select the target printer in Bambuddy settings (must be in LAN mode)
2. For cross-network: select the slicer network interface for SSDP relay
3. Enable the proxy — printer appears in slicer discovery via SSDP
4. Connect using the printer's access code
5. Print as normal — traffic is relayed through Bambuddy

Proxy Mode Ports¶

Key Benefits¶

Feature	Description
TLS-encrypted control channels	End-to-end TLS for FTP, file transfer, and camera; MQTT TLS-terminated for IP rewriting
No cloud dependency	Your data never touches third-party servers
Uses printer's credentials	No additional passwords — use your printer's access code
Full protocol support	FTP, MQTT, file transfer tunnel, camera, and bind protocol
Camera streaming	RTSP camera feed proxied for X1/H2/P2 series (port 322)
Connection monitoring	Real-time status showing active connections

Requirements¶

Printer Requirements:

• Bambu Lab printer in LAN Mode (Developer Mode)
• Printer must be accessible from Bambuddy on your local network
• Printer's IP address and access code

Network Requirements:

• Bambuddy server accessible from the slicer (same LAN, VPN, or internet)
• Ports 3000 + 3002 (bind), 990 (FTP), 6000 (file transfer), 8883 (MQTT), 322 (RTSP camera), 2024-2026 (A1/P1S proprietary), and 50000-50100 (FTP data) reachable from the slicer
• Static IP or dynamic DNS for your Bambuddy server (if remote)

Supported Network Configurations:

Setting Up Proxy Mode¶

Step 1: Complete Platform Setup¶

Make sure you've completed the Platform Setup for your installation (iptables rules, firewall ports, Docker config).

Step 2: Configure Remote Access (if needed)¶

To access from outside your home network, forward these ports on your router:

Step 3: Enable Proxy Mode in Bambuddy¶

1. Go to Settings → Virtual Printer
2. Select Proxy mode from the mode options
3. Select your Target Printer from the dropdown
4. Click the toggle to Enable Virtual Printer
5. Verify the status shows "Running" with the proxy ports

Step 4: Configure Your Slicer¶

In Bambu Studio or OrcaSlicer:

1. Go to Device → Add Printer → Add printer manually
2. Enter your Bambuddy server's IP or hostname
3. Enter your printer's access code (not a Bambuddy password)
4. The printer should connect and show as online

Step 5: Print!¶

Select a model, slice it, and click Print. The job will be:

1. Sent to Bambuddy (encrypted via TLS)
2. Relayed to your printer on the local network
3. Started on your printer just like a local print

Dual-Homed (Cross-Network) Setup¶

For setups where Bambuddy has interfaces on two networks (e.g., printer on LAN A, slicer on LAN B):

• Enable the virtual printer, then select the slicer-facing interface under Network Interface Override
• Bambuddy will re-broadcast printer SSDP on the slicer's network
• The slicer discovers the printer automatically via SSDP
• All protocols are proxied including camera streaming (RTSP port 322) — no additional NAT rules needed

Proxy Mode vs Server Modes¶

Troubleshooting¶

Slicer Can't Find or Connect to Virtual Printer¶

1. Check virtual printer is enabled and showing "Running" status in Bambuddy Settings
2. Verify bind/detect ports are reachable — the slicer needs port 3000 or 3002 for the handshake:

   # From the slicer machine
   nc -zv BAMBUDDY_IP 3000
   nc -zv BAMBUDDY_IP 3002
   

3. Check firewall — ports 3000/tcp, 3002/tcp, 2021/udp, 8883/tcp, 990/tcp, 2024-2026/tcp, 50000-50100/tcp must be open
4. Same network? — SSDP discovery only works on the same LAN/subnet. Use "bind with access code" for VPN, remote, or Docker bridge setups

FTP Error / Connection Reset¶

1. Check permissions on the uploads directory
2. Check no other FTP server is using port 990
3. Verify CAP_NET_BIND_SERVICE — the process needs this capability to bind to port 990
4. Review logs for specific error messages

"Wrong Printer Model" Error¶

The slicer's selected printer profile must match the virtual printer model in Bambuddy settings.

Permission Denied Errors¶

If you see "Permission denied" in the logs:

# Fix ownership of the virtual printer directory
sudo chown -R $(whoami):$(whoami) /path/to/bambuddy/data/virtual_printer

Authentication Failed¶

1. Verify access code matches in both Bambuddy and slicer
2. Access code must be exactly 8 characters
3. Try removing and re-adding the printer in your slicer

Wrong IP in SSDP / TLS Handshake Fails (Multi-NIC)¶

If Bambuddy has multiple network interfaces (LAN + VPN, Docker bridges, etc.), the auto-detected IP may be on the wrong interface:

1. Go to Settings → Virtual Printer
2. Enable the virtual printer if not already enabled
3. Under Network Interface Override, select the interface your slicer connects through
4. The virtual printer will restart with the correct IP in SSDP broadcasts and TLS certificate

TLS Connection Failed / Error -1¶

This typically means the slicer doesn't trust the virtual printer's certificate.

1. Verify Bambuddy CA is in slicer's certificate file:

   # Check that the Bambuddy CA appears in printer.cer
   grep -c "BEGIN CERTIFICATE" "/path/to/slicer/resources/cert/printer.cer"
   

   The count should be higher than a stock install (stock has 1 certificate).

2. Wrong certificate? If you have multiple Bambuddy hosts or reinstalled, you must update the certificate. See Step 2.

3. Verify certificate fingerprints match:

   # On Bambuddy server (Docker)
   docker exec bambuddy openssl x509 -in /app/data/virtual_printer/certs/bbl_ca.crt -noout -fingerprint -sha1
   
   # On Bambuddy server (native)
   openssl x509 -in virtual_printer/certs/bbl_ca.crt -noout -fingerprint -sha1
   

   Verify this fingerprint appears in one of the certificates in your slicer's printer.cer.

4. Fully restart the slicer — Cmd+Q on macOS, or End Task on Windows. Just closing the window is not enough.

5. Regenerate certificates (last resort):

   # Delete certs and restart Bambuddy
   rm -rf /path/to/virtual_printer/certs/
   # Then disable and re-enable virtual printer in UI
   

   You'll need to remove the old Bambuddy CA from the slicer and append the new one.

Proxy Mode: Printer Shows Offline in Slicer¶

• Verify the target printer is online in Bambuddy
• Check that the printer is in LAN mode
• Restart the proxy by toggling it off and on

Proxy Mode: "Connect Using IP and Access Code" Dialog When Printing¶

If the slicer connects and shows printer status but shows a connection dialog when you click Print:

1. Check port 6000 is reachable — BambuStudio uses this port for the file transfer tunnel:

   nc -zv BAMBUDDY_IP 6000
   

2. Check firewall — port 6000/tcp must be open between slicer and Bambuddy
3. Different VLANs/subnets — the MQTT IP rewrite ensures the slicer connects to the proxy, not the printer. Check Bambuddy logs for IP rewrite active to confirm it's working

Proxy Mode: Camera Not Loading¶

• X1/H2/P2 series: Camera uses RTSP on port 322. Ensure this port is reachable from the slicer
• A1/P1 series: Camera uses port 6000 (shared with file transfer). Ensure port 6000 is reachable

Proxy Mode: Connection Drops During Transfer¶

• Large files may timeout on slow connections
• Check your internet upload speed

Technical Details¶

Security¶

• Bind protocol (ports 3000, 3002): In proxy mode, Bambuddy responds with the VP's own identity (not forwarded to printer). Unencrypted TCP — transmits printer identity only, no sensitive data
• MQTT control channel: TLS-terminated at Bambuddy (TLS 1.2). In proxy mode, printer IP addresses in MQTT payloads are rewritten to prevent the slicer from bypassing the proxy
• File transfer tunnel (port 6000): End-to-end TLS (transparent proxy)
• Camera streaming (port 322): End-to-end TLS RTSP (transparent proxy)
• Proprietary ports (ports 2024-2026): End-to-end TLS (transparent proxy). Used by A1/P1S models for slicer–printer communication
• FTP control channel: End-to-end TLS (transparent proxy)
• FTP data channel: In proxy mode, transparent proxy — encryption depends on slicer/printer negotiation. Bambu Studio does not encrypt the data channel. Use a VPN for end-to-end data encryption
• Self-signed certificates are auto-generated (shared CA persists, per-instance device cert regenerates per serial)
• Access code authentication required for all connections (8 characters)
• Certificates stored in virtual_printer/certs/ (shared CA) and virtual_printer/certs/{id}/ (per-instance certs)

Limitations¶

• Each virtual printer requires its own dedicated bind IP address
• SSDP discovery requires same LAN or routed subnets — use manual IP entry for tun-mode VPN, or Docker bridge setups
• Slicer must trust the self-signed certificate (see Certificate Installation)
• FTP data channel unencrypted on slicer side (use VPN for full encryption)
• VPN tun mode does not support SSDP broadcast — printers must be added manually by IP

Ready to try it?¶

Install Bambuddy Back to top