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: Get the CA Certificate¶

You need to get the Bambuddy certificate file. The easiest way is to download it from the Bambuddy UI - no command line needed:

1. Go to Settings → Virtual Printer
2. In the Slicer certificate card, click Download to save bambuddy-virtual-printer-ca.crt, or Copy to put the PEM text on your clipboard
3. The card also shows the certificate's SHA-256 fingerprint, so you can verify later that the slicer has the right one using openssl commands below

All virtual printers for a given Bambuddy instance will share the same certificate, and it is generated automatically the first time you open the Virtual Printer settings, so you do not need to enable a virtual printer first.

Step 2: Append the Bambuddy CA Certificate to Slicer¶

The slicer's printer.cer file contains preconfigured CA certificates for communicating with printer hardware. In order for the slicer to successfully communicate with Bambuddy's virtual printers, you need to append the self-signed Bambuddy certificate to this file. Avoid removing the original certificates from the file to ensure that connections to physical printers will still work.

This process of appending the Bambuddy certificate to printer.cer will need to be repeated whenever:

• First-time setup - append the Bambuddy CA certificate as in these instructions
• After slicer updates - updates may revert to the original certificate file, requiring you to append again
• New Bambuddy installation - each Bambuddy install generates a new CA
• Switching Bambuddy hosts - each host has its own CA (unless you share the CA)

macOS¶

Once you've downloaded the Bambuddy CA certificate using the above instructions, you will append the Bambuddy certificate onto printer.cer using the commands listed below.

An alternative is to manually append the Bambuddy certificate to printer.cer with a text editor like BBEdit, Sublime Text, or VS Code, but avoid using TextEdit, which can mess with line endings or insert smart quotes.

macOS - OrcaSlicer:

# save a backup of printer.cer
cp -v /Applications/OrcaSlicer.app/Contents/Resources/cert/printer.cer \
  /Applications/OrcaSlicer.app/Contents/Resources/cert/printer.cer.bak

# ensure printer.cer has a trailing newline to avoid mangled formatting
sed -i '' '$a\' /Applications/OrcaSlicer.app/Contents/Resources/cert/printer.cer

# append bambuddy cert to printer.cer
cat ~/Downloads/bambuddy-virtual-printer-ca.crt \
  >> /Applications/OrcaSlicer.app/Contents/Resources/cert/printer.cer

Then fully quit and relaunch the slicer (Cmd+Q on macOS, not the red X).

macOS - Bambu Studio:

# save a backup of printer.cer
cp -v /Applications/BambuStudio.app/Contents/Resources/cert/printer.cer \
  /Applications/BambuStudio.app/Contents/Resources/cert/printer.cer.bak

# ensure printer.cer has a trailing newline to avoid mangled formatting
sed -i '' '$a\' /Applications/BambuStudio.app/Contents/Resources/cert/printer.cer

# append bambuddy cert to printer.cer
cat ~/Downloads/bambuddy-virtual-printer-ca.crt \
  >> /Applications/BambuStudio.app/Contents/Resources/cert/printer.cer

Then fully quit and relaunch the slicer (Cmd+Q on macOS, not the red X).

Linux¶

The location of printer.cer can vary depending on distro and/or install method. You can use find to search for it across your local filesystem:

find / -name printer.cer 2>/dev/null

Example locations include:

• /usr/share/OrcaSlicer/resources/cert/printer.cer
• /opt/bambustudio-bin/resources/cert/printer.cer
• /var/lib/flatpak/app/com.orcaslicer.OrcaSlicer/current/active/files/share/OrcaSlicer/cert/printer.cer
• etc...

# extract the filesystem:
./Bambu_Studio_linux_*.AppImage --appimage-extract

# find the file and proceed with appending to it:
find squashfs-root/ -name printer.cer

./squashfs-root/AppRun

Once you've found the location of printer.cer, you can append the Bambuddy certificate like this:

CERT_PATH=/my/path/to/resources/cert/printer.cer

# save a backup
cp -v $CERT_PATH ${CERT_PATH}.bak

# ensure printer.cer has a trailing newline to avoid mangled formatting
sudo sed -i '$a\' $CERT_PATH

# append bambuddy cert to printer.cer
sudo tee -a $CERT_PATH < bambuddy-virtual-printer-ca.crt

After updating printer.cer, fully quit and relaunch the slicer.

Windows¶

Open printer.cer from one of the following locations in a good text editor like Notepad++ or VS Code. Do not use Notepad which will mangle the file. Save an unedited backup to ensure you can still connect to physical printers if there's a problem.

• Bambu Studio: C:\Program Files\Bambu Studio\resources\cert\printer.cer
• OrcaSlicer: C:\Program Files\OrcaSlicer\resources\cert\printer.cer

After opening the file:

1. Save a backup copy to e.g. printer.cer.bak
2. Go to the end of the file
3. Paste the entire contents of bambuddy-virtual-printer-ca.crt after the last -----END CERTIFICATE-----
4. Save the file
5. Fully restart the slicer

Step 3: Verify the Append Worked¶

If the Bambuddy certificate is missing or invalid, connecting the slicer to a virtual printer can fail with a generic connection error like Connect <printer name> failed! [SN:<###>, code=-1]. In a macOS or Linux terminal, you can check the printer.cer content with a command like this, which prints a summary of all certificates in the file:

while openssl x509 -noout -subject -dates -sha256 -fingerprint; do :; done < \
  /my/path/to/printer.cer

You should see multiple entries like this:

subject=C=CN, O=BBL Technologies Co. Ltd, CN=BBL CA2 RSA
notBefore=Jun 17 01:38:08 2025 GMT
notAfter=Jun 17 01:38:08 2050 GMT
sha256 Fingerprint=[...]
[...other "BBL Technologies" entries...]
subject=CN=Virtual Printer CA
notBefore=... 2026 GMT
notAfter=... 2046 GMT
sha256 Fingerprint=...should match Bambuddy UI...

As seen above, the last entry is the Virtual Printer CA that we appended. The printed Fingerprint for that entry can be compared with the fingerprint shown in the Bambuddy Virtual Printer UI.

If the command doesn't work or the output doesn't match up, here are some possible solutions:

• Error message: If openssl x509 returns an error, the cert file is likely malformed from the edit. A common problem may just be that there are -----END CERTIFICATE----- and -----BEGIN CERTIFICATE---- headers on the same line. This problem can be fixed by manually editing the file in a text editor. Worst case, restore from printer.cer.bak and try again.
• Subject and Issuer aren't Virtual: The subject and issuer should both be Virtual Printer CA. For example if you instead see BBL Technologies Co. or similar, then maybe the Bambuddy cert wasn't appended to the file yet?
• Fingerprint doesn't match: The sha256 Fingerprint=... line above should match the SHA-256: ... fingerprint shown on Bambuddy's Settings → Virtual Printer → Slicer certificate card. If the two don't match, then maybe you have an old copy that Bambuddy has since regenerated, or a copy from a different Bambuddy instance. The above command is printing the last certificate from the file, so it may be further up. If you can't find a printer.cer file on your system, then it's possible that Bambu Studio is just using the host CA bundle.

On Linux, if printer.cer has been updated you're still seeing problems, then maybe the slicer is using the system CA bundle rather than printer.cer. You can try one of the following to add the Bambuddy certificate to the system CA store - but note that this will effectively add Bambuddy as a trusted CA for other host applications, like the browser:

Debian / Ubuntu / Mint / Raspberry Pi OS:

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

Fedora / RHEL / openSUSE:

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

Arch:

sudo trust anchor --store bambuddy-virtual-printer-ca.crt

Then fully quit and relaunch the slicer.

Multiple Bambuddy Hosts¶

Each Bambuddy installation generates its own unique CA certificate. You can deal with this by either adding each Bambuddy instance's certificate to printer.cer, or sharing the same CA keypair (bbl_ca.crt + bbl_ca.key) across the Bambuddy instances.

Option 1: Share the CA (Recommended)

Copy the certs/ directory from one Bambuddy instance to the other(s):

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

Restart Bambuddy on host2. All Bambuddy instances will use the same CA keypair, avoiding the need to append multiple certificates at the slicer.

Option 2: Update Certificate When Switching Hosts

Download the CA certificate from each Bambuddy instance, and add them all to the printer.cer file, one after the other. You can check the content of printer.cer by running the following command and comparing the listed per-cert fingerprints with the fingerprint displayed in the Virtual Printer settings UI on each Bambuddy instance:

while openssl x509 -noout -subject -dates -sha256 -fingerprint; do :; done < \
  /my/path/to/printer.cer

Certificate Persistence¶

The CA is generated once and persists across Bambuddy restarts. In Docker, keep the certs on a volume so a container recreate (or a switch between Docker and a native install) reuses the same CA instead of regenerating it — which would otherwise force you to re-append the new CA at every slicer:

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

Tailscale Integration (Optional)¶

What this gives you¶

Secure remote slicer access: when your slicer machine and the Bambuddy host are on the same tailnet, the slicer reaches Bambuddy 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 Bambuddy's 100.x.x.x exactly like it would a real printer on the LAN.

How it works¶

When at least one VP has the toggle enabled, Bambuddy invokes tailscale status --json on the host, parses Self.DNSName and Self.TailscaleIPs, and renders the result on the VP card as 100.x.x.x (your-host.<tailnet>.ts.net) with a copy button. The status is cached for 60 seconds.

Bambuddy itself does not join your tailnet — there is no Bambuddy-side sidecar and no auth-key field in Bambuddy settings. The host running tailscaled is the device in your tailnet; Bambuddy is just a process on that host reporting the host's IP to the UI.

If you run multiple VPs on one Bambuddy install, they share the same host-level Tailscale IP. Your slicer disambiguates them the same way it does on the LAN: by the per-VP serial number written into each VP's SSDP record, plus a matching slicer-side printer profile per VP.

Setup — install Tailscale on the Bambuddy host¶

Bambuddy does not run Tailscale itself; it just reads tailscale status from the host's tailscaled daemon. Setup is whatever Tailscale's normal install flow looks like for your platform.

If you already have Tailscale running on the Bambuddy host and tailscale status works, skip to Setup — per VP below. Otherwise pick your platform and follow the install steps.

curl -fsSL https://tailscale.com/install.sh | sh

sudo tailscale up

tailscale status        # should print at least your own 100.x.x.x line

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

brew install tailscale
sudo brew services start tailscale
sudo tailscale up
tailscale status

/Applications/Tailscale.app/Contents/MacOS/Tailscale status

sudo ln -s /Applications/Tailscale.app/Contents/MacOS/Tailscale /usr/local/bin/tailscale

tailscale status

services:
  bambuddy:
    # ...
    volumes:
      - /var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock

docker exec bambuddy tailscale status

Setup — install Tailscale on the slicer machine¶

Tailscale is a tunnel, not a tunnel-server — both ends need to be on the tailnet. Install Tailscale on whichever machine runs Bambu Studio / OrcaSlicer and sign it in to the same Tailscale account (or accept an invite to the host's tailnet, if you split accounts).

tailscale status
ping 100.x.x.x

tailscale status
ping 100.x.x.x

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up        # sign in to the same tailnet as the Bambuddy host
ping 100.x.x.x

Verify the connection works¶

Before you touch the slicer, confirm end-to-end reachability from the slicer machine. Open a terminal / PowerShell on the slicer machine and run:

tailscale ping 100.x.x.x         # ICMP via tailnet
curl -k https://100.x.x.x:8000/  # Bambuddy web UI

• tailscale ping should show pong within a few ms once the direct path is established (it may briefly show via DERP first while NAT traversal negotiates — that's normal and still works).
• curl -k should return the Bambuddy login page HTML. The -k is needed only until you import Bambuddy's CA into the slicer machine (see certificate installation).

If both succeed, your slicer is ready to talk to Bambuddy over Tailscale.

Setup — per VP¶

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

When Tailscale is the right choice¶

Roadmap — per-VP Tailscale identities¶

A future release may register each VP as its own node in your tailnet (each with its own 100.x.x.x and bambuddy-<vp>.<tailnet>.ts.net MagicDNS hostname) so multiple VPs are individually discoverable. That work is being scoped — track #701 and related issues.

Troubleshooting¶

Toggle is on but no Tailscale address shows on the card¶

Bambuddy couldn't reach tailscaled. Usual causes:

• Native install: tailscale is not in $PATH of the user running the Bambuddy service, or tailscaled is not running. Verify with tailscale status from the same shell environment Bambuddy runs under.
• Docker: the host's /var/run/tailscale/tailscaled.sock isn't mounted into the container. Bambuddy logs a one-time hint when it detects this — check the container log for the message starting "Running in Docker but …".
• Not logged in: tailscaled is running but the host is not authenticated (tailscale up was never run, or the device was logged out). The status query returns an empty DNSName and Bambuddy treats Tailscale as unavailable.

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 regardless of how the slicer reaches the host. Import Bambuddy's CA into the slicer as described above, then connect to the host's 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:50099/tcp  # FTP passive data (10 ports per VP from 50000; widen for >10 VPs)

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-50099/tcp  # FTP passive data (10 ports per VP from 50000; widen for >10 VPs)
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:50099/tcp  # FTP passive data (10 ports per VP from 50000; widen for >10 VPs)

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-50099/tcp  # FTP passive data (10 ports per VP from 50000; widen for >10 VPs)
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-50029:50000-50029"      # FTP passive data (3 VPs × 10-port slice; widen for more VPs; proxy mode needs 50000-50100)
    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

QNAP NAS¶

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

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

# Check your interface name with IP assigned to your NAS. Default is qvs0
ifconfig
sudo ifconfig qvs0:1 192.168.1.101 netmask 255.255.255.0 up # Example for 1st Virtual Printer
sudo ifconfig qvs0:2 192.168.1.102 netmask 255.255.255.0 up # Example for 2nd Virtual Printer

mount $(/sbin/hal_app --get_boot_pd port_id=0)6 /tmp/config
sudo sh -c 'echo "sudo ifconfig qvs0:1 192.168.1.101 netmask 255.255.255.0 up" >> /tmp/config/autorun.sh'
sudo chmod +x /tmp/config/autorun.sh
umount /tmp/config

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.

Print Queue mode: Send All on multi-plate projects¶

Bambu Studio and OrcaSlicer's Send All button on a multi-plate project uploads a single 3MF containing every plate — one FTP transfer, one filename — with slice_info.config inside listing each plate as its own <plate> block. From 0.2.5 (#1733), a Print Queue mode VP enqueues one queue item per plate when it receives a multi-plate Send All:

• Each plate becomes an independent queue row, with the plate index (plate_id = 1, 2, 3, …) taken from the 3MF
• Queue positions are consecutive in slicer plate order, so the slicer's plate sequence becomes the queue's execution sequence
• Each plate's required_filament_types and any colour overrides are computed per plate, so the scheduler's per-printer "Any [model]" matching dispatches each plate onto a printer with the right filaments loaded for that plate (not for plate 1's set)
• All plates share one archive — the single 3MF upload is archived once and every queue item references that same archive row
• The VP's auto_dispatch and manual_start posture are inherited unchanged by every plate

Single-plate Send (or Send All on a single-plate project) is unchanged — one upload, one queue item, one archive.

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.

Live print progress. While the target printer is printing, the VP mirrors its progress into the slicer's Device tab — file name, current stage, percentage, layer count, and time remaining, updated once a second (#1887). The Send button stays enabled the whole time, which is the point of a server-mode VP: you can queue the next job while the current one is still running.

That comes with one deliberate limitation. Bambu Studio and OrcaSlicer decide "this printer is busy, hide the Send button" and "this printer is printing, draw the progress bar" from the same internal flag, so a VP cannot both show a running print and accept a new one. Bambuddy resolves it in favour of accepting jobs: the progress is real, but the slicer's Pause, Resume, and Stop buttons stay greyed out for a server-mode VP. Control the running print from Bambuddy itself, or use Proxy Mode, where the slicer talks to the real printer and those buttons work normally.

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

Access-code rule (auto-managed by Bambuddy). The bridge forwards the slicer's MQTT and RTSPS auth bytes through to the real printer — the slicer holds one code in its profile (the one it bound the VP with), and that code has to satisfy both the VP's listener and the real printer at the other end of the bridge. The only way both pass is if the VP's code equals the real printer's code. Bambuddy now derives the VP's access code from the target automatically: when you pick a target printer in Settings → Virtual Printer, the VP's access-code field switches to read-only and inherits the printer's LAN access code. Changing the target re-syncs the code; re-add the VP in your slicer afterwards so it picks up the new value. Earlier Bambuddy releases let the codes diverge — a one-time startup migration silently fixes mismatched VPs on first launch after upgrade. If you didn't set a target, the VP has its own independent code (and the field is editable) — the bridge is off in that case, so there's no other side to match.

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 FTP data reachable from the slicer (10 ports per VP starting at 50000 — VP 1 = 50000-50009, etc.; proxy mode uses the full 50000-50100)
• 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¶

Setup Check¶

Every virtual printer card has a stethoscope button (next to the delete button) that runs a built-in setup diagnostic. Reach for it whenever a virtual printer doesn't show up in the slicer or won't accept a print — it checks the things that usually go wrong so you don't have to guess.

The check probes, from Bambuddy's side:

Each row is marked pass, fail, warning or skipped, with a short explanation of what to fix. After making a change, hit Run again to re-check.

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, and the FTP-data range must be open. The FTP-data range is 10 ports per VP starting at 50000 (VP 1 → 50000-50009, VP 2 → 50010-50019, etc.); proxy-mode VPs need the full 50000-50100 forwarded
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.

No Print Progress in the Slicer's Device Tab¶

1. Set a target printer on the VP (Settings → Virtual Printer). Without one there is no printer to mirror, and the slicer sees synthetic state only.
2. Check the printer is actually printing. Progress appears while the target is running or paused; an idle printer has none to show.
3. Wait a few seconds after a Send. The VP keeps reporting your own upload until the slicer has acknowledged it, then switches to the job on the bed.
4. Greyed-out Pause / Resume / Stop is expected on a server-mode VP — see Live target-printer mirror. Control the print from Bambuddy, or use Proxy Mode.

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¶

An error like Connect <printer name> failed! [SN:<###>, code=-1] 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. The Slicer certificate card in Settings → Virtual Printer shows the CA's SHA-256 fingerprint directly — the quickest reference. To read it from the server instead:

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

   Verify this fingerprint matches the one on the card, and that the CA appears 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