# termscp: a terminal file transfer client for SCP, SFTP, S3 and SMB

> termscp is a Rust TUI that puts a local pane and a remote pane side by side in the terminal, with SFTP, SCP, FTP, S3, GCS, Kube, SMB and WebDAV backends. It is a good fit when you live in a shell and want a WinSCP-style two-pane client without leaving it.

**veeso/termscp** — 🖥  A feature rich terminal UI file transfer and explorer with support for SCP/SFTP/FTP/S3/SMB/WebDAV

- Repository: https://github.com/veeso/termscp
- Website: https://termscp.rs
- Stars: 3,108 · Forks: 83
- Language: Rust
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/veeso-termscp

## What termscp solves that plain scp does not

The command line already moves files. What it does not give you is a view. termscp's README describes it as a terminal utility with a TUI to connect to a remote server to retrieve and upload files and to interact with the local file system. The two-pane layout is the whole point: you see the local tree and the remote tree at once, and moving a file is a selection rather than a path you have to type correctly.

The audience is narrow and specific. If you administer servers over SSH, pull build artifacts out of an S3 bucket, or push files to an SMB share from a Linux box, and you would rather not keep a GUI file manager open next to your terminal, termscp is aimed at you. The repository topics include winscp-for-linux and winscp-for-mac, which states the intended comparison directly.

The protocol list is broader than the tagline suggests. The README lists SFTP, SCP, FTP and FTPS, Kube, S3, Google Cloud Storage, SMB and WebDAV. That mix matters: S3 and GCS are not file transfer protocols in the SSH sense, and Kube is not a filesystem at all, so termscp is really an explorer with several unrelated backends behind one interface.

## How the TUI, the transfer engine and the backends fit together

The architecture is visible in Cargo.toml. termscp depends on ratatui and tui-realm for the interface, and on a family of crates from the same author for the actual transport: remotefs, remotefs-aws-s3, remotefs-gcs, remotefs-kube and remotefs-smb. The naming pattern tells you the design: a common filesystem abstraction, with one crate per backend implementing it. The README's Powered by list confirms the same split, naming remotefs and pavao among the dependencies.

That abstraction is why the explorer behaves the same whether you are on SFTP or S3. Create, remove, rename, search, view and edit are operations the README lists for both the remote and the local side. The remote side is whichever backend you connected with; the local side is the same interface pointed at your disk.

Two features are worth noting because they are not obvious from a screenshot. The README mentions desktop notifications when a large file has been transferred, and a synchronization mode that keeps file changes synchronized with the remote host. The notification path uses notify-rust, which is why the Linux build requirements include libdbus-1. The sync feature is the more interesting one and the README does not explain its conflict resolution, so treat it as something to configure carefully rather than trust by default.

Credentials handling is deliberate. The README states that SFTP and SCP authentication works with SSH keys and with username and password, and that passwords can be saved in the operating system key vault. The keyring dependency is a default Cargo feature, so a build with default features will try to use the platform keyring.

## Installing termscp and making a first SFTP connection

The README gives a one-line installer for Linux, FreeBSD and macOS. It fetches install.sh from termscp.rs and pipes it to sh.

```bash
curl --proto '=https' --tlsv1.2 -sSLf https://termscp.rs/install.sh | sh
```

On macOS the README notes that this requires Homebrew, otherwise the Rust compiler gets installed. Windows users get a PowerShell equivalent, and there are package manager routes as well.

```ps
irm https://termscp.rs/install.ps1 | iex
```

For Windows there is also Chocolatey. NetBSD and Arch Linux both ship termscp in their official repositories, installed with pkgin and pacman respectively.

```bash
pkgin install termscp
pacman -S termscp
```

Once installed, the README says to update by running termscp from the CLI with `(sudo) termscp update`. That is the self_update crate doing the work, and it is worth knowing that the update path is a subcommand of the same binary rather than a package manager transaction.

For a first real use, start the binary with no arguments. The README's gallery shows an authentication screen as the entry point, followed by bookmarks, a setup screen and a text editor. You pick a protocol, enter host, port and credentials, and land in the two-pane explorer. The README says connections can be saved through built-in bookmarks and recent connections, so the second connection to the same host is a selection rather than a form fill. If you use SSH keys rather than a password, the README lists that as a supported SFTP and SCP authentication method, and the user manual at docs.termscp.rs covers the configuration details.

## Build requirements, the SMB flag and the keyring question

The official Linux binaries and .deb packages are, per the README, statically linked against musl and have no runtime requirements, running on any distribution and any glibc version. That is a real advantage for the install path and it means most users never touch the build requirements at all.

Building from source is a different story. The README lists libdbus-1, pkg-config and libsmbclient for Linux, and dbus, pkgconf and libsmbclient for FreeBSD and NetBSD. The libsmbclient entry is the one that catches people out, because it comes from the smb Cargo feature, which is on by default. Cargo.toml shows the feature list: default is keyring and smb, and smb pulls in the remotefs-smb dependency. There is also an smb-vendored feature that maps to remotefs-smb/vendored, which is the escape hatch when you would rather not fight a system libsmbclient.

If you build with --no-default-features you drop both the keyring and the SMB backend. That removes the libsmbclient requirement, but it also removes SMB support and password storage, so it is a choice about what you are willing to give up rather than a free simplification.

The keyring side has its own caveat. On Linux, the README points at a user manual section on the keyring and lists a keyring manager as an optional requirement. Optional here means the feature degrades rather than fails: without a keyring manager you lose stored passwords, not the ability to connect. The Cargo.toml also shows keyring-core as a dependency alongside the older keyring-rs entry in the README's Powered by list, which suggests the credential storage layer has been reworked across versions.

## Where termscp is the wrong tool

The most important limitation is that termscp is interactive. Every feature described in the README is reached through the TUI: bookmarks, the explorer, the editor, the setup screen. There is no documented batch mode, no scriptable transfer command, and no exit code contract for automation. If you need a transfer to run from cron, from a CI job, or from a Makefile, termscp is not the tool; scp, rsync, aws s3 cp or sftp in batch mode are.

The second limitation is the protocol surface. The list is wide but it is not everything. There is no documented support for rsync, for NFS, or for the object stores outside S3 and GCS. If your storage is not on the list, the abstraction does not help you.

The third is the terminal itself. A TUI needs an interactive terminal with a reasonable size, and the README's screenshots show a layout that assumes horizontal room for two panes. Running it inside a constrained multiplexer pane or over a slow link is going to be uncomfortable in a way that a single scp command is not.

Finally, the synchronization feature is the one I would approach with the most caution. The README says it keeps file changes synchronized with the remote host, and says nothing about what happens when both sides change the same file. That silence is not proof of a problem, but it is a gap you should test with disposable data before pointing it at anything you care about.

## How termscp differs from WinSCP and from rclone

The README's own framing is WinSCP, and the repository topics include winscp-equivalent-for-linux and winscp-for-linux. The difference is the platform and the rendering. WinSCP is a Windows GUI application; termscp is a terminal application that runs on Linux, macOS, FreeBSD, NetBSD and Windows. If your work happens over SSH on a headless server, termscp is reachable where WinSCP is not, and it does not need an X server or a forwarded display.

A more interesting comparison is rclone, because the overlap is partial and the philosophies differ. rclone is a command-line sync and copy tool with a very large backend list and a strong scripting story; it is built to be driven by arguments and run unattended. termscp is built to be driven by keystrokes and watched. Both can talk to S3. If your task is a nightly mirror, rclone's model fits; if your task is browsing a bucket and pulling three files out of it, termscp's model fits. The README lists neither rclone nor any other tool as a comparison, so this is a distinction drawn from what each tool documents about itself, not a benchmark.

Against plain sftp and scp, the difference is not capability but feedback. Those tools transfer what you name and tell you when they are done. termscp shows you the directory you are choosing from. That is a real gain for exploratory work and a real cost for anything you want to repeat identically.

## Maintenance, licence and what upgrading costs you

termscp is MIT licensed, stated in the README and in the Cargo.toml license field, with the full text in the LICENSE file at the repository root. MIT is permissive: it allows use, modification and redistribution with the copyright notice and permission notice retained. That is the extent of what the repository states; it is not legal advice and the LICENSE file is the authority.

The maintenance picture from the repository data is straightforward. The repository is not archived. The last push was on 2026-09-16, and v1.2.0 was released on 2026-09-03, with v1.1.1 and v1.1.0 both on 2026-06-08. The project ships a CHANGELOG.md, a Justfile, a rust-toolchain.toml and a dist/ directory, which together indicate a release pipeline rather than ad hoc tagging.

Upgrade cost has one sharp edge: rust-version = "1.98.0" in Cargo.toml. If you build from source on a distribution with an older Rust toolchain, that is the number you have to meet, and it is high enough that distro-packaged rustc may not qualify. Users on the prebuilt binaries and the .deb packages never see this, because those are statically linked against musl. The `termscp update` subcommand is the intended upgrade path for those installs, and it means upgrades bypass your package manager, which is convenient but also means your package manager's record of what is installed will drift.

## Conclusion

Adopt termscp if you already work in a terminal and move files over SFTP, SCP, S3 or SMB often enough that retyping scp and aws s3 cp commands has become friction. Skip it if you need unattended scripted transfers, a GUI, or a client for a protocol outside the list in Cargo.toml, since it is an interactive TUI rather than a batch tool. Before committing, verify two things on your own machine: that your target protocol is compiled in (the default features are keyring and smb, and SMB pulls in libsmbclient on Linux), and that your OS keyring is available if you want stored passwords, because the manual documents a separate Linux keyring setup.

## FAQ

### Is termscp the same as SCP or SFTP?

No. termscp is a client application that speaks SCP and SFTP among other protocols; it is not a protocol itself. The README lists SFTP, SCP, FTP and FTPS, Kube, S3, GCS, SMB and WebDAV as the communication protocols it supports.

### Which protocols does termscp support?

The README lists SFTP, SCP, FTP and FTPS, Kube, S3, Google Cloud Storage, SMB and WebDAV. Cargo.toml shows the SMB backend as a default Cargo feature that can be disabled at build time with --no-default-features.

### How do I install termscp on Linux or macOS?

The README gives a one-line installer that fetches install.sh from termscp.rs and pipes it to sh. It notes that the macOS route requires Homebrew, otherwise the Rust compiler gets installed.

### How do I update termscp after installing it?

The README says to run termscp from the CLI with `(sudo) termscp update`. This is a subcommand of the installed binary, so the update does not go through your package manager.

### Does termscp need libsmbclient to build?

Yes, when the smb feature is enabled, which it is by default. The README lists libsmbclient among the build requirements for Linux, FreeBSD and NetBSD, and Cargo.toml provides an smb-vendored feature as an alternative to a system library.

## Sources

- [License: MIT](https://github.com/veeso/termscp/blob/main/LICENSE)
- [Project website](https://termscp.rs)
- [README](https://github.com/veeso/termscp/blob/main/README.md)
- [Releases](https://github.com/veeso/termscp/releases)
- [veeso/termscp on GitHub](https://github.com/veeso/termscp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/veeso-termscp