Skip to content

Auto Start

GhostTypes edited this page Jul 24, 2026 · 1 revision

Auto Start

FlashForgeUI can launch itself automatically when you sign in, so your printers and the WebUI are ready without you opening the app.

Windows & macOS

Two settings in Settings do everything — no manual setup required:

  • Start with system — launches FlashForgeUI when you log in.
  • Start minimized — starts it to the tray instead of opening a window (requires the tray icon to be enabled).

Both are registered through the OS's native login-item mechanism (Windows run-key / macOS Login Items). Toggle them on and you're done.

Linux

The same Start with system / Start minimized settings work on Linux. "Start with system" writes a standard freedesktop autostart entry to ~/.config/autostart/flashforgeui.desktop (or $XDG_CONFIG_HOME/autostart/ if you set that variable). Every major desktop environment honors it — GNOME, KDE, XFCE, Cinnamon, MATE — so it behaves the same on any distro. Turning the setting off deletes the file.

The one Linux-specific thing to know is the AppImage + Ubuntu 24.04 sandbox situation below. It does not stop auto-start from working, but it affects whether the app launches sandboxed.

"Start minimized" caveats

  • "Start minimized" only applies to sessions the system auto-launched; launching FlashForgeUI yourself always shows the window.
  • Some environments ignore minimize requests. Wayland has no "minimized" window state, so the window may simply open normally — use the tray icon to get back to it.
  • On GNOME, tray icons require the AppIndicator extension. Without it the icon won't appear, though relaunching FlashForgeUI always brings the existing window to the front.

Sandbox / AppArmor on Ubuntu 24.04+

Ubuntu 23.10+ ships kernel.apparmor_restrict_unprivileged_userns=1, which blocks unprivileged programs from creating user namespaces. Chromium (which Electron is built on) needs either those namespaces or a root-owned chrome-sandbox helper to sandbox itself, and granting the permission back requires an AppArmor profile — which needs root to install.

Whether you have to do anything depends on which package you installed:

You installed Do you need to set anything up?
.deb or .rpm No. The profile is installed for you.
.AppImage Only if you want the sandbox on. It runs unsandboxed otherwise.

Installed from the .deb or .rpm — nothing to set up

The package installs an AppArmor profile to /etc/apparmor.d/FlashForgeUI during installation and loads it, so FlashForgeUI runs fully sandboxed. To confirm it is active:

aa-status | grep FlashForgeUI

On Ubuntu 22.04 and earlier the installer deliberately skips the profile ("Skipping the installation of the AppArmor profile"). That's expected — those releases don't restrict user namespaces, so the sandbox works without it. If FlashForgeUI won't start after a .deb/.rpm install on 24.04+, reload the profile:

sudo apparmor_parser -r /etc/apparmor.d/FlashForgeUI

Running the .AppImage — works out of the box, sandbox off

An AppImage has no install step and never runs as root, so it can't install a profile for itself, and its chrome-sandbox helper can never be root-owned. FlashForgeUI detects this at launch and starts with --no-sandbox so it stays usable — only where namespaces are blocked; everywhere else the AppImage runs sandboxed as normal. If you're fine running it unsandboxed, there's nothing to configure.

Optional: sandboxing the AppImage yourself

Create /etc/apparmor.d/flashforgeui, replacing the path with the actual location of your AppImage:

abi <abi/4.0>,
include <tunables/global>

profile flashforgeui /home/YOUR_USER/Applications/FlashForgeUI.AppImage flags=(unconfined) {
  userns,
  include if exists <local/flashforgeui>
}
sudo apparmor_parser -r /etc/apparmor.d/flashforgeui

The profile is tied to that exact path — moving or renaming the AppImage means updating and reloading it. If that upkeep is annoying, install the .deb/.rpm instead; that's why those are the recommended downloads on Ubuntu 24.04+.

Background: electron#41066 and Ubuntu bug #2046844.

Headless: auto-start without the desktop UI

The Start with system setting is part of the desktop app and does not apply to headless mode. To run FlashForgeUI headless at login, create a systemd user service at ~/.config/systemd/user/flashforgeui.service:

[Unit]
Description=FlashForgeUI (headless)
After=network-online.target

[Service]
Type=simple
ExecStart=/opt/FlashForgeUI/FlashForgeUI --headless
Restart=on-failure

[Install]
WantedBy=default.target

Adjust ExecStart to match your install (for an AppImage, use the full path to the .AppImage). Then enable it:

systemctl --user daemon-reload
systemctl --user enable --now flashforgeui
loginctl enable-linger "$USER"   # start without an active login session

See Headless Mode for the headless command-line flags.

Clone this wiki locally