BURSU Connection Manager

What is BURSUcm

BURSU Connection Manager (BURSUcm) is a fast remote connection manager. It brings everything an engineer works with into one window: servers, network gear, remote desktops, file panels, saved credentials and team access rights. It runs natively on Windows, Linux and macOS, has mobile companions for Android and for iPhone/iPad, and can — but does not have to — sync everything through the BURSUcloud service.

Your servers, one encrypted catalog — on every device

Windows · Linux · macOS · Android · iOS/iPadOS · web portal

SSHWinRMSFTPFTPRDPVNCScreen SharingTelnet

Supported protocols

Quick start in 10 minutes

From a blank machine to your first SSH session, saved password and file transfer. Every step links to the chapter that covers it in depth — but you will not need those links to finish.

1. Install the app. Windows: download and run BURSUcm-Setup.exe. Linux: install the package for your distribution. macOS: drag the app from the .dmg into Applications.
2. Choose where the data lives. On first run the app asks; pick Local database — the safest default, fully offline. Later you can bring its connections, credentials and snippets into the cloud with a portable backup.
3. Sign in and change the password. A fresh local database has one account, admin / admin; the app asks you to replace the password right away.
4. Save a credential. Open Credentials in the sidebar → New credential → a label (say, “root — lab servers”), the username and the password. One saved credential can serve any number of servers — that is the point.
5. Add a connection. Press Ctrl+T (or + Add Connection): a name, type SSH, the host address — port 22 is pre-filled. In the credential field pick the one you just saved. In Folder pick a folder from the list — it shows the same folders in the same order as the tree; new folders are created with New folder in the tree.
6. Connect. Double-click the new entry. On the very first connection the app shows the server's key fingerprint — that is the host-key check working as intended; confirm with Trust & remember. A green dot on the tab means the session is live.
7. Move a file. In the session toolbar press Files (SFTP): your computer on the left, the server on the right. Drag a file across — it goes through the transfer queue with a progress bar.
8. Lock it down. When real passwords start accumulating, set a master password in Settings → Security — from then on your secrets are encrypted with a key only you know, and the database becomes portable to any other machine. Details in Master password & the vault.

Install on Windows

System requirements

• Windows 10 or 11 (x64, x86 or ARM64), including Windows Server 2012–2025.
• ~150 MB of disk space. The .NET runtime is bundled with the installer — nothing else to install.

Installation

1. Download BURSUcm-Setup.exe from bursucm.com/download. The SHA-256 checksum is published next to the button — verify it with certutil -hashfile BURSUcm-Setup.exe SHA256 if you like.
2. Run the installer and follow the wizard. It picks the right build (x64/x86/ARM64) for your CPU automatically.
3. Launch BURSUcm and continue with Data storage & first run.

Install from a terminal — winget

BURSUcm is in the Windows Package Manager, so the two steps above can be a single command. winget ships with Windows 10 (1809 and later) and Windows 11, and the command works the same in PowerShell, Terminal and Command Prompt. Windows asks for confirmation once, because the app is installed for every account on the machine.

winget install bursucm

Later, winget upgrade bursucm installs the newest version over the old one and keeps all your data; winget uninstall bursucm removes it.

Updates

The app checks the release feed once a day — at startup and on every further day it stays open (you can turn this off in Settings → Appearance) — and shows a dialog when a newer version is available, with the changelog and a download link. A notice found while you work waits until you are on the Home tab. Installing a new version over the old one keeps all your data. If you installed with winget, winget upgrade bursucm does the same from a terminal.

Install on Linux

Native x86_64 packages are built for the three big families. Grab the file from bursucm.com/download (the page picks your distribution's tab automatically) — or better, add the repository once and let your package manager handle updates forever.

The app lands in /opt/bursucm, appears in your application menu as “BURSU Connection Manager”, and can be started from a shell as bursucm. Every package's SHA-256 checksum is published on the download page.

Package repositories — automatic updates

All three repositories are served from bursucm.com and signed with the BURSUsofts Package Signing GPG key. Add the one for your family and new releases arrive with your regular system updates.

APT (Debian / Ubuntu / Mint / Pop!_OS)

sudo wget -qO /usr/share/keyrings/bursucm.gpg https://bursucm.com/repo/bursucm.gpg
sudo tee /etc/apt/sources.list.d/bursucm.sources >/dev/null <<'EOF'
Types: deb
URIs: https://bursucm.com/repo/apt
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/bursucm.gpg
EOF
sudo apt update && sudo apt install bursucm

The modern deb822 .sources format is used on purpose: Ubuntu's “Software & Updates” window shows such entries properly under Other Software.

DNF / YUM (Fedora / RHEL / AlmaLinux / Rocky)

sudo rpm --import https://bursucm.com/repo/bursucm.asc
sudo tee /etc/yum.repos.d/bursucm.repo >/dev/null <<'EOF'
[bursucm]
name=BURSUcm
baseurl=https://bursucm.com/repo/rpm
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://bursucm.com/repo/bursucm.asc
metadata_expire=6h
EOF
sudo dnf install bursucm

Pacman (Arch / CachyOS / Manjaro / EndeavourOS)

curl -fsSL https://bursucm.com/repo/bursucm.asc | sudo pacman-key --add -
sudo pacman-key --lsign-key BA53B57D047CE8F14610C02A037A882DB839E2E0
echo -e '\n[bursucm]\nServer = https://bursucm.com/repo/arch' | sudo tee -a /etc/pacman.conf
sudo pacman -Syu bursucm

Runtime dependencies

The packages declare everything they need (GTK 3, NSS, ALSA); your package manager pulls those in automatically. There is no separate .NET or Electron to install — the app is self-contained.

Install on macOS

1. Download the disk image for your Mac from bursucm.com/download: Intel (BURSUcm-3.3.5-x64.dmg) or Apple Silicon (BURSUcm-3.3.5-arm64.dmg). Not sure which chip you have? Apple menu → About This Mac.
2. Open the .dmg and drag BURSU Connection Manager into the Applications folder.
3. Launch it from Applications or Spotlight.

Everything in this guide applies on the Mac; the details specific to the Linux/macOS edition are collected in its chapter.

Install on Android

1. Install BURSU Connection Manager from Google Play (Android 8.0 or newer) — the easiest way, with automatic updates. Prefer no Google account on the device? The same app is also available as a direct BURSUcm.apk from bursucm.com/download; opening it asks for a one-time permission to install from your browser or file manager.
2. Open BURSUcm and sign in with your bursucm.com account (email/password, Google, Microsoft, Apple or GitHub), or with a database user login like name@handle. If your account has two-factor sign-in on, the app asks for the code right after the password — see Two-factor sign-in.

The Android app is a companion to the cloud: it needs a BURSUcloud account and shows the same catalog as your desktop. Its features and security model are described in the Android chapter.

Install on iPhone and iPad

1. Install BURSU Connection Manager from the App Store — one universal app for both iPhone and iPad, free, requiring iOS or iPadOS 17 or newer.
2. Open it and sign in with your bursucm.com account (email/password, Google, Microsoft, Apple or GitHub), or with a database user login like name@handle. If your account has two-factor sign-in on, the app asks for the code right after the password — see Two-factor sign-in.

The iOS and iPadOS app is a companion to the cloud: it needs a BURSUcloud account and shows the same catalog as your desktop. Its features and security model are described in the iOS & iPadOS chapter.

Data storage & first run

BURSUcm keeps the whole catalog (connections, credentials, users, snippets) in a single database. On first launch the app asks where that database should live — and you can change your mind later in Settings → Database, between a local database and PostgreSQL; BURSUcloud is opened from the login screen instead (see Connecting the app to the cloud):

• Local database — sign in as admin / admin; the app immediately asks you to change the password.
• BURSUcloud — sign in with your bursucm.com email and password, or with Google, Microsoft, Apple or GitHub (a browser window opens; the app picks the sign-in up automatically), then choose a database from the list.

How BURSUcloud works inside

• Every database gets its own PostgreSQL database on the server — customer data is never mixed.
• Apps reach it only through the HTTPS API; the DBMS itself is not exposed to the internet.
• Connection passwords are stored encrypted with your master password. The master password never travels to the server: the key is derived on your device, the server only ever sees ciphertext. That is why a forgotten master password cannot be recovered — keep it safe.
• Database users travel inside the database: a full backup or SQL dump carries the user accounts along with the data.

Migrating between modes

1. In Settings → Database select and test the target database (the “Test” button).
2. Click “Migrate to another database…” — connections, credentials, users and snippets move over wholesale into the target: in the Windows app another local database file or a PostgreSQL database, in the Linux & macOS app another local database file or, since 3.1.3, a PostgreSQL database. The button cannot move a catalog into BURSUcloud — for that, see Moving in from a local database.
3. If several computers will use the database, enable a master password BEFORE migrating — otherwise DPAPI-encrypted passwords will not open on other machines.

Switching the database — in Settings → Database, with Import Database…, or by answering Yes to “Switch to the migrated database now?” after a migration — closes every open session. If any session is open, the app asks first: “Open sessions (N) will be closed. Continue?”

PostgreSQL: your own server

Choose PostgreSQL under “More options” on the first-run screen — or later in Settings → Database → Database mode — and fill in the form. The app assembles the connection itself; nobody types a connection string:

Test connection shows the server version beside the button — or the reason it failed; a refused certificate is explained in the same words, naming the encryption option to pick. Then Continue: the schema is created, and you sign in as admin / admin and set a new password. Every client — Windows, Linux, macOS — is pointed at the same server the same way; users, groups and per-folder rights work exactly as in the other modes.

To share these connection settings without retyping them, choose Export config in the PostgreSQL form and send the resulting .bursucm-db file to your colleague; Import config opens it on another Windows, Linux or macOS computer. The file contains the host, port, database, username, database password and encryption choice — not the catalog, app account, vault master password or saved secrets. Protect the file with its own password before sending it: an unprotected file contains the database password in plain text.

On the server: what an administrator sets up

Versions. Any PostgreSQL release the project still supports — 13 and newer at the time of writing. BURSUcm asks for nothing exotic: the newest thing its schema uses is ON CONFLICT (PostgreSQL 9.5), and scram-sha-256 authentication needs PostgreSQL 10. It is developed and tested against 14 and 16.

Give it a role and a database of its own, and nothing else:

CREATE ROLE bursucm LOGIN PASSWORD 'a long random password';
CREATE DATABASE bursucm OWNER bursucm;
REVOKE ALL ON DATABASE bursucm FROM PUBLIC;

• No SUPERUSER, no CREATEROLE, no CREATEDB. The role owns one database and needs nothing beyond it. A superuser here would let anyone who reaches the catalog read every other database on that server, and pg_hba.conf cannot take that back.
• Let in the client subnet only — in pg_hba.conf, above any broader line, because the first matching line wins:

  # TYPE   DATABASE  USER      ADDRESS           METHOD
  hostssl  bursucm   bursucm   192.168.10.0/24   scram-sha-256

  Put your own subnet there, delete every trust line, and set ssl = on and listen_addresses in postgresql.conf. Then sudo systemctl reload postgresql.
• The certificate must name the host you type. With Required, verify server certificate the app checks the server certificate against the name in the Host field: a certificate issued for db.example.lan does not match a connection to 10.0.0.5. Connect by that name, and make sure the issuing CA is trusted on the client computer. The middle option, a self-signed certificate, still encrypts but proves nothing about who answered.
• Firewall the port. 5432 reachable from the client subnet and from nowhere else — e.g. sudo ufw allow from 192.168.10.0/24 to any port 5432 proto tcp.
• Back it up like any other database. pg_dump -Fc bursucm > bursucm-$(date +%F).dump on a schedule, kept off that machine, and restore one of them somewhere harmless from time to time: an untested backup is a hope, not a backup. The dump holds the catalog and the saved passwords as ciphertext — the master password is still needed to read them, but treat the file as a secret all the same.

Connections

Creating a connection

1. Click “+ Add Connection” (or Ctrl+T, or right-click a folder → “Add connection here…”).
2. Fill in the name, type (protocol), host and port. The port is pre-filled per protocol (22, 5985, 3389, 5900, 23…).
3. In BURSUcloud mode the BURSUlink connection field above Host and Port chooses Direct or Through BURSUlink — an agent on a computer behind NAT (see BURSUlink).
4. Enter the username and password manually — or pick a saved credential from the vault (see Credentials).
5. The “Folder” field is a drop-down tree of folders: the same folders, in the same order and folded the same way as the main tree (folding them here leaves the main tree alone). You pick a folder rather than type a path; General (no folder) at the top of the list keeps the connection outside any folder. A new folder is made in the tree first, from its right-click menu.
6. Optionally add tags (comma-separated) and notes.

Folders, favorites, search

• Folders — unlimited nesting; the expanded/collapsed state is remembered, and in cloud mode it syncs across devices along with folder order.
• Filters above the tree: All, Favorites, Recent. The star on a connection card adds it to favorites.
• Search (Ctrl+F) matches names and hosts instantly.
• Quick Connect — a user@host:port line for a one-off session without saving it to the catalog. Later, Save as connection in the tab's menu opens the new-connection editor filled in with what you typed.

The right-click menu — the fast lane

Most day-to-day catalog surgery never opens a dialog; it lives in the context menu.

• On a folder: “Add connection here…”, “New subfolder…”, “Rename folder…” and “Default credential for this folder” — one login for everything inside (see folder inheritance).
• Deleting a folder: “Delete folder...” removes only an empty folder. If connections, credentials or subfolders are still inside, nothing is deleted — the window says how many connections (in a credential folder, credentials) and subfolders it holds, so you can move or delete them first. Before Windows 5.1.4 and Linux & macOS 3.1.3 everything inside moved one level up instead. The same rule applies on bursucm.com.
• On a connection: Connect, Open in split view, Copy Username / Copy Password (the password goes to the clipboard without ever being shown on screen), Copy As — duplicate the entry to make a similar one in two clicks, Wake on LAN — send a magic packet to the connection’s MAC address to power on a sleeping machine before you connect, Move to folder, Edit, Delete.
• Also in the same menu: a direct “Open SFTP” — the file panel without opening a terminal first; and for RDP on Windows, “Open with Remote Desktop” — the session in an external mstsc window instead of a tab.
• On a credential: Edit, Copy As, Move to folder, Delete — same idea, same speed.

Wake on LAN and the MAC address

Every connection type except Serial has the field MAC address (for Wake on LAN, optional). With an address saved, Wake on LAN in the right-click menu sends the magic packet — as a broadcast and also straight to the machine’s own address, because a sleeping computer on Wi-Fi never receives the broadcast.

Since Windows 3.8.1 and Linux & macOS 2.8.1 the Get MAC button beside the field reads the address for you. It first asks this computer’s own network (ARP): instant and without credentials, but only for a machine that is switched on and on the same local network. For an SSH connection to a machine beyond a router it then signs in — with the connection’s own credentials, key, host-key check and jump host — and asks the machine itself. For any other connection type outside the local network, read the address on an SSH connection to that machine, or type it by hand.

Your own order — arranging folders and entries by hand

Alphabetical order is the default, but rarely how you actually think about your servers. Both trees — connections and credentials — can be arranged manually:

• Hover any row — a folder, a connection or a credential — and small ▲ ▼ arrows appear on the right. Each click swaps the row with its neighbour.
• The arrows keep the tree as it is: folders move among folders, entries among entries within their folder — only the display order changes.
• Or drag with the mouse in the Windows, Linux and macOS apps: grab a folder or an entry and drop it where it belongs — a line shows the place, an outline shows the folder it goes into. Among its neighbours it moves at once. Into a folder, out of one or to the top level, a window first shows what moves, from where, to where and at which place — and an administrator sees who gains or loses access; nothing changes until you press Move. A folder takes its subfolders, entries, access rights and order along. Holding the pointer over a closed folder opens it; Esc cancels. Dragging is off in Favorites, Recent and while searching.
• The order is saved in the database, not on the device: in cloud mode the Windows app, the Linux/macOS app, the web portal, the Android app and the iOS/iPadOS app all show exactly the order you set. On the portal the same arrows sit on each row of the Connections and Credentials tabs.
• On the phones a row moves with its drag handle on Android, and with Move up / Move down in its menu on the iPhone and iPad — in the full list, outside a search, and only with the right to edit.
• Anything you never reordered — and anything newly created — simply follows in alphabetical order after the arranged items, so new entries never disappear.

The connection card

Click a connection to open its card: host/port/protocol, the linked credential with Copy and Show/Hide buttons, tags, notes, last-used time. On top — Connect, favorite, Edit, Delete.

Since Windows 5.1.1 and Linux & macOS 3.1.1 the card’s Last used row says when the connection was last used and, on a shared database (BURSUcloud or PostgreSQL), by whom — for example “by user2554, at 15.02.2025 21:22 GMT+4”. The time is shown in your own time zone, with the GMT offset that applied on that date. A local SQLite database shows only the time. A connect is counted once the session is established; a failed sign-in is not recorded.

Terminal & sessions

Tabs

• Every session is a tab. Drag to reorder; right-click for Duplicate, Pin, Close. With many sessions open the tabs narrow to share one row, like a browser’s; the + at the end opens a new connection and the mouse wheel scrolls the strip.
• Status dot on each tab: yellow — connecting, green — live, red — dropped, purple — connected through a jump host. You can spot a dead session without opening the tab.
• On an unexpected drop (network, a server that stopped answering, a reboot) the tab turns red and reconnects on its own — see When a connection drops. The overlay inside the session keeps its Reconnect button: Enter reconnects at once. An intentional exit (exit, Ctrl+D) closes the tab as usual.
• Duplicate with cwd: duplicating an SSH tab opens the new session in the same directory you were working in — no cd ceremony.

When a connection drops — automatic reconnect

Since Windows 5.1.2 and Linux & macOS 3.1.2 a session that breaks reconnects by itself — SSH, SFTP and FTP, Telnet, WinRM, serial ports, RDP, VNC and Apple Remote Desktop alike. Only a session that broke is reconnected: your own exit, or logging off a remote desktop, still closes the tab.

• The countdown: the tab turns red, waits 30 seconds and reconnects — up to three attempts. For the tab you are looking at, the “Connection lost” window shows the reason and the countdown, with Reconnect now and Cancel; a tab in the background counts down quietly. After three failed attempts the window says so and offers Reconnect (three more attempts) or Close.
• A server that stops answering: an SSH or SFTP session asks the server whether it is still there once per keep-alive interval (15 seconds by default, Settings → SSH) and counts the session as lost after 10 seconds without an answer. A frozen server, or one rebooting under an open session, is noticed in seconds instead of leaving the terminal waiting. Data still arriving counts as an answer, so a large transfer over a slow link is not taken for a dead server. An idle FTP session is kept open with a keep-alive command once a minute.
• The keyboard stays with you: an attempt in the background never takes the keyboard or switches tabs — what you type into another tab, a dialog or the second pane stays there. A question an attempt runs into (a host key, a jump host, an RD Gateway certificate) waits until you open its tab, and a changed host key is never accepted silently.
• Passwords you typed: if you typed the password when connecting and did not save it, an automatic attempt does not send it again: the tab waits for you, and its Reconnect uses what you typed.
• Split view: a second pane that loses its session reconnects in place on its own. If the main pane drops while the second one still works, the working pane is left alone; Reconnect and Close ask first and name the session in the second pane that would close with the tab.
• Port forwards: the -L, -D and -R tunnels of a lost session are released at once, so the reconnected session can open the same ports again.

Working in the terminal

• Full ANSI colours: Midnight Commander, htop and other TUI apps render correctly.
• Right mouse button — configurable in the connection’s SSH and WinRM options (Right-click in terminal): “Copy if selected, otherwise paste (default)”, “Copy selection, paste on right-click”, or “Show a Copy/Paste context menu”. Selecting text copies it only in “Copy selection, paste on right-click”; in the other two modes the right button is the copy, so a line you select to read does not replace what you have just copied.
• Safe paste: if the clipboard holds multiple lines (commands would run immediately), a confirmation with a preview appears — protection against hidden commands copied from web pages. This guards every paste route: Ctrl+V, Shift+Insert, right-click and the context menu.
• Clean paste: line endings are normalised and bracketed paste is supported, so modern shells (bash 5.1+, zsh) and REPLs receive a multi-line paste as one editable block instead of executing it line by line — and pasting into editors never leaves stray ^M characters.
• Full Window expands the session to the whole app window; Full Screen (exit with F11) takes the entire monitor. Its panel — the session tabs, the session’s buttons, Exit Full Screen, Minimize and a pin that keeps it down — spans the whole top of the screen and comes down once the mouse rests for a moment at the middle of the top edge, so the remote screen’s own tabs and window buttons in the corners keep taking clicks. On a Mac its tabs and buttons sit right in the bar macOS itself slides down. Neither keeps other programs behind it: a program you switch to — a messenger, a browser — comes in front, as with Remote Desktop Connection (Windows 5.3.7).
• Sidebar width: drag the sidebar’s right edge to make it wider or narrower — the width is remembered, and a double-click on the edge gives back the standard width. In a narrow sidebar the buttons show their icons and counts instead of cut-off words, and each one names itself in a tooltip.
• The + at the end of the tab strip — and on the Full Screen panel — opens Open connection: the connection tree with a search on top. The arrow keys walk the tree, Enter or a double click connects, Expand all / Collapse all fold the folders, and + Add Connection at the bottom creates a new one. A connection opens without leaving Full Window or Full Screen.
• A slim scrollbar on the right lets you scroll back through the buffer without covering the text.

Appearance — colour scheme and font

Make the terminal your own in Settings → Appearance (it applies to every terminal session — SSH, Telnet and Serial):

• Colour scheme: pick from built-in themes — Classic, Dracula, Solarized and more — matched for both readability and looks.
• Font: choose the font family and size; the whole scrollback re-renders instantly so you can compare at a glance.

Logging a session to a file

Need a transcript of what happened on a server? Turn on session logging per connection and BURSUcm writes the session’s output to a text file as you work.

• Two switches, both needed: Log terminal session output to files (per connection) in Settings → Logs, and Log this session's output to a file in the connection itself. The Logs folder is set on the same Settings → Logs tab; transcripts go to its sessions subfolder.
• Each session gets its own timestamped file, so you keep a clean record for audits, change tickets or just remembering what you typed last week.

Split view — two sessions side by side

One tab can hold two terminal sessions:

• Another server alongside: right-click a connection in the tree → “Open in split view” (joins the active tab).
• The same server again: the “Duplicate in split” button in the session toolbar.
• The ⇅ button flips the layout: side-by-side ⟷ stacked.
• If one pane exits, the other takes over the whole tab. Jump hosts and tunnels work in the second pane too.
• A pane that loses its session reconnects in place — see When a connection drops.

Broadcast — type once, send everywhere

The Broadcast toggle in the session toolbar mirrors your keystrokes to every open terminal session (tabs and split panes). While it is on, a bright orange banner shows “Broadcasting input to N sessions” with a Stop button.

Command snippets

Snippets are a shared library of saved commands you send into a terminal in one click.

• Send: the Snippets button in an SSH/Telnet/Serial session toolbar → pick a command from the grouped menu. It is typed into the terminal (without Enter — you decide when to run it); keyboard focus stays in the terminal.
• Placeholders: write {name} in a command — e.g. systemctl status {service}. A dialog asks for each value at send time.
• Managing: the Snippets window opens from the Home dashboard (“⚡ Command snippets”) or from Settings → Other → “Manage snippets…”. Fields: name, group, command, description.
• Sync: snippets live in the database — in cloud mode they are shared with the whole team and can also be edited on the web portal (the Snippets tab).
• Permissions: everyone can use snippets; adding and changing them requires the administrator role or the “Can manage command snippets” right. A new database comes pre-seeded with useful defaults (df, systemctl, journalctl, apt, docker, ss…).
• With Broadcast on, a snippet goes to every session at once.

Keyboard shortcuts

Toggled in Settings → Appearance → “Enable keyboard shortcuts”; the same page shows this legend.

Inside a terminal, copy and paste follow terminal conventions: Ctrl+Shift+C copies the selection, Ctrl+V or Shift+Insert pastes, and plain Ctrl+C stays what it should be — the interrupt key for the remote program.

In an AppleRD tab the Mac’s shortcuts apply: copy and paste on the Mac are Win+C / Win+V from a Windows keyboard, Alt+C / Alt+V on Linux and Command+C / Command+V on macOS — see AppleRD keyboard.

SSH power features

Authentication

In the connection card → SSH options there are three ways to sign in:

The same page sets keep-alive and connect timeout (empty = the global defaults from Settings → SSH) and the terminal type (TERM).

SSH agent

On Windows the app talks to the OpenSSH Authentication Agent (and Pageant); on Linux and macOS, to the standard ssh-agent.

1. Windows: enable the service “OpenSSH Authentication Agent” (Services → startup type “Automatic” → Start). Linux/macOS: the agent is usually already running in your session.
2. Add a key: ssh-add /path/to/key — the passphrase is asked once.
3. In the connection’s SSH options select the “SSH agent” method. Done: the passphrase is never stored or asked again.

Jump host — connecting through a bastion

If a server is only reachable through an intermediate host (a bastion), BURSUcm builds the tunnel automatically, like ssh -J:

1. Open the bastion in your catalog → Edit → SSH options → tick “This connection can be used as a jump host”.
2. In the target connection → SSH options → “Connect via (jump host)” → pick the bastion. Only flagged connections appear as candidates.
3. Connect as usual. Both the terminal and the SFTP panel work. Chains are supported: the bastion itself may go through another jump host.

• Such a session’s tab gets a purple dot, and the card shows a “Jump host” row.
• Security: the host key is verified against the real target, not the tunnel — swapping the destination server will be noticed.

Port forwarding (-L / -R tunnels)

Each SSH connection can carry a list of tunnels (SSH options → Port forwards) that open automatically with the session:

Each tunnel’s status is printed into the terminal when the session starts. Tunnels work through a jump host too. A tab whose connection carries forwards shows an “(F)” suffix in its title.

A dynamic forward (since Windows 3.3 and Linux/macOS 2.3) opens a SOCKS5 proxy on 127.0.0.1 only — it is never offered to the network your computer is on. Names are resolved on the server side as well (socks5h), so internal hostnames work. Several services behind one host? One dynamic forward replaces a list of local ones. The phones keep such a forward when they save the connection but do not start it.

On Linux and macOS the listen port of a local (-L) or dynamic (-D) tunnel must be 1024 or higher: lower ports belong to root, so a tunnel on 443 reports “Permission denied” and does not start — the app says so under the red line. 1080 is the customary SOCKS5 port. Windows has no such limit, which is why the same connection can work on one computer and not on another.

tmux — a session that survives a dropped connection

Since Windows 3.3, Linux/macOS 2.3 and Android 1.8.8 — and on the iPhone and iPad too — an SSH connection can live inside tmux on the server: tick Keep the session in tmux in the SSH options and give the session a name (default BURSUcm). When the shell opens, the app attaches to that session — created the first time, rejoined on every later connection.

• A dropped connection loses nothing: reconnect and you are back on the same screen with the same programs still running. The same option on the phone joins the same session, so work started on the desktop continues on Android, the iPhone or the iPad, and back.
• Detach with Ctrl+B, then D: you return to the plain shell and the tab stays open; the session keeps running on the server. The tab title reads “(tmux)” while you are inside.
• The mouse wheel scrolls tmux's own history, the Files panel still follows cd, and the AI assistant still sees when a command ends.
• tmux must be installed on the server (sudo apt install tmux, sudo dnf install tmux); a server without it says so in the terminal and the session goes on without it. Nothing needs configuring on the server — the app sets what it needs for its own session.

Host-key verification (MITM protection)

Like PuTTY, BURSUcm verifies the server’s identity by its key fingerprint:

• First connection: an “Unknown SSH server” dialog with the fingerprint — verify it and choose “Trust & remember” (or “Connect once”).
• Key changed: a prominent warning. Continue only if the server really was reinstalled or its key rotated.
• Modes in Settings → SSH: “Ask once, then remember (recommended)”, “Strict - only allow already-trusted hosts” (Linux and macOS: “Strict - only allow already-trusted servers”), “Off - do not verify (insecure)”. The “Forget all trusted SSH host keys” button lives there too.

The SFTP file panel

• The “Files (SFTP)” button in an SSH session opens a dual-pane manager: this computer on the left, the server on the right.
• Transfer queue: every upload and download goes through a queue with per-file progress bars and speed. Long copies no longer block the panel — keep browsing while they run.
• Drag & drop: drop files straight from your file manager (Explorer on Windows) into the remote pane.
• Whole folders: uploading or downloading a directory mirrors the entire tree, subfolders included.
• Move (F6): transfer a file — or a whole directory — to the other side and remove the source, in one action. The delete is held back until every file has arrived: a move that skipped or failed anything leaves the source untouched.
• Open in the server pane’s right-click menu downloads the file and opens it in the program your system uses for that type; every save there goes back to the server (Linux & macOS since 3.3.1).
• Create folders and files, rename, delete, chmod (octal permissions: 644, 755…), replace confirmation with file dates.
• Auto-open for new SSH sessions and follow the shell’s folder (the panel follows cd; bash only) are toggled in Settings → SSH.

RDP: remote desktop

On Windows: two engines

The engine belongs to the connection: the first time you open one, the app asks which engine it should use and remembers the answer on that connection (change it any time in its RDP options; Settings → RDP sets the default for new ones). The choice is stored in the catalog itself, so in cloud mode the Windows and the Linux/macOS app open the same connection with the same engine. On the first connection to a new server the app asks you to verify its certificate — and when the session goes through an RD Gateway, the gateway's own certificate is checked and remembered separately from the server's. A host that is not answering is reported as unreachable within seconds, not as a silent black tab. Picking a different engine in a connection’s RDP options makes the app ask again on the next connect, with that engine already selected; a connection through a BURSUlink agent always uses BURSUrdp.

On Linux and macOS: BURSUrdp and IronRDP

The Linux/macOS app renders RDP right inside the tab with its own BURSUrdp engine — the same one as on Windows, with H.264 graphics and multi-monitor support — and a lightweight IronRDP engine as a fallback. No external client, no X11 tricks, identical behaviour on both systems. Copy and paste work with the system clipboard, the session renegotiates its resolution when you resize the window, and reconnecting after a drop is a single click. Certificates of servers you accept are remembered; the list can be cleared in Settings → Trusted hosts. An “open in the system RDP client” action is still available from the connection’s context menu if you prefer an external window.

Per-connection options

• Display: colour depth (15/16/24/32-bit), connection quality (LAN / broadband / low / auto), all monitors (multimon, Windows engine); sharp picture on Retina / HiDPI screens — on a monitor scaled above 100% the session gets the screen’s real pixels together with its scale, so text is sharp at its usual size (on by default, both engines; turn it off for a server that ignores the scale and draws everything tiny).
• Pointer: the pointer takes the server’s own shapes — resize arrows, the hand over links, the text cursor — in both engines (Windows 5.2.5, Linux & macOS 3.3.0).
• Local resources: clipboard, local drives, printers, microphone; where remote audio plays.
• Other: domain, RD Gateway.

RD Gateway

A server that can be reached only through a Remote Desktop Gateway is set up on the connection itself: RDP options → Security → RD Gateway host (optional). Type the gateway's host name; an empty field means a direct connection. The field is the same in the Windows and the Linux & macOS app and travels with the connection in the catalog.

• Credentials: the gateway is sent the connection's own username, domain and password — there are no separate gateway credentials. A gateway you would not trust with that password is the wrong gateway.
• Transport: HTTPS on port 443, over the gateway's HTTP transport (the old RPC-over-HTTP transport is not used). Type the host name — or host:port when the gateway does not listen on 443 (Windows 5.2.0; the Linux & macOS app from 3.2.1).
• Engines: BURSUrdp goes through the gateway on Windows, Linux and macOS. The Microsoft engine on Windows does too, with Windows' own gateway checks. The IronRDP fallback on Linux and macOS cannot use a gateway, so the field is greyed while it is selected.
• The gateway's certificate is checked before the session starts and remembered separately from the server's: on the first connection the app shows its fingerprint (Trust & remember or Connect once), and a changed certificate raises a warning instead of being accepted silently. If the certificate cannot be read at all, the connection is cancelled — the gateway would see the same password as the server. Settings → RDP → Forget all trusted RDP certificates forgets gateway certificates as well (since Windows 5.1.5 and Linux & macOS 3.1.4).
• A different gateway on a shared connection is part of the Routing changed check.
• On Android, iPhone and iPad (since 2.0) an RDP connection goes through the gateway set on the desktop; the phone apps have no gateway field and cannot change it. They send the session's own username and password (smart cards are not supported), use port 443 unless the desktop field holds host:port, pin the gateway's certificate separately (Unknown RD Gateway, RD Gateway certificate changed) and ask before using a gateway other than the one recorded for the connection (RD Gateway changed).

VNC: remote desktop

Alongside RDP, BURSUcm speaks VNC (RFB) and renders the remote screen right inside a tab — the same window, tabs and full-screen behaviour as every other session. It works with the common servers: RealVNC, TigerVNC, TightVNC, UltraVNC, x11vnc and the built-in screen sharing on macOS and Linux.

macOS Screen Sharing: the standard mode is ordinary VNC/RFB, and a Mac offers it to any VNC client — the path BURSUcm uses for Macs that do not offer Apple's own protocol. Apple’s High Performance screen sharing (macOS 14 or later, a virtual display carried over UDP on the connection's port and the next one) is handled by the dedicated Apple Remote Desktop connection type. A Mac that can do it also still answers on the standard VNC mode.

Encryption & authentication

• TLS / VeNCrypt: when the server offers it, the session is encrypted (VeNCrypt, or the RealVNC/UltraVNC TLS variants). The server’s certificate is verified on the first connection and remembered — if it later changes you are warned (the same Trust-On-First-Use model as SSH host keys and RDP).
• Password: the standard VNC password (and, where the server uses it, a username) can be saved in a linked credential or asked at connect time. Plain VNC without TLS sends the framebuffer unencrypted — prefer a TLS-capable server, or tunnel it through SSH port forwarding.
• Apple sign-in: a VNC server that offers Apple’s own sign-in (Apple Diffie-Hellman) with unsafe encryption parameters is refused before your password leaves the computer, with a message that says why (since Windows 5.1.1 and Linux & macOS 3.1.1).

Encodings & performance

• Supports Tight, ZRLE and Hextile encodings and negotiates the best one with the server; only the changed part of the screen is redrawn, so even a slow link stays usable.
• Scaling: the remote screen can be shown at full size or scaled to fit the tab.
• View-only mode disconnects your keyboard and mouse from the session — watch or present without touching the far side by accident.
• Clipboard sharing copies text both ways between your machine and the remote desktop.

Importing existing VNC connections

Already have .vnc connection files (from RealVNC Viewer, TigerVNC and others)? Bring them in from Import in one click — host, port and options come across; passwords are asked or linked afterwards. See Importing from other tools.

Apple Remote Desktop: Mac desktops

Alongside RDP and VNC, BURSUcm opens a Mac's screen as a connection of type Apple Remote Desktop (the app's settings tab and dialogs call it AppleRD). On macOS 14 or later the connection uses Apple's High Performance path — hardware-accelerated video and the Mac's system audio (Apple documents it for Apple silicon; an Intel Mac streams it too); a Mac that does not offer it shows the ordinary, fully usable screen, without audio.

Creating a connection

• Type: Apple Remote Desktop. Host, port (5900 is pre-filled), and the macOS username and password — the account you sign in with on the Mac. Screen Sharing or Remote Management must be switched on there (System Settings → General → Sharing).
• High Performance is always on: there is no mode or Mac-type field, and the Mac tells BURSUcm itself what it is. A Mac gives High Performance to one connection at a time, and it sends that picture only to UDP ports 5900 and 5901 of this computer, so one computer can hold one such session. When it is already in use, BURSUcm says High Performance is already in use and does not connect — close the other AppleRD connection and connect again. When a Mac does not start High Performance (before macOS 14, for instance), the session opens on the standard picture. On every Mac the pointer takes the Mac's own shapes.
• Screen mode: Private session — a virtual display sized to your window (sharp, and the Mac's own panel goes dark) — or Mirror, which streams the physical screen at its native size and leaves it lit. Sharp and stay-lit are the same Apple switch and cannot be combined. Screen darkening works only on a Mac with Apple silicon: an Intel Mac keeps its screen lit whichever mode is set, and BURSUcm says so once.
• Mac interface at this screen's scale (Retina / HiDPI) — the Mac draws its interface at this screen's scale: sharp instead of enlarged.
• Video codec: H.264 4:2:0 (hardware-decoded on the GPU — the responsive default) or HEVC 4:4:4 (finer coloured text, decoded on the CPU).
• Audio: play the Mac's system sound in the session. The status line under the picture says audio off when you switched it off, audio unavailable when this computer has no output device, and no audio on the standard picture, which never carries sound.

Someone else is signed in at the Mac

When another user is signed in at the Mac, the desktop apps (Windows, Linux, macOS) ask what to do — Someone is using this Mac:

• Ask name to share the screen — that person sees a request on the Mac and has to allow it.
• Cancel does not connect.

Only asking to share the screen is offered, on every Mac and in every app — desktop, phone and tablet; there is no separate login.

A sleeping Mac

A Mac that is asleep answers nothing, and Screen Sharing simply times out. When the connection has a MAC address saved (see Wake on LAN and the MAC address), BURSUcm first checks whether the Mac answers. If it does not, the tab shows Waking the Mac and waiting for it to answer…, the magic packet is sent and repeated every ten seconds, and the session opens as soon as the Mac answers — usually in about half a minute, into a “dark wake” that serves the screen without lighting the Mac’s own panel. The wait is limited to 60 seconds, and closing the tab ends it. A Mac that is already awake is never sent a packet; without a saved address nothing changes. If the Mac stays silent, the error says that it was also sent a wake-up packet and did not answer — it may be switched off, or on a network the packet cannot reach. The Mac itself must allow it: Wake for network access in its Battery or Energy settings. Windows 3.8.1, Linux & macOS 2.8.1.

The Mac's identity

Before your password is offered, BURSUcm checks who is answering. On the first connection it shows the Mac's host-key fingerprint (SHA-256) and asks you to confirm it — the same first-use model as an SSH host key; from then on a Mac whose key has changed is refused with a warning. Settings → AppleRD sets the policy: As set on the Security tab (follows the general certificate setting — an inherited “Off” still means “Ask once” for Macs), Ask once, then remember, Strict — only allow already-trusted Macs, or Off (insecure). Forget all trusted Macs clears the remembered keys. The password itself never crosses the network: the login is Apple's SRP handshake, and the session is encrypted with keys derived from it.

Clipboard

Text copies both ways. What you copy on this computer is sent to the Mac while its tab is the one you are working in; a secret copied from a credential card is never forwarded. What is copied on the Mac lands on your clipboard only while its tab is visible and has the focus, so a background session cannot replace what you have just copied.

Keyboard

In the Windows app (since 5.2.1) the Mac receives the character your keyboard layout produces: capitals, Caps Lock, symbols, and accents typed with a dead key — ´ then e gives “é”, ^ then e gives “ê”. Combinations with Ctrl or Win send the plain key, so a shortcut is the same on every layout, and letting go of both Shift keys at once lets go of both on the Mac.

• Windows: while the Mac’s picture has the keyboard, Win combinations reach the Mac as Command combinations — Win+C copies, Win+V pastes, Win+Tab is Command+Tab. Win pressed alone does not open the Start menu, and Win+L still locks this computer. Click outside the AppleRD tab to get the Windows shortcuts with Win back. Since 5.2.1.
• Linux: Alt+C and Alt+V act as Command+C and Command+V; the desktop keeps the Super key for itself.
• macOS: the Command key is Command.

High Performance: Apple's own limits

The fast path is Apple's constraint, not ours: Apple documents High Performance for Apple silicon Macs running macOS 14 or later, with Screen Sharing or Remote Management enabled. An Intel Mac (tested: an iMac 2020 on macOS 26) streams it as well, but it cannot darken its screen. The session runs over the connection's TCP port (5900); High Performance adds two UDP flows on that port and the next one (5900 and 5901 by default) in both directions — the client answers from the same two local ports — so a firewall on either side must let them through. A Mac that cannot offer High Performance still connects, as a plain screen without audio. Through a BURSUlink agent these UDP flows go through the agent, so nothing has to be opened on the Mac’s network.

On Android, iPhone and iPad

Since Android 2.0 and iOS/iPadOS 2.0 an AppleRD connection also opens on the phone and the tablet. On an Apple silicon Mac with High Performance the video is decoded in hardware and the Mac's sound plays on the device, and the Mac's screen goes dark for a private session or stays on as a mirror (without High Performance, or on an Intel Mac, the Mac's screen stays on). On the iPhone and iPad the Mac's virtual display turns with the device in a private High Performance session. The Mac's host key is confirmed on first use, as on the desktop. The limits: text copied on the Mac reaches the device's clipboard, but nothing is sent back to the Mac; on Android the video is always H.264, and the phone must be a 64-bit one.

What we deliberately do not implement

Apple's proprietary Apple Remote Desktop administration protocol (UDP 3283: silent observation, file and package deployment, task lists, inventory) is a separate, undocumented protocol. BURSUcm connects to the shared screen — which is what most people mean by “ARD” — and does not implement that administration protocol.

Telnet · Serial · Web · FTP

Telnet

The same embedded terminal as SSH (colours, copy/paste, broadcast, snippets). Note: Telnet sends everything in plain text — use it on trusted networks only.

Serial (COM port)

• Set the port (e.g. COM3 on Windows, /dev/ttyUSB0 on Linux) and baud rate on the connection.
• Serial options cover data bits, parity, stop bits, flow control.
• The classic case: a switch/router console over a USB-COM adapter.

Web (HTTP/HTTPS)

• The page opens in an embedded browser tab — handy for web panels (routers, IPMI, NAS) — that works like a browser: Back / Forward, Reload / Stop and Home; an address field with a lock that says whether the connection is secure; Copy address; Open in system browser; and a ⋯ menu with zoom, Find on page (Ctrl+F), printing and Developer tools (F12).
• Keys belong to the page first: a web console (Proxmox, iLO, iDRAC) gets Ctrl+R, Esc and the rest, and the browser keys act only when the page does not use them. Ctrl+W and Ctrl+Tab stay the app’s.
• Sign-in pop-ups (Google, Microsoft, single sign-on) open in a window of their own and complete; a link that opens a new page opens it in a new tab. A site that asks for the camera, the microphone, your location, notifications, reading the clipboard or downloading several files at once asks you first — Remember for this site keeps the answer.
• Downloads go to the Downloads folder and are listed with their progress — pause, Resume, cancel, open, Show in folder: on Windows in the Downloads window, which opens when a download starts and from the tab’s Downloads button; in the Linux & macOS app in the Downloads panel.
• A downloaded program, script, installer or disk image is never opened silently: on Windows Open asks first; the Linux & macOS app shows such a file in its folder instead of running it.
• A page opens at most 10 tabs in 10 seconds and 5 pop-up windows, and pages open at most 20 tabs and 10 pop-ups in all; when a page tries more, a notice says that some tabs were not opened.
• Settings → Security → Web browser clears the browsing data of all web tabs and forgets the sites’ permissions and the certificates accepted for them.
• You can store a login/password and enable “Ignore certificate errors” for internal self-signed panels; the exception applies only to that host, never globally. The saved login answers a sign-in only while the tab shows that device itself — never for a site it links to or a window such a site opens. The browser does not offer to save the passwords you type into pages: keep them in the vault.

FTP / FTPS

• A dual-pane file manager with the same transfer queue and whole-folder transfers as SFTP.
• Encryption: plain FTP (none), FTPS explicit (AUTH TLS) or FTPS implicit. Plain FTP sends the password in cleartext — use FTPS whenever the server supports it.
• Passive mode (PASV) is on by default — works behind NAT.

WinRM: PowerShell on Windows servers

Since Windows 3.3 and Linux/macOS 2.3 a connection of type WinRM opens a PowerShell or cmd.exe console on a Windows server as a terminal tab — no RDP session, no SSH server on the Windows side. PowerShell runs over PowerShell Remoting, cmd.exe over WinRS; both travel inside WS-Management on port 5985 (HTTP) or 5986 (HTTPS).

Creating a connection

• Type: WinRM. Host, port (5985 is pre-filled; 5986 for HTTPS), username and password — a saved credential works exactly as for SSH. A domain account is written as DOMAIN\user; a local account has to be a member of Administrators (or of Remote Management Users).
• WinRM options: transport (HTTP or HTTPS), shell (PowerShell or cmd.exe) and, for cmd.exe, the console code page — set 866 when you type Cyrillic into a cmd session; output is readable either way. On HTTPS there is also “Proceed past certificate errors” for a lab server with a self-signed certificate.
• Authentication is NTLM: the password never crosses the wire in clear, and a password asked for by a script (Read-Host -AsSecureString, a Password: prompt in cmd) is answered under the session key rather than as text on the screen.

Trust: certificates and plain HTTP

• HTTPS: the first connection shows the fingerprint of the server certificate. Verify it and choose “Trust & remember” — from then on the certificate is pinned the way an SSH host key is, and a changed certificate raises a warning instead of connecting silently. Settings → WinRM has “Forget all trusted WinRM certificates”.
• Plain HTTP: asked about once per server. NTLM seals the message bodies, but the server's identity is not verified — use HTTPS anywhere outside a trusted network. The trust dialogs may take their time; the tab waits up to three minutes for your answer.
• “Proceed past certificate errors” in the connection's WinRM options waives chain errors only where no certificate is remembered yet. A certificate you have trusted stays binding whatever the switch says, and under a strict policy a new certificate is refused (since Windows 5.0.2 and Linux & macOS 3.0.2).

Working in the terminal

• Output streams while a command is still running; Ctrl+C stops the pipeline; errors arrive as errors with the line they happened on, and $LASTEXITCODE is reported for the command that set it.
• Read-Host, -Confirm and a missing mandatory parameter ask and wait for you, as in a local console.
• clear / cls clear the window; Write-Host keeps its colours and -NoNewline; a multi-line paste runs every line; the tab splits into a second pane like an SSH tab, and broadcast input reaches it.
• What WinRM cannot do: there is no PTY, so no window resize, no full-screen programs and no tmux; and WS-Management has no file transfer, so there is no file panel — use SFTP, SMB or RDP drive redirection for files.

Enabling PowerShell Remoting on the server

Run in an elevated PowerShell on the Windows machine you want to reach:

Enable-PSRemoting -Force
# reachable from other networks, not only the local subnet:
Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress Any

An HTTPS listener with a self-signed certificate (its fingerprint is what you verify on the first connection):

$cert = New-SelfSignedCertificate -DnsName 'server.example.com' -CertStoreLocation Cert:\LocalMachine\My
New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $cert.Thumbprint -Force
New-NetFirewallRule -DisplayName 'WinRM HTTPS' -Direction Inbound -Protocol TCP -LocalPort 5986

BURSUcm carries its own WinRM client, so nothing on your side needs TrustedHosts or a domain membership.

On the phones: a WinRM connection is listed with its own colour, can be created and edited for the desktop, and the card copies host, user and password — opening it is desktop-only for now.

AI assistant (optional)

Since Windows 3.0 and Linux/macOS 2.0 the app can open an AI chat right beside a session: the assistant sees the same terminal you do, explains output, investigates failures and can run commands — read-only ones on its own, anything that changes the system only after you approve it.

The feature is strictly opt-in. It does nothing until you add your own API key (or connect a local model), every AI element disappears when you untick one checkbox in Settings → AI assistant, and an administrator can switch it off per user.

Enabling it: keys and providers

• Open Settings → AI assistant and tick Enable AI assistant. The AI button then appears on the toolbars of SSH and WinRM (and, on Windows, RDP) sessions.
• Add a key: OpenAI, Google Gemini, Anthropic Claude, DeepSeek, OpenRouter, Groq, Mistral, xAI and Together are built in with fixed endpoints; any other OpenAI-compatible service is added as the Custom (OpenAI-compatible) provider with its own Base URL.
• Or use no key at all with local models: Ollama, LM Studio, llama.cpp — they run on your own machine and work offline.
• Keys are stored in your database, encrypted with the master password — in cloud mode the server only ever sees ciphertext. The active key is marked ★, and you can switch keys right in the chat.
• Per-user control: in the user editor an administrator can untick Can use the AI assistant, and the feature disappears for that user on every device.

Note: a ChatGPT or Claude subscription does not include API access — the assistant uses the API, which providers bill separately. Local models need no key and cost nothing.

In an SSH session

• Commands that only look at the system (df, ps, journalctl, cat…) may run automatically — that is the administrator setting Run read-only commands without asking. Anything that may change the system is explained first and waits for Run or Skip.
• Secret Shield finds and redacts passwords, API keys, private keys, tokens, cookies and .env contents before any text is sent to the provider.
• Give the assistant evidence: paste a screenshot from the clipboard, or attach logs, configuration files and documents. Text is extracted for analysis; images go to every provider except DeepSeek, which has no vision models.
• Find cause of error builds a focused diagnosis in one click; Create session report produces a copyable record of the problem, commands, results and final checks — with detected secrets hidden.
• Risky changes get a safety net: the assistant can save the original state, show the diff, apply, validate the result — and roll everything back in one click if the check fails. Chats can be created, renamed, archived, restored and deleted, and the panel itself can be pinned to a connection; a long conversation can be compacted without losing its working summary.
• The terminal stays yours. Whatever you type goes to the shell at once, even while one of the assistant's commands is running. A prompt meant for you — a sudo password, a yes/no — is waited for (“Waiting for your input in the terminal”, no clock running); the timeout counts silence rather than minutes, so a long upgrade that keeps printing is not cut off; and interactive programs such as htop are started and handed over to you.

In an RDP session (Windows app)

On Windows the assistant also works inside RDP sessions, combining a persistent PowerShell channel with visual control for tasks that only exist in the GUI.

• PowerShell commands run in a session window you can watch on the remote desktop, and their exit codes are verified.
• Screenshot access is a separate, explicit permission — Secret Shield protects text, but it cannot reliably hide secrets visible inside a screenshot.
• Autopilot may continue locally verified read-only PowerShell commands on its own; clicks, typing, hotkeys and any unknown command always wait for your approval.

In a WinRM session

The assistant works in WinRM tabs as it does in SSH, and judges a PowerShell line by PowerShell's own rules: a method call anywhere in the line ($_.Delete(), (Get-Service x).Stop()), a static member and every script block wait for your click, so Get-ChildItem | ForEach-Object { $_.Delete() } is never treated as a reading command. Reading a file that may hold secrets (the SAM and SECURITY hives, web.config, appsettings, keys, .ssh), any UNC path and -ComputerName ask too, because what is read goes to the AI provider with the output.

What leaves your machine — and how to turn it all off

• Your messages and the output of commands the assistant runs go from your device directly to the provider of the active key — or to a local model, in which case nothing leaves the machine at all. BURSUcloud servers never see this traffic.
• Chat history is stored locally and encrypted; the output of commands is not written into chat files.
• Do not use the assistant on servers where sending session output to a third party is not allowed — the warning in Settings exists for exactly this.
• To remove the feature entirely, untick Enable AI assistant in Settings: every AI button and panel disappears. Administrators can additionally disable it for individual users.

Credentials

Saved credentials live separately from connections — one credential can be linked to dozens of servers, and a password change is done in one place.

How to use them

1. Open Credentials in the sidebar → “New credential”. Fill in a display label, username, password, group — and, if you like, a comment: a free note about what the account is for (an import from a password manager puts the entry’s notes there). The comment is not encrypted, so keep secrets out of it.
2. In a connection, pick this credential in the “Saved credential” field — instead of typing.
3. If a credential is deleted, linked connections switch to manual entry (the password is asked on connect).

SSH keys as credentials

Since Windows 3.1 and Linux/macOS 2.1 a credential can be an SSH key, not only a password — “New credential” asks which kind you want. A key record keeps the private key and its passphrase encrypted under the master password, with the public key and a comment beside them; load the key from a file and the matching .pub next to it is picked up automatically. Folders, permissions, owners, backups and sync apply to it exactly as to a password.

• In a connection, pick the key from the same folder tree as any credential — keys carry a key icon, passwords a padlock — and the authentication method follows. The key is used for the target and for every jump host in the chain.
• A stored key never copies into the connection: unlinking restores the connection’s own fields, and a key you may edit but not reveal is shown as a write-only field, not an empty box.

Built-in password generator

Next to the password field is a generate button: choose the length and which character classes to include (upper/lower case, digits, symbols) and drop a strong random password straight into the field — no separate tool, and the new value is stored encrypted like any other.

Two-factor codes (TOTP)

A credential can also hold a two-factor secret, so the one-time code lives right next to the login it belongs to:

• Paste the Base32 secret or a full otpauth:// URI into the credential’s TOTP field (the same value a phone authenticator would store).
• The credential then shows a live six-digit code with a countdown; “Copy TOTP code” puts the current one on the clipboard in a single click — no phone in hand.
• The secret is protected by the master-password vault exactly like a password, and syncs the same way, so the code is available on every device you sign in on.
• These codes belong to the servers you log in to. The code that protects your bursucm.com account itself comes from the authenticator app on your phone — see Two-factor sign-in.

Folder inheritance

A connection folder can have a default credential: every connection inside without its own credential uses the folder’s one. The typical case — one admin login for a whole rack/subnet. The connection card shows “Folder credential — …” when inheritance applies.

Credential groups can be reordered by hand just like connection folders — hover a row for the arrows (see Your own order).

Master password & the vault

Saved secrets are encrypted always. The only question is with which key:

Day-to-day

• On startup the app asks for the master password. You may skip: connecting still works, but saved passwords stay locked. If a locked password is needed for a connection, the app simply asks for it right there instead of failing.
• “Remember on this computer” stores not the password itself but a local key protected by the operating system — no typing at startup. “Forget” undoes it.
• The state is visible on the Home dashboard (the vault card) and in Settings. Quick lock — Ctrl+L.
• Change the master password: Settings → Security → “Change master password…” — all secrets are re-encrypted.
• The Generate button in the set/change dialog creates a strong random password (16 characters, without look-alike characters) and shows it so you can write it down.
• For a BURSUcloud database the master password is set right in the app as well: every stored password is encrypted on your device before it is uploaded — the master password itself never leaves your computer. While no master password is set, the database page on the portal shows a red warning with the same action and a password generator.
• A master password must be at least 12 characters — long enough to resist offline guessing, since it is the one key that protects every saved secret.

Password policy

The administrator sets requirements for app users’ passwords: minimum length and required character classes (lowercase, uppercase, digits, special) — Settings → Security.

Users & permissions

The User Management window (Home dashboard → “Manage users”, or the sidebar). The permission model is the same for local, PostgreSQL and cloud databases.

Roles

Per-folder rights

For every connection folder and credential group — three checkboxes:

• Read — see the folder and connect;
• Edit — create/change/delete inside it;
• Passwords — reveal saved passwords in cleartext (without this right connecting still works, but the password stays hidden).

A grant on a folder covers its subfolders. The “All folders” row is the default rule.

Since Windows 3.1 and Linux/macOS 2.1 the rights live on the Access permissions tab of the user window (next to General) as one folder tree instead of two tables: switch it between connection and credential folders, fold it, search by the full path, show Only granted, expand or collapse everything, and read the counter. The All folders row ticks and locks the rows below it — a right granted to everything cannot be taken back one folder at a time. The tree lists every folder the main window shows, the example folders included.

When a shared connection is repointed

In a BURSUcloud database several people edit one catalog, and the Edit right does not include Passwords. Someone who may change a connection but not see its password could point it at a machine of their own and wait for you to connect with the saved secret. So the app remembers — on this computer, never in the shared database — where each connection went the last time you connected: host and port, the linked credential, the jump host, the RD Gateway and the connection type. The first connection is remembered silently. If any of these has changed since, connecting first shows Routing changed — “This connection no longer goes where it did” — with Previously connected to and Now points to side by side. Cancel sends nothing and keeps the old routing on record; Connect anyway accepts the new one. If you made the change yourself, simply confirm it. The same question is asked for a jump host on the way, and before Get MAC signs in over SSH.

A local database and your own PostgreSQL server are not checked: there is no third party between you and the catalog. The check is in the Windows app, and since 2.8.1 in the Linux & macOS app; the RD Gateway and the connection type are compared since Windows 3.8.1 and Linux & macOS 2.8.1. It is a warning, not encryption — read it before you press the button. Since Windows 5.0.2 and Linux & macOS 3.0.2 the security switches are compared as well — “Proceed past certificate errors” and plain HTTP for WinRM, no TLS for FTP, ignored certificates for a web tab, encryption off for VNC — so flipping one of them on a shared row asks the same question.

Users in cloud mode

For a BURSUcloud database the Users window lists two kinds of entries:

• Both kinds carry the same per-folder rights (read/edit/passwords) and the snippets right. They can be managed both from the app and on the portal — it is one and the same database.
• Database users are stored inside the customer database itself, so a full backup or SQL dump moves them together with the catalog, and changing the database handle applies instantly.
• The database owner (the account that created it on the portal) is always an administrator: they cannot be demoted or removed — the database is never left without an admin. Local databases enforce the same rule for the last administrator.

User groups

The User Management window has a second list, User groups. A group is a named set of per-folder rights (plus the snippets right) that every member inherits on top of their own — put people in groups instead of repeating the same rights on each account, for example a “Linux Admins” group with read / edit / passwords on the Linux folder.

• Rights add up. A user’s effective rights are their own grants plus every group’s. A group never takes a right away, and it never grants the administrator role or the AI assistant flag — those stay on the user.
• Inherited rights are visible. On the user’s Access permissions tab the folders a group grants are shown as green ticks, locked, while the account’s own rights keep the normal colour; change the green ones on the group. The Groups list on the General tab says which groups the account is in.
• Groups are stored next to the users — in the local database, in your PostgreSQL database or inside the BURSUcloud customer database — so backups, snapshots and SQL dumps carry them. In cloud mode both database users and portal members can be put in a group, from the app or on the portal.
• Deleting a group leaves its members with only the rights granted to them directly. Changes apply on the next sign-in for a local database and on the next catalog refresh for a cloud one.

Your settings on this computer

Everything the app keeps outside the database that is yours — settings, trusted host keys and certificates, logs and session transcripts, the offline cache, AI chats, the web tabs’ cookies, the remembered master password — lives in a folder of your own on each computer (Users\<name>-<id> under the app’s data folder). The app switches to it the moment you sign in.

• Every account gets its own settings. Two people using the same computer do not see each other’s theme, trust decisions or logs, and a person who comes back finds everything as they left it. Nothing is deleted when somebody else signs in.
• All settings tabs are open to every user. SSH, RDP, VNC, WinRM, Logs and the others are yours to change. Only what describes the shared database stays with administrators: switching the database, import / export, the master password, the password policy, users and groups.
• Local data. In User Management an administrator can remove another account’s folder from this computer with the Delete local data… button — the account and the database are kept. The folder of the signed-in account cannot be removed while it is in use.

BURSUcloud

BURSUcloud is the optional cloud that syncs your catalog across devices and a team. The same catalog is available from the Windows app, the Linux/macOS app, the web portal, Android and iOS/iPadOS.

Creating an account

1. Open bursucm.com/register. Five ways: email + password (8 characters minimum), or “Continue with Google”, Microsoft, Apple or GitHub (personal and work accounts both work).
2. With email sign-up a confirmation link arrives by mail — it is valid for 24 hours. Nothing came? Check spam or click “Resend link” on the sign-in page.
3. After confirming, sign in — you land in “My databases”.

Creating a cloud database

1. Click “+ New database”.
2. Name — how the database appears in lists (e.g. “Prod infrastructure”).
3. Handle — a unique short id of letters, digits and dashes. It becomes part of database users’ logins: name@handle. Leave blank to auto-generate; you can change it later, but that updates user logins.
4. Master password (optional) — you can set it right away to encrypt connection passwords. Without one the database works plainly; set it later in the database’s Settings or from the app.

Connecting the app to the cloud

1. In the app: pick BURSUcloud on the first-run screen — or, if the app already opens another database, sign out and sign in to BURSUcloud on the login screen (Settings → Database cannot switch into the cloud).
2. Sign in with your portal email and password — or with Google, Microsoft, Apple or GitHub (a browser opens; the app picks the sign-in up automatically).
3. If your account has two-factor sign-in on, the app asks for the 6-digit code (or a recovery code) in its own window right after the password. A Google, Microsoft, Apple or GitHub sign-in does not ask for it.
4. Choose a database from the list (“Refresh databases” re-reads it) → “Use selected”.
5. If the database has a master password, the app asks for it and offers to remember it on this computer (a locally protected key is stored, not the password itself).

What syncs

Connections and folders (including folder order, your manual item order and collapsed state), credentials, snippets, users and rights, each connection’s SSH, WinRM, RDP, VNC and Apple Remote Desktop options (including jump hosts, tunnels and the BURSUlink agent a connection goes through). The app’s own preferences (theme, language, hotkeys) stay local.

The security model

• Every database is a separate PostgreSQL database; the DBMS is not reachable from the internet — only the portal itself, on the server, talks to it.
• Clients use the HTTPS API with tokens: a token lives 30 days, sliding with use (hard cap 90 days), at most 10 active tokens per account, and signing in again revokes the previous token.
• Connection passwords are encrypted with the master password on your device; the server stores and relays ciphertext only (zero-knowledge). That is why a forgotten master password cannot be recovered even by support.
• A sign-in from a new IP address triggers an email notification; so does a password change.
• The account itself can be protected by two-factor sign-in: a code from an authenticator app after the password, with ten one-time recovery codes.

Working offline

When the network drops — or the database itself becomes unreachable — the app keeps working from an encrypted local copy of your catalog. You can browse and edit connections and credentials, and even start the app with no connection at all. A status bar shows the state: red while offline (with a counter of unsynced changes and a “Retry” button), amber while synchronising, green “Synchronized” for a moment when it finishes.

Changes you make offline are queued and uploaded automatically as soon as the database is reachable again. If the same item was changed both on your device and on the server, a conflict window shows the two versions side by side and lets you keep either one (passwords are never shown there). Availability is detected by pinging the database itself, so a dead server is noticed even while the internet is fine. This works for both BURSUcloud and a direct PostgreSQL database — for PostgreSQL an up-to-date local mirror is kept on your computer.

BURSUlink: a computer behind NAT

A home PC behind a router, a laptop on a mobile connection, a server in an office with no public address — BURSUlink reaches them with no port forwarding, no public IP and no VPN. A small agent on that computer keeps one outbound connection to the nearest BURSUlink relay. When you open a connection, bursucm.com signs a pass for it — one agent, one device, one connection, two minutes — and the session goes through to the agent: directly through the NAT when the routers allow it, through the relay otherwise. Traffic is encrypted end to end between your device and the agent; a relay forwards packets it cannot read. BURSUlink is part of BURSUcloud at no charge: the agent is linked to a BURSUcloud database, and the database’s members connect through it. Downloads and the long story are on bursucm.com/bursulink; this chapter is the working part.

Linking a computer

1. On bursucm.com open the database, then the BURSUlink tab, and press Add agent: name it, choose the mode (next section) and copy the one-time code. It is valid for 15 minutes.
2. Install the agent on the computer you want to reach — not on the one you connect from. Windows: one installer for x64 and ARM64; it installs the service and the status icon after one administrator consent. macOS: one image for Intel and Apple silicon — drag BURSUlink to Applications, start it and press Install in the Service tab. Linux: the packages from the same repositories as BURSUcm (set up once); ARM64 servers get the service only (.deb, .rpm), and the Arch package is for x86-64 only. One command as root does it all: curl -fsSL https://bursucm.com/downloads/bursulink.sh | sudo sh adds the repository, installs the agent, asks for the code, links the computer with it and starts the service. On a computer with a desktop it installs the window and the status icon too; on a server, on ARM64 and where no repository has WebKitGTK 4.1 (RHEL, Rocky and AlmaLinux 9) it installs the console agent — the service alone — and says which one and why. glibc 2.34 or newer is required (Ubuntu 22.04+, Debian 12+, RHEL 9+, Fedora, Arch); an older system is refused before anything is changed. Without a terminal, as root: curl -fsSL https://bursucm.com/downloads/bursulink.sh | BURSULINK_CODE=CODE sh. The code is never put on a command line, where other users of the server could read it.
3. In the agent’s window press Link this computer and paste the code — or sign in there with your portal account and pick the database (an account with two-factor sign-in is asked for its code once, agent 1.0.1). The computer appears in the BURSUlink tab within seconds, with its mode, version, last contact and whether it is online.

The agent runs as a Windows service, a systemd unit or a macOS LaunchDaemon: it starts with the system, before anyone signs in, and needs no window. It only ever connects out — 443/tcp and 7842/udp — so nothing on the router or the firewall changes. The same computer can be linked to up to eight databases; each link has its own key, and removing one touches nothing else.

Two modes

Connecting through an agent

In the connection window, in BURSUcloud mode, the BURSUlink connection field above Host and Port offers Direct or Through BURSUlink with the agent’s name; it is shown only for the types the tunnel carries. The connection keeps its real host name — the SSH host key and the RDP certificate are checked against it as before — and shows a BURSUlink mark in the tree and the agent’s name on its card. Every member of the database who may open the connection can use it: per-folder rights and user groups apply exactly as for a direct connection, and an account with two-factor sign-in must have signed in with the code — otherwise the app offers to sign in again.

• Protocols: SSH, SFTP, Telnet, RDP, VNC, WinRM, Apple Remote Desktop, web pages and FTP/FTPS go through the agent. A web page opens in its own browser profile, so local addresses and WebRTC cannot slip past the agent; every FTP data channel takes the tunnel too. Apple’s High Performance mode sends its picture and sound over UDP through the agent — over a relay only when the agent’s Allow High Performance over a relay switch on the portal is on; otherwise the session opens in the standard mode and says why. Not through it: Serial. RDP through the agent uses the BURSUrdp engine, and Open with Remote Desktop cannot go through it.
• RDP redirects: when the server hands the session on to another address (an RD Connection Broker does), RDP through an agent stays on the tunnel — or stops and says why — instead of dialling that address directly, and a chain of redirects ends after four hops. The BURSUrdp engine does the same for RDP through an SSH port forward. Windows since 5.2.1, Linux & macOS since 3.2.1.
• One route per connection: an agent replaces a jump host and an RD Gateway. Saving a connection with an agent removes them, and the window says so first; a jump host that itself goes through an agent is refused — if a connection already has one, its SSH options show it by name, marked “· BURSUlink”, and say why it cannot be used.
• What the app tells you: an offline agent is named with its last contact time; an agent removed on the portal shows as removed agent in the connection window — choose another; “did not answer” means the agent did not take the pass within its two minutes, or no relay can reach it.
• A different agent on a shared connection is part of the repointed-connection check: the agent passes on everything the connection sends.
• Where: the Windows app since 5.2.0; the Linux & macOS app from 3.2.1 — use 3.2.5 or later, because 3.2.3 refused RDP and SSH through an agent. Web pages, FTP and High Performance through an agent need agent 1.0.0 with Windows 5.2.2 or Linux & macOS 3.2.3 or later. When the agent runs on the target computer itself, the tree, the card and the tab show the agent’s name instead of the stored host, and search finds the connection by it. The Android and iOS apps do not connect through an agent yet.

To stop an agent, remove it in the BURSUlink tab: its passes stop at once, and it wipes itself the next time it connects. Uninstalling BURSUlink on the computer removes the agent from the portal as well.

The web portal: a full guide

The portal at bursucm.com is the browser control centre for cloud databases. Whatever you change on the portal is immediately visible to the apps, and vice versa.

My databases

The Databases section lists your databases in the columns Name, Database (the PostgreSQL database’s own name), Role (owner, or member of someone else’s database), Status and Created. Manage opens the database console with its tabs.

The Connections tab

• The same folder tree as in the app: expand/collapse (plus “expand all / collapse all”), per-folder connection counts.
• Reordering: ↑ ↓ arrows on every folder and on every connection — the page reorders instantly, without reloading, and the result is the same order your apps show.
• Add: “+ Add connection” — a three-step wizard: folder → details (type, name, host, port, username) → password. New folders via “+ New folder” or right inside the wizard.
• Edit / delete / move — the Edit/Delete buttons on a connection row; an empty folder can be deleted; one that still holds connections or subfolders is refused. The edit window also sets the BURSUlink route — directly or through an agent of the database (see BURSUlink). If the connection was changed in an app or another tab while the window was open, nothing is overwritten: the save is refused and the window opens again with the current version.
• Revealing passwords: the “Master password” field on top with “Unlock & reveal”. Passwords are decrypted on the server, for this page view only: the master password travels with the request over HTTPS and is not stored. The apps never send it — there, passwords are decrypted on your device. When editing a connection, the box shows the connection’s own password once it may be revealed; it stays empty for a password that comes from a linked credential or that you may not see — then “leave blank to keep the current one”.

The Credentials tab

The same saved credentials as in the app, grouped, with the same ↑ ↓ reordering on rows. Adding and editing works like connections (label, username, password, group); a connection folder’s default credential — the one its connections without a login of their own inherit — is chosen in the folder’s edit window, and a key on the folder shows it.

The Snippets tab

• The shared library as a table: name, command, group. “+ Add snippet” / Edit / Delete.
• {placeholders} behave exactly as in the app: values are asked when sending from a terminal.
• The tab is visible to the owner, administrators and users with the snippets right.

The Users & access tab

Two lists:

• Both are edited with a step wizard: step 1 — role (admin = full access) and global flags (edit, reveal passwords, snippets); step 2 — per-folder connection rights (view/edit/reveal); step 3 — credential-group access.
• For database users the Sessions column shows the number of active devices: click to open the list (device, IP, last used, expiry) with per-token and revoke-all buttons.
• The database owner cannot be removed or demoted — the database always keeps an administrator.

A third card, User groups, holds sets of rights that database users and members inherit (see User groups). Its wizard has four steps — group (name, description, snippets right), connection folders, credential groups, members. The user and member wizards offer the groups on their first step, and both lists show a Groups column.

The BURSUlink tab

Owner only. It lists the computers linked to the database — name, mode, version, last contact, online or not — and the one-time codes still waiting for an agent, each with a countdown. Add agent makes a code (valid for 15 minutes; New code renews an expired one, Cancel withdraws it), edit renames an agent or changes its mode and its allow-list, and remove shuts it out at once. The whole procedure is in BURSUlink.

The Settings tab

• Name and handle. Changing the handle updates every database user’s login instantly — warn your team.
• Master password: set or change (the current one is required). Setting it re-encrypts the database’s passwords.
• Export .sql — a full dump as a file; Import .sql — upload a dump (the “replace schema before import” checkbox wipes the database first). Dumps contain data — keep them private.
• Danger zone: permanent deletion of the database with all its data.

Import & export on the portal

The same import and export as in the desktop apps also lives on the portal — move connections between the app, the portal and other tools with one portable backup file (see Importing from other tools and Export & backups). KeePass, 1Password and Bitwarden / Vaultwarden come in here too, and are read in your browser: neither the file nor its password is sent to the server. The entries read from it go to the server over HTTPS for the review, where you choose which to import.

Profile & devices

• Profile — first/last name, nickname, portal language, password change — and the sign-in methods card: see every way into your account (password, Google, Microsoft, Apple, GitHub), link a new provider, unlink one, or set a password for an account created through a provider. The card never lets you remove the last remaining way in.
• Connected devices — every app signed in to your account: device name, IP, last used, expiry. Revoke signs out one device, “Sign out all” — all of them: each app will ask to sign in again. Use it if a device is lost.
• Two-factor authentication — a code from an authenticator app on top of the password, with recovery codes for a lost phone; see Two-factor sign-in.
• Delete account — removes the account and every database it owns, after your current password. The Android and iOS apps have the same button in their Settings.

Downloads & status

• /download — installers and packages for every platform, SHA-256 checksums, repository setup commands, the full changelog in 8 languages.
• /status — live checks of the portal, API, PostgreSQL and mail + recent incidents.

Two-factor sign-in for your bursucm.com account

Since October 2026 a bursucm.com account that signs in with a password can ask for a second proof as well: a 6-digit code from an authenticator app on your phone. Whoever learns the password still cannot open the account — its databases, their users and the devices signed in to it. It stays off until you turn it on; nobody is forced to use it, administrators and database owners included.

Turning it on

1. On bursucm.com open Profile. The Two-factor authentication card says Off: press Turn on, type your Current password and press Continue.
2. Set up your authenticator app: scan the QR code with Google Authenticator, Microsoft Authenticator, 1Password or any other authenticator app. Cannot scan it? The window also shows the key as text — type it into the app instead. The new entry is called BURSUcloud, with your email beside it.
3. Type the 6-digit code the app shows and press Turn on. The setup waits 10 minutes; after that, start again with Turn on. If the code is refused, check that the phone's clock is set automatically.
4. Your recovery codes appear: ten codes like abcde-fghij. Each one works once, and they are shown only now. Press Copy codes, keep them somewhere safe and away from the phone — a password manager or a printed sheet — and press I have saved them.

Turning it on signs out every other browser and device signed in to the account, so each app asks you to sign in again — this time with the code. An email confirms the change.

Signing in with the code

• On the website: after the password a Two-factor authentication page asks for the Code → Verify. The page waits 10 minutes and accepts five wrong codes; ten wrong codes within an hour lock code entry on the account for an hour.
• In the apps — Windows 5.1.5, Linux & macOS 3.1.5, Android 2.0.1, iOS/iPadOS 2.0.1 and later: type the email and password as usual, and the app opens its own Two-factor authentication window with one field. Type the 6-digit code — or a recovery code — and press Sign in. A wrong or expired code is reported in the same window, and you simply type the next one; after too many attempts the window asks you to wait a few minutes. Cancel returns to the sign-in form and forgets the password you typed.
• Older app versions cannot sign in to such an account with the password: update the app, or sign in with a linked Google, Microsoft, Apple or GitHub account.
• Offline: the desktop apps no longer open a two-factor account offline with the password alone. An app that is already signed in keeps working offline from its saved copy of the catalog, as before.
• Database users (logins like name@handle) are not affected: two-factor sign-in belongs to bursucm.com accounts.

Google, Microsoft, Apple and GitHub

Signing in with a provider does not ask for the code: the provider's own sign-in — with its own second factor, if you turned it on there — is trusted. Linking a new provider to an account with two-factor on does ask for a code (or a recovery code), so someone who got into your mailbox cannot attach their own provider account. The card is shown only to accounts that can sign in with a password; an account created through a provider first sets a password on the sign-in methods card of the same page.

Recovery codes, turning it off, a lost phone

• How many are left: the card reads “On — N recovery codes left” and warns when three or fewer remain. A recovery code goes into the same field as a code from the app — on the website and in every app — and is used up once accepted.
• New recovery codes: your password and a code from the app (or a recovery code) give ten new codes; every old one stops working.
• Turn off: your password and a code (or a recovery code). Every other device is signed out, and an email confirms it.
• A lost or replaced phone: sign in with a recovery code, then turn two-factor off and on again to move it to the new phone. Resetting the password does not turn two-factor off.
• Phone and codes both lost: the code page has a Contact link to support. Once it is confirmed who is asking, a BURSUcloud administrator can reset two-factor on the account; you get an email about it, and every other device is signed out.

The Linux & macOS app

BURSUcm for Linux and macOS is the same connection manager, built for those systems from one codebase. If you know the Windows app, you already know this one: the same catalog, the same storage modes (local, PostgreSQL, BURSUcloud), the same SSH features, credentials, vault, users, snippets, split view and broadcast. This chapter covers what is specific to it.

What is different from the Windows app

Finding your way around

• The sidebar switches between Connections and Credentials; folders expand in place, and hovering any row shows the ↑ ↓ reorder arrows (see Your own order).
• Quick connect sits on top of the sidebar: pick a protocol, type user@host:port, press Enter — a one-off session without touching the catalog.
• The Home tab shows the same dashboard: stats, recent, favorites, vault state, quick actions. Session tabs, split view, broadcast, full-window and full-screen modes behave as described in the shared chapters.
• Light and dark themes, and the same eight interface languages (English, German, Spanish, Portuguese for Brazil and for Portugal, Russian, Ukrainian, Georgian) — in Settings; the four new ones from 3.2.1. On its first start the app opens in your system’s language when it is one of the eight.

Signing in

Cloud sign-in offers the full set: email/password, Google, Microsoft, Apple, GitHub, or a database user login (name@handle). Browser-based sign-ins open your default browser and return to the app automatically. If the account has two-factor sign-in on, a Two-factor authentication window asks for the code right after the password; provider sign-ins do not ask for it.

Android app

Install it from Google Play, or as a direct APK from the download page. It is a client for the cloud catalog: sign in with the same account — email/password (plus the two-factor code if your account has it on), Google, Microsoft, Apple or GitHub, or a database user login name@handle — and you get the same folders and connections, in the same order you arranged on the desktop. Version 2.0 (October 2026) brought it close to the desktop:

• Sessions: SSH and Telnet terminals, built-in RDP and VNC, and AppleRD to a Mac, High Performance video and sound included; a Web connection opens in the system browser. Sessions — file transfers and remote desktops included — keep running while the app is in the background; up to 5 at once by default (1–20 in Settings).
• Remote desktops: a trackpad pointer or direct touch, a key row with Esc, Tab, Win and Ctrl+Alt+Del, and on rotation the desktop follows with a matching resolution without reconnecting. RDP goes through the RD Gateway set on the desktop. Not on the phone: clipboard sharing in RDP and VNC, and RDP sound.
• SSH: jump hosts, local (-L) and remote (-R) port forwards, tmux, Ed25519 keys and the per-connection Send LANG=en_US.UTF-8. A dynamic (-D) forward is kept with the connection but starts only on the desktop.
• Terminal: the desktop's colour schemes and font size, Find in the output, session logs with Share output, the database's snippets — sent with a tap, added and edited here — a key row with Ctrl, Alt, Esc, Tab, the arrows, Home/End, PgUp/PgDn and F1–F12, and a question before a multi-line paste runs.
• Files (SFTP and FTP): select several items to download, move or delete them at once; download or delete a whole folder; view and edit a text file on the server; sort by name, size or date and show hidden files; rename, create folders and (SFTP) change permissions. Uploads go one file at a time.
• Catalog: Favorites and Recent, tags, Quick Connect and Copy As; folders with new subfolder, rename, move, delete and the folder's default credential; your manual order, changed with a row's drag handle; Wake on LAN from a row's menu; “Last used by …” on the connection card. Search expands the folders that contain matches.
• Credentials: login/password and SSH-key records, live TOTP codes from a record's two-factor secret, a password generator and a private key imported from a file.
• Offline: changes made without a connection are queued on the phone and sent when the portal is back; a strip above the catalog shows the state, and a conflicts window lets you keep either version, as in the desktop apps.
• Tablets and theme: a side-by-side layout with the catalog on the left and a welcome pane with quick actions and live catalog numbers on the right — a Home button always brings you back to it. The theme follows the system light/dark setting, or is fixed in Settings.
• Unlock and lock: fingerprint (or device PIN) unlock — the vault key is protected by an Android Keystore key that cannot be used without a successful check; Lock App on Start asks for it at launch. The vault locks after 5 minutes in the background and after 10 idle minutes.
• Privacy: Block screenshots (off by default) hides sensitive screens from screenshots and screen mirroring; Clear clipboard empties a copied secret after the time you set; certificate pinning accepts only the genuine bursucm.com certificate; and signing in again revokes the previous session, so the portal's “Connected devices” list stays true.
• Your account: Settings → Delete account deletes your bursucm.com account and every database it owns after one confirmation (Delete account permanently), and removes this phone's session logs and crash records with it. Report a problem sends a report from the app; nothing leaves without your tap.
• Not on Android: opening WinRM connections (they can be created and edited here, and the card copies host, user and password) and serial ports, the AI assistant, split view and broadcast, users and rights, Get MAC, and automatic reconnect — a dropped session is reopened by hand. Import reads only the app's own export file, which carries no passwords.

iOS & iPadOS app

BURSUcm for iPhone and iPad is one universal app, free on the App Store for iOS and iPadOS 17 or newer. Sign in with the same account — email/password (plus the two-factor code if your account has it on), Google, Microsoft, Apple or GitHub, or a database user login — and the same catalog opens: the same folders and connections, in the order you arranged them, with every password decrypted on the device only. Version 2.0 (October 2026) brought it close to the desktop:

• Sessions: SSH and Telnet terminals, SFTP and FTP, built-in RDP and VNC, and AppleRD to a Mac — High Performance video and sound included, with the Mac's virtual display turning with the device; a Web connection opens in the default browser. A live session asks iOS for the extra half-minute it allows when you switch apps, so a transfer or a command in progress does not drop the moment you glance away.
• Remote desktops: touch gestures (tap = click, two-finger tap = right click, two fingers = scroll, double-tap and drag = drag) and a floating control pad with Esc, Tab, Del, the arrows, function keys and Ctrl+Alt+Del. RDP goes through the RD Gateway set on the desktop. Not on the device: clipboard sharing in RDP and VNC, and RDP sound.
• SSH: jump hosts, local (-L) and remote (-R) port forwards, tmux and the per-connection Send LANG=en_US.UTF-8. A dynamic (-D) forward is kept with the connection but starts only on the desktop.
• Terminal: two extra key rows above the on-screen keyboard — Ctrl, Esc, Tab, ^C, common symbols and Paste; F1–F12, Home/End, PgUp/PgDn and the arrows — so htop, mc and other TUIs are usable on a phone, while a hardware keyboard passes its modifiers straight through. The desktop's colour schemes and font size, Find, session logs with Share output, the database's snippets (sent with a tap, added and edited here), and a safe paste: control characters are stripped and a multi-line paste asks first.
• Files (SFTP and FTP): select several items to download, move or delete them at once; download or delete a whole folder; view and edit a text file on the server; sort by name, size or date and show hidden files; upload, rename, create folders and (SFTP) change permissions. Downloads land in the BURSUcm folder of the Files app.
• Catalog: Favorites and Recent, tags, Quick Connect and Copy As; folders with new subfolder, rename, move, delete and the folder's default credential; your manual order with Move up / Move down in a row's menu; “Last used by …” on the connection card; and Wake on LAN from a row's menu — sent straight to the machine's own address, because iOS lets an app send broadcasts only with a special Apple permission.
• Editing on the go: connections and credentials are created and edited on the device, jump hosts and port forwards included; a credential shows live TOTP codes from its two-factor secret, has a password generator, and takes a private key imported from a file.
• Offline: changes made while the portal cannot be reached are kept on the device and sent when it is back — connections, folders, manual order and folder state alike. A strip above the catalog shows the state, a conflicts window lets you keep either version, and signing out with unsent changes warns you first.
• iPad: a split layout with the catalog beside a live session, pointer support (a trackpad or mouse drives the real remote cursor in RDP and VNC), full hardware-keyboard modifiers, the desktop's shortcuts for switching sessions (Ctrl+Tab, ⌘1–9, ⌘W), and Stage Manager for several sessions side by side.
• Face ID / Touch ID: the vault key is held behind the system biometric store; Lock App on Start asks for it whenever the app comes back. The vault locks after 5 minutes in the background and after 10 idle minutes — typing on a hardware keyboard counts as activity.
• Security: certificate pinning for bursucm.com, SSH host-key verification, and RDP certificates on the trust-on-first-use model — with the server required to prove it holds the certificate's private key. Trusted hosts and certificates are forgotten per protocol in Settings.
• Your account: Settings → Delete account deletes your bursucm.com account and every database it owns after one confirmation (Delete account permanently), together with this device's session logs and crash records. Report a problem sends a report from the app; nothing leaves without your tap.
• Not on iPhone and iPad: opening WinRM and serial connections (they can be edited here), the AI assistant, split view and broadcast, users and rights, import and export, Get MAC, and automatic reconnect — a dropped session is reopened by hand.

Importing from other tools

Moving in from another connection manager is a single window: Settings → Data → Import (also available on the web portal). Pick the source, review the preview, click Import.

Supported sources

The preview step

• Before anything is written, the import shows a folder tree of what it found — tick exactly the folders and connections you want.
• Choose a target folder in your catalog; the imported structure lands inside it.
• Imports are additive: nothing existing is overwritten or deleted.

From a password manager

KeePass, 1Password and Bitwarden / Vaultwarden are read by the desktop apps — Windows 5.3.7 and Linux & macOS 3.3.1 or later; the web portal and the phone apps do not read them. Pick the source in the import window and choose the file; its format is told by its content.

• Opening the file: a .kdbx or .kdb database asks for its master password, its key file or both — leave the password empty when the key file alone opens it; a password-protected Bitwarden export asks for the password it was exported with. A wrong password keeps the window open for another try. The file is read on your computer and sent nowhere.
• What becomes what: groups, vaults and folders become folders. Every entry with a login, a password or a one-time code becomes a credential, the one-time code (TOTP) included; an entry whose address names a server also becomes a connection. Notes and the address go into the comment. SSH keys from 1Password and Bitwarden become SSH-key credentials.
• Which protocol: an address with a protocol — ssh://, rdp://, https://… — always decides. For a bare host the entry itself is read first: a port in the address (22, 23, 3389, 5900–5909), the words RDP, SSH, VNC or Telnet in its title or notes, a DOMAIN\user login. Only the rest follows Treat hosts without a protocol as: SSH connection, RDP connection or Credential only.
• What is skipped: cards, identities, secure notes, documents, archived and deleted items and the KeePass recycle bin. They are counted in the summary, so nothing vanishes silently.
• Into a cloud database: a large import runs straight through, and a progress window counts the connections and credentials as they arrive.

Export & backups

Portable backups (.bcmbackup)

• Export with a master password — the file is encrypted (AES-256-GCM); this is the format to move a catalog between machines or keep as a backup.
• Export without a password — for quick transfers only; the app warns you clearly that saved passwords would be stored in plain text.
• CSV export — the catalog structure without passwords, for spreadsheets and audits. It imports back too: pick BURSUcm CSV as the import source.
• The same export/import is available on the web portal, so a backup made in the app opens on the portal and vice versa.

Database snapshots

• Export Database… — a single encrypted file with the whole catalog (connections, credentials, users). You choose a snapshot master password — the file is useless without it.
• Import Database… replaces the current database contents (the app warns you). Local mode can also import a raw SQLite file.
• For a cloud database the portal offers .sql export/import (the database’s Settings tab) — a full PostgreSQL dump, database users included.

Resetting the setup

“Clear cache & restart setup” (Settings → Database) forgets the configured database and any saved sign-in and re-runs the first-run wizard. The data inside the database itself is not deleted.

Recipes: six common jobs

Short, complete walkthroughs of tasks that come up in real infrastructures. Each one only uses features described earlier — the links lead to the details.

1 · Reach a firewalled database as if it were local

A PostgreSQL server listens on db.internal:5432, reachable only from an SSH-accessible host. You want localhost:5432 on your machine to lead there.

1. Edit the SSH connection to that host → SSH options → Port forwards → add a Local (-L) forward: local port 5432, destination db.internal, destination port 5432.
2. Connect. The terminal prints the tunnel status as the session opens.
3. Point pgAdmin, DBeaver or psql at localhost:5432. The tunnel lives exactly as long as the session tab — closing the tab closes the door. Details: Port forwarding.

Several services behind the same host? Add one Dynamic (-D) forward instead and point the client at the SOCKS5 proxy — see Port forwarding.

2 · Give a contractor access to one folder only

An external engineer needs to work on the servers in Servers\Staging — and see nothing else, least of all passwords.

1. Open User Management → add a user (in cloud mode, a database user — the contractor needs no portal account, just the name@handle login you hand over).
2. Give the User role, leave the “All folders” rule empty, and on Servers\Staging grant Read — and Edit only if they should change entries.
3. Leave Passwords unticked: the contractor can connect with the stored credentials, but cannot reveal them in cleartext.
4. When the engagement ends, delete the user; in cloud mode also check their Sessions on the portal. Details: Users & permissions.

3 · Move in from PuTTY and WinSCP over lunch

1. Settings → Data → Import → source WinSCP: sites arrive with their folder tree and saved passwords, decrypted automatically.
2. Run the import again with PuTTY as the source — saved sessions, ports and SSH details come across; the preview step lets you untick what you do not want.
3. Both imports are additive and land in the target folder you choose, so nothing gets overwritten. Set a master password afterwards — imported passwords deserve real encryption. Details: Importing from other tools.

4 · One catalog on the work PC, the laptop and the phone

1. Create a free account and a database on bursucm.com (how).
2. On the machine that has your catalog: export it with Settings → Data → Export… → BURSUcm Backup (.bcmbackup)…, sign in to the new cloud database with its master password, and import the file with Settings → Data → Import… → BURSUcm backup.
3. Sign in to the same database from the laptop and the Android or iOS app. Everything follows: folders, manual order, credentials, snippets, tunnels — and each password is decrypted only on the device, never on the server.

5 · Run one command on a whole rack

1. Open sessions to every server involved (tabs and split panes both count).
2. Switch on Broadcast in the session toolbar — the orange banner confirms how many sessions are listening.
3. Type the command once — or send a snippet; with placeholders like systemctl restart {service} the app asks for the value first. Check the banner before Enter, then switch Broadcast off.

6 · A laptop is lost or stolen

1. On the portal open Profile → Connected devices and Revoke the lost device (or “Sign out all”) — its API token dies immediately and the app on it is signed out. For a database user's device, the owner does the same from the database's Users & access tab → Sessions.
2. Change your bursucm.com account password.
3. If two-factor sign-in is not on yet, turn it on — that also signs out every other device. If it is on and the recovery codes were kept on the laptop, press New recovery codes: the old ones stop working.
4. Assess the vault: saved passwords on the laptop are AES-encrypted under your master password — without it they are unreadable. If the master password could be known too, rotate the actual server passwords as a precaution.

Reference

The editions at a glance

Security model in one table

Where the app keeps its files

Inside: settings.json (app preferences), the local database when you use local mode, and known_hosts.json (trusted SSH host keys and certificates) in your own folder under Users — see Your settings on this computer. Back up the whole folder and you have backed up a local installation. Saved passwords inside these files are always encrypted — see the vault chapter.

File formats

Default ports

Pre-filled when you pick the protocol; change them freely per connection. SSH/SFTP 22 · Telnet 23 · RDP 3389 · VNC 5900 · Apple Remote Desktop 5900 (+ UDP 5900/5901 for High Performance) · FTP/FTPS 21 · HTTP 80 · HTTPS 443 · WinRM 5985 (HTTP) / 5986 (HTTPS). The BURSUlink agent needs nothing inbound: it connects out on 443/tcp and 7842/udp.

Glossary

FAQ & troubleshooting

Frequently asked

Is it free?
Yes, the app is free on every platform. BURSUcloud is an optional add-on.

Which platforms are supported?
Windows, macOS (Intel and Apple silicon), Linux (Debian/Ubuntu, Arch/CachyOS, Fedora/RHEL) and Android (Google Play or a direct APK) are available today. The iOS and iPadOS app is on the App Store and needs iOS or iPadOS 17 or newer.

Do I need an account?
No. Local mode is fully offline. An account is only needed for cloud sync and the Android and iOS/iPadOS apps.

I forgot the master password. Now what?
It cannot be recovered — that is the point of zero-knowledge. Your connections and catalog structure are intact; saved passwords must be re-entered (Settings → Security → set a new master password, then update the passwords).

I moved the database to another PC and passwords will not open.
The database was protected with DPAPI (tied to a Windows account). On the original computer enable a master password (Settings → Security), copy the database again — now it is portable, including to Linux and macOS.

What is the difference between a “database user” and a “member”?
A database user is an account for the BURSUcm apps only (login name@handle); no portal account needed. A member is a full bursucm.com account granted access to the database. Per-folder rights are identical.

Where does my cloud data live?
In a dedicated PostgreSQL database on the bursucm.com server, unreachable from the internet directly. Passwords in it are ciphertext; only you hold the key.

Why don’t my devices show the same order of connections?
Manual order syncs through the database. Make sure every device runs a current version (Windows 2.7.5+, Linux/macOS 1.7.5+, Android 1.8.1+, iOS/iPadOS 1.1.0+) and has refreshed the catalog; older versions simply fall back to alphabetical order without harming what you arranged.

Troubleshooting

Diagnostic logs

Settings → Logs: only operation timings are recorded — never passwords. Off by default. “Open” leads to the log folder.

Report a problem

Help → Report a problem, or the offer that appears by itself after an error or at the next start after a crash (Windows 3.3.0 and Linux & macOS 2.3.0 and later). The report carries the error itself, the app and system version and — while the box stays ticked — the tail of the diagnostic logs. The “What will be sent” section (on Linux and macOS, the “Show what will be sent” button) is the report, not a summary of it: passwords, keys and tokens are removed on your computer before you ever see it, and server addresses, account names and IP addresses are replaced with placeholders unless you tick the box that includes them. Nothing leaves the computer until you press Send. You get a report number back, and reports are deleted after 90 days.

A screenshot is offered only for an error that happened while the app was open: it is taken at the instant of the fault, is off by default, and is shown to you before it is sent. If sending fails nothing is lost — “Save to file...” writes the whole report, ready to be mailed to support@bursucm.com. To stop the app offering at all, turn off Settings → Other → Offer to report problems; it never sent anything on its own, so only the question goes away.

Still stuck?

Write to us through bursucm.com/contact — we usually reply within one business day. The status page shows whether a cloud issue is on our side.