Cyberduck: one libre client for FTP, S3, Azure and everything between

Every protocol people still use, in one window

Cyberduck is a libre file transfer client for macOS and Windows, and its protocol list is the resume, FTP, SFTP, WebDAV, Amazon S3, Backblaze B2, Microsoft Azure and OneDrive, and OpenStack Swift, spanning the legacy protocols, the object stores and the consumer cloud drives in a single application. The repository is the development home, with a command line interface extending to Linux alongside macOS and Windows, so the same core speaks GUI on the desktop and script on the server. The project lives under the iterate-ch organization, is licensed GPL-3.0 with pull requests welcome, and had its repository pushed 2026-09-29, the day before this writing, with no GitHub releases since distribution flows through its own channels rather than tags. The description also names Microsoft Azure and OneDrive explicitly rather than treating them as one thing, reflecting that enterprise tenants and personal drives connect differently even when the vendor is the same.

The same core powers Mountain Duck

The core libraries are used in Mountain Duck, the commercial companion that mounts cloud storage as volumes, which makes Cyberduck the open source half of a dual licensing arrangement where the engine is shared and the products differ. That relationship explains the repository's unusual cleanliness for a twenty year old codebase, the core is production currency for a paying product, not a static artifact. The ecosystem extends through sibling repositories, documentation maintained at docs.cyberduck.io from its own repo, and additional connection profiles beyond the bundled defaults maintained separately and installable through Preferences then Profiles, the mechanism that lets new providers and endpoints arrive without application releases. For users this split has a practical consequence, fixes and protocol work land in the shared core and reach both products, so the free client benefits from the same engineering attention the commercial one pays for.

Thirty one languages through Transifex

Localization is run as infrastructure, using Transifex to localize resources, with the current roster reading English, Czech, Dutch, Finnish, French, German, Italian, Japanese, Korean, Norwegian, Portuguese, Slovak, Spanish, Chinese in both Traditional and Simplified Han, Russian, Swedish, Hungarian, Danish, Polish, Indonesian, Catalan, Welsh, Thai, Turkish, Hebrew, Latvian, Greek, Serbian, Georgian and Slovenian. A dedicated localization mailing list carries notifications about changes to the translations needed, so translators learn when strings move rather than discovering stale work late, and a news mailing list announces releases. The breadth, including Welsh, Georgian and Catalan, is the kind that only accumulates over decades of continuous use, and it doubles as evidence of the user base's spread. A translation notification loop that reaches translators when strings change is the difference between a localized app and an app that was localized once, and maintaining it as a mailing list keeps the workflow open to contributors without Transifex accounts.

Chocolatey may fail spectacularly

The Windows build prerequisites section is the most honest toolchain documentation in the file. It starts conventionally, Visual Studio 2022 with three workloads, .NET desktop development, Universal Windows Platform development, and Desktop development with C++, plus the Bonjour SDK for Windows and optionally WiX v3. Then Chocolatey scripts cover both the build tools only and full IDE paths, installing the workloads first:

choco install visualstudio2022buildtools -y
choco install visualstudio2022-workload-manageddesktopbuildtools -y
choco install visualstudio2022-workload-vctools -y
choco install visualstudio2022-workload-universalbuildtools -y

and then the remaining dependencies after the IDE or build tools land:

choco install microsoft-openjdk17 ant maven -y
choco install bonjour -y; choco install bonjour -y --force

And then the remarks, quoted nearly verbatim because no paraphrase improves them, installing with Chocolatey may or may not fail spectacularly, with observed issues including Bonjour failing with file not found despite the MSI being extracted, WiX depending on a .NET 3.5 package that never completes and does not work on Windows 11, and workloads halting with Operation canceled, recoverable by aborting and resuming in the Visual Studio Installer. A restart closes the list, and the PATH section that follows adds MSBuild, the Windows SDK binaries, mvn, ant and java to the environment so the three build systems can find each other.

NuGet credentials and three build systems

Building on Windows also requires configuring NuGet with credentials for GitHub Package Registry sources, a classic personal access token with read:packages scope feeding two configured sources, gh-ikvmnet and gh-iterate-ch, run through dotnet nuget update source, because the IKVM Java runtime bridge and internal packages are distributed as GitHub packages. The build itself is Maven driven, SKIP_SIGN=true mvn verify -DskipTests produces osx/target/Cyberduck.app and windows/target/Cyberduck.exe without tests or code signing, and adding -Pinstaller produces distributable artifacts, zips and pkgs for macOS, exes and msis for Windows, and debs and rpms for the Linux CLI. The repository carries all three build worlds simultaneously, an xcodeproj for the Mac side, a Visual Studio solution with MSBuild targets for Windows, and Ant and Maven wiring it together, the price of one codebase shipping native feeling apps on two platforms. The two NuGet sources are not cosmetic, gh-ikvmnet feeds the IKVM bridge that lets the Java core call into .NET for the Windows shell integration, and gh-iterate-ch carries the organization's own packages, so without the PAT step the Windows build fails at dependency resolution before compiling anything.

A sandbox profile and a debugger on port 5005

The macOS build accepts -Psandbox to activate the sandboxing profile and apply the com.apple.security.app-sandbox entitlement, aligning development builds with the hardened runtime users actually run, and -Pdebug opens a remote debugger on port 5005 for attaching from IntelliJ or another JVM debugger. Windows debugging is more convoluted because, in the documentation's words, Visual Studio is not able to handle Java projects, so the flow runs mvn verify with a debug configuration that ensures debugging symbols are generated, preventing MSBuild invoked from Maven from producing optimized assemblies that would make stepping through meaningless. The section exists at all because this is a Java application wrapped in native shells on both platforms, and the seams show exactly where debugging crosses from one world into the other. The debug configuration detail matters more than it looks, optimized native assemblies would make half the variables invisible at exactly the moment a bug crosses the Java to native boundary, which in this application is where the interesting bugs live.

A directory per cloud, and agent files at the root

The repository layout maps the protocol matrix directly, top level directories for backblaze, box, dropbox, dracoon, ctera, azure, bonjour, and notably cryptomator, the client side encryption integration, alongside core, cli and binding directories holding the engine, the command line tool and the language bindings. The tree is truncated in any listing because the provider list continues well past it, which is the point, adding a provider means adding a module. The root also shows the current era, AGENTS.md, CLAUDE.md and an .aiignore file configuring coding agents for a Java and C codebase, a Gurubase badge for AI assisted answers, and the practical furniture of a long maintained project, SECURITY.md, SUPPORT.md, a changelog, and TIMEZONES, a data file hinting at the schedule handling the app needs. The cryptomator directory deserves a pause, it means the client can encrypt data before it leaves the machine for any of the supported clouds, turning a plain transfer tool into a privacy instrument for storage you do not fully trust.

Nightly snapshots, betas, and a duck in Docker

With no GitHub releases, distribution happens through the website and the update system, and Preferences then Update can switch an installation to beta or snapshot builds, the latter described as nightly builds from the current development trunk featuring the latest bug fixes and enhancements, with the warning they are potentially unstable and experimental attached. The CLI, named duck, gets its own delivery form, a Docker image on ubuntu:focal whose entrypoint is the duck binary running --version by default, symlinked into place, the simplest possible way to script transfers against any supported protocol from a container. Community channels round it out, the Google Groups discussion list, the news and localization lists, and a Fosstodon presence, the quiet infrastructure of a project that predates and outlasts most of its contemporaries. The snapshot channel doubles as the support path for bleeding edge fixes, users chasing a specific regression can ride the trunk briefly and drop back to stable once a fix ships, without ever building from source.

Editorial conclusion

Use Cyberduck when one graphical client must reach many protocols and providers, from elderly FTP servers to S3 and B2 buckets, on both macOS and Windows, with a CLI for scripting and Linux. Choose a single protocol tool when that is all you need, or FileZilla when a tri licensed GUI tradition matters more than the cloud breadth. Before building from source, budget real time for the Windows toolchain, the prerequisites page itself warns Chocolatey may fail spectacularly, and note the GitHub Package Registry credentials required for NuGet dependencies. For daily use, prefer the stable builds over snapshots unless chasing a specific fix, since snapshots are labeled potentially unstable and experimental by the project itself.

Frequently asked questions

Official sources

1. Issues
2. iterate-ch/cyberduck on GitHub
3. License: GPL-3.0
4. Project website
5. README