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

SSHWinRMSFTPFTPRDPVNCTelnet

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, and you can move it to the cloud later without losing anything.
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.

Updates

The app checks the release feed on startup (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. Installing a new version over the old one keeps all your data.

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-2.7.0-x64.dmg) or Apple Silicon (BURSUcm-2.7.0-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.

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.

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:

• 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 selected database…” — connections, credentials, users and snippets move over wholesale.
3. If several computers will use the database, enable a master password BEFORE migrating — otherwise DPAPI-encrypted passwords will not open on other machines.

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, 23…).
3. Enter the username and password manually — or pick a saved credential from the vault (see Credentials).
4. The “Group” field sets the folder; nest with \, e.g. Servers\Production. New folders are created automatically.
5. 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.

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).
• 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.

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.
• Folders move among folders, entries move among entries within their folder — the tree structure never changes, only the display order.
• The order is saved in the database, not on the device: in cloud mode the Windows app, the Linux/macOS app, the web portal and the Android app all show exactly the order you set. On the portal the same arrows sit on each row of the Connections and Credentials tabs.
• 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.

Terminal & sessions

Tabs

• Every session is a tab. Drag to reorder; right-click for Duplicate, Pin, Close.
• 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, timeout) an overlay appears inside the session with a Reconnect button — just press Enter. 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.

Working in the terminal

• Full ANSI colours: Midnight Commander, htop and other TUI apps render correctly.
• Right mouse button — configurable: “copy selection, paste on right-click” (default), “copy if selected, otherwise paste”, or a context menu.
• 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 with an auto-hiding toolbar and session tabs on top.
• 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 → SSH (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.

• Enable it on the connection (or as a default in Settings); the log folder is configurable in Settings → Data.
• 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.

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.

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 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 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 already-trusted hosts”, “Off” (insecure). The “Forget all trusted 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.
• 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.

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 an in-browser 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).
• Local resources: clipboard, local drives, printers, microphone; where remote audio plays.
• Other: domain, RD Gateway.

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 that is what BURSUcm connects with — a Mac offers it to any VNC client. Apple’s High Performance screen sharing is a different protocol and is not supported: Mac to Mac only, both Apple silicon and macOS Sonoma 14 or later, a virtual display carried over UDP 5900–5902 with HDR and 30 or 60 fps. A Mac that can do it still answers on the standard 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.

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.

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). The tab has its own Back / Forward / Reload buttons, so multi-page panels are comfortable to walk through.
• 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.

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 “Ignore 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 — 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 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.

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 Run read-only commands without asking (an administrator setting) setting. 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 the cause of the error builds a focused diagnosis in one click; Create 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.
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.

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.

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: Settings → Database → BURSUcloud (or pick BURSUcloud on first run).
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. Choose a database from the list (“Refresh databases” re-reads it) → “Use selected”.
4. 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 and RDP options (including jump hosts and tunnels). 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.

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 synchronizing, 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.

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: name, technical name, your role (owner or member of someone else’s database), status and creation date. 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.
• Revealing passwords: the “Master password” field on top with “Unlock & reveal”. Passwords are decrypted only for the current page view; the server never sees them. When editing a connection the password box is always empty — “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); folder inheritance is configured in the app.

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 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).

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.

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.

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 four interface languages (English, Russian, Ukrainian, Georgian) — in Settings.

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.

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, Google, Microsoft, Apple or GitHub — and you get the same folders, the same connections, in the same order you arranged on the desktop.

• SSH terminal with hardware-keyboard and Ctrl-combo support; catalog search expands the folders that contain matches.
• Built-in RDP and VNC: full remote-desktop sessions on the phone — a trackpad pointer or direct touch, and on rotation the desktop follows with a matching resolution without reconnecting.
• SFTP and FTP: file panels for browsing, uploading and downloading straight from a connection.
• Tablets: 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.
• Session limit: up to 5 simultaneous sessions by default (adjustable 1–20 in Settings); a session the remote side ends closes itself with a notice.
• Theme: follows the system light/dark setting by default; a fixed Light or Dark theme is available in Settings.
• Master password & biometrics: fingerprint unlock — the vault key is protected by an Android Keystore key that physically cannot be used without a successful scan. The “Lock App on Start” option asks for the fingerprint immediately at launch.
• Auto-lock: the credential vault locks after 5 minutes in the background.
• Screen protection: screenshots and screen recording are blocked on sensitive screens; content is hidden in the Recents switcher.
• Certificate pinning: the app accepts only the genuine bursucm.com certificate — a substituted connection (MITM) is rejected.
• Sessions: signing in again revokes the previous session on the server, so the “Connected devices” list on the portal always reflects reality.
• tmux: the same checkbox and session name as on the desktop, in the connection's SSH section — a session started on the phone is ready on the desktop and the other way round.
• WinRM: such connections are listed with their own colour, can be created and edited here for the desktop, and the card copies host, user and password; opening one is desktop-only for now.

iOS & iPadOS app

BURSUcm for iPhone and iPad is one universal app, free on the App Store. Sign in with the same account — email/password, Google, Microsoft, Apple or GitHub — and the same catalog opens: the same folders, the same connections, in the order you arranged them, with every password decrypted on the device only.

• SSH terminal with an extra key row (Ctrl, Esc, Tab, ^C, F1–F12) above the on-screen keyboard, so htop, mc and interactive TUIs are actually usable on a phone. Hardware keyboards pass modifiers straight through.
• SFTP and FTP file browsing: upload and download, create folders, rename, delete — with each file's permissions in the listing.
• Built-in RDP and VNC: the remote desktop rendered in the app. Touch gestures do the pointing (tap = click, two-finger tap = right click, two fingers = scroll, double-tap and drag = drag), and a floating control pad carries Esc, Tab, Del, the arrows, function keys and Ctrl+Alt+Del.
• Editing on the go: connections and credentials can be created and edited on the phone — including jump hosts and port forwards — and the manual order of folders and entries can be arranged with the same arrows as everywhere else.
• 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, and Stage Manager for several sessions side by side.
• Face ID / Touch ID: the vault key is held behind the system biometric store; the vault locks itself after 5 minutes in the background.
• TOTP codes saved in a credential are shown with a live countdown, ready to copy.
• 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 actually holds the certificate's private key.

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.

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 snapshot — a single encrypted file with the whole catalog (connections, credentials, users). You choose a snapshot master password — the file is useless without it.
• Import snapshot 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: enable a master password first, then Settings → Database → select BURSUcloud → “Migrate to selected database…”.
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 tab → Sessions.
2. Change your bursucm.com account password.
3. 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). 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 · FTP/FTPS 21 · HTTP 80 · HTTPS 443 · WinRM 5985 (HTTP) / 5986 (HTTPS).

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 1.7.5+, Android 1.8.1+) 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. “Show what will be sent” 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.