SFTP is reliable, widely available, and easy to reason about. It is also not always the fastest way to move a directory with thousands of small files.
The issue is not just bandwidth. It is overhead.
Every file in a recursive transfer needs metadata reads, directory creation, file opens, writes, closes, and progress updates. For one large file, that overhead is tiny. For a project tree with many small files, it can dominate the transfer.
Voltius adds tar acceleration for those cases.
For the product-level SFTP workflow, start with SFTP Workflows Beyond Local File Transfers.
The normal path
For simple transfers, Voltius streams files directly through SFTP.
That is still the right path for single files. It keeps behavior predictable, supports progress updates, and avoids doing extra work when there is nothing to batch.
For directories and multiple selected items, however, the app can take a different path when SFTP Tar Acceleration is enabled.
The tar path
When tar acceleration is enabled, Voltius turns a directory or batch selection into a single gzip-compressed tar stream and unpacks it on the other side as it arrives. Nothing is written to a temporary archive on either end.
The remote ends run tar in an SSH exec channel, reading from or writing to the channel directly. The local end doesn't need a tar binary at all: Voltius packs and unpacks in-process.
For a local-to-remote directory upload, Voltius packs the folder in-process and streams it into tar -xzf - on the host. For a remote-to-local download, tar -czf - on the host streams the folder out and Voltius unpacks it locally.
For host-to-host transfers, the stream runs from tar on the source host, through Voltius's memory, into tar on the destination. Nothing lands on your laptop, and nothing is staged on either host.
Earlier versions built a temporary .tar.gz on one side, moved it and then extracted it. That needed free space for the whole archive in /tmp, so a large folder failed on a host with a small /tmp. Since 0.48.0, a tar transfer never needs more space than a file-by-file copy.
Why this is faster
The main win is reducing the number of SFTP operations.
Instead of opening, writing, and closing thousands of individual files over the protocol, Voltius can move one compressed archive. That can be much faster on high-latency connections, remote-to-remote transfers, and folders with many small files.
Compression can also reduce the bytes transferred for text-heavy directories, logs, source trees, and configuration bundles.
When Voltius uses it
The feature is controlled by the SFTP Tar Acceleration setting and is enabled by default.
Voltius uses the tar path for directory transfers and multi-item batch transfers when it is available. Single-file transfers continue to use the direct SFTP path.
Before taking the tar path, Voltius checks each remote host the transfer touches with a round trip that has to come back byte for byte: a binary-clean tar -xzf - -O. A host without tar, or whose channel mangles binary data, gets a plain recursive SFTP copy instead, and the transfer queue shows a File by file badge with the reason. The files still arrive; only the speed differs.
The answer is cached per connection, so it does not add a round trip to every transfer. A check that got no answer at all (a refused channel, a timeout, a reconnect) is not cached as a "no": the host is asked again, so one bad moment doesn't leave the rest of the connection copying file by file.
The implementation supports:
- Local to remote directory uploads.
- Remote to local directory downloads.
- Remote to remote directory transfers.
- Multi-item batch uploads and downloads.
- Multi-item host-to-host transfers.
Container-backed file operations use the same idea: stream tar data into or out of the container so directory transfers do not degrade into one operation per file.
Folder transfers also survive a dropped connection: they wait for the session to come back and continue. See SFTP Transfers That Survive a Dropped Link.
The tradeoffs
Tar acceleration depends on tar being available on the remote hosts. Voltius detects this for you: if a host involved in the transfer does not have tar, that transfer falls back to recursive SFTP instead of failing, and says so. You do not have to know in advance which hosts have tar.
It is still a setting. When you want predictable per-file behavior, you can turn it off and always use recursive SFTP.
Why it fits Voltius
Voltius is trying to make infrastructure work feel less fragmented.
Fast SFTP is part of that. If moving a directory between hosts takes long enough that you reach for another tool, the SSH client has failed the workflow.
Tar acceleration is a small implementation detail, but it changes how SFTP feels in practice: fewer round trips, better batch behavior, and less waiting when the file tree gets large.