Proton Drive CLI 2026: encrypted backups from the terminal, and what it still can't do

The essentials

Proton Drive has an official command-line tool. Proton announced it on 9 June 2026: one binary for Windows, macOS and Linux, called proton-drive, built on the same Proton Drive SDK that powers its desktop and mobile apps. It lists, uploads, downloads, manages folders and trash, and shares files with other Proton users, and it prints JSON on request so you can pipe it into other tools.

What it is not: a sync client. Proton states plainly that only its applications include a background synchronisation engine and that the CLI is "not a full replacement". It runs one operation, tells you whether it worked, and exits. That makes it a good fit for scheduled encrypted backups and build scripts, and a poor fit for keeping a folder mirrored in real time.

This guide covers what it does, the commands to start with, how sign-in and session storage work, and the limits worth knowing before you build a backup routine on it. Everything here comes from Proton's announcement and its support page; where Proton says nothing (free-plan access, headless servers), we say so instead of guessing.

What the CLI does at launch

According to Proton, the first release covers:

• Files and folders: list, upload, download, create and manage folders, and the trash.
• Sharing: invite another Proton user to a file or folder.
• Machine-readable output: plain text by default, --json (or -j) for scripts.
• Interactive mode: running proton-drive with no arguments opens a shell where you type commands one after another.
• Short commands: any command name can be shortened as long as the short form stays unique.

It is written in TypeScript, packaged with Bun, and Proton links its source to the public Drive SDK repository on GitHub. Proton's post does not state a licence for the CLI itself.

The commands to start with

These are the examples from Proton's support page, run from the folder where you downloaded the binary:

# Sign in (opens your browser)
./proton-drive auth login

# List your files
./proton-drive filesystem list /my-files

# Upload a local folder's contents
./proton-drive filesystem upload ~/Documents/* /my-files/Documents

# Download a folder to the current directory
./proton-drive filesystem download /my-files/Documents ./

# Share a folder with another Proton user
./proton-drive sharing invite --user proton@proton.me /my-files/Documents

# Full option list for a command
./proton-drive filesystem upload --help

Two details matter for scripts. Remote paths start at /my-files, which is your Drive root. And since the tool exits after each operation, a backup job is simply an upload command placed in a scheduler.

Sign-in and where your session lives

proton-drive auth login opens a browser sign-in. Proton says no password is typed on the command line, which keeps it out of your shell history and process list. Once signed in, the session is stored in the operating system's credential store: Windows Credential Manager, the macOS Keychain, or libsecret on Linux.

That design is sensible on a laptop or desktop. It raises a real question on a headless server: browser sign-in and libsecret both assume a desktop session, and Proton's documentation does not address servers without one. If your backups run on a VPS or a NAS, test the sign-in there first, and keep a fallback ready.

Scheduling encrypted backups with cron

Proton names cron explicitly as a use case. A nightly upload of a documents folder on Linux or macOS looks like this in crontab -e:

0 2 * * * /home/you/bin/proton-drive filesystem upload /home/you/Documents/* /my-files/Backups/Documents

Because files are encrypted on your machine before they leave it, the backup lands in Drive with the same end-to-end encryption as anything you upload through the apps. Two practical cautions:

• Fair use applies. Proton asks users to transfer only files that changed and warns that accounts generating unusually high traffic are temporarily throttled. Re-uploading an entire folder every hour is exactly what that rule targets.
• An upload is not a versioned backup on its own. Decide how you want to keep older copies (dated folders, for example) before you rely on the job. The same reasoning is behind why sync is not a backup.

What it can't do yet

Proton lists these as coming later, not available at launch:

• Photos and albums
• Public link sharing (sharing works only by inviting a Proton user)
• Multiple accounts

And by design, no background sync. If you want a folder kept identical on two machines, the desktop app is the tool, not the CLI.

Proton Drive CLI or rclone?

Before June 2026, the usual way to script Proton Drive was rclone, through a community-maintained backend. The two now answer different needs:

• The official CLI is maintained by Proton on its own SDK, which is a strong argument for long-term compatibility, and it signs in through your browser instead of storing credentials in a config file.
• rclone does far more: it talks to 70+ providers, has a real sync command, mounts remotes as a drive, and can add its own client-side encryption layer with rclone crypt on clouds that have none.

If Proton Drive is your only cloud and you want simple scheduled uploads, start with the official CLI. If you already run rclone across several providers, or you need true one-way sync, there is no reason to switch yet.

Who it's for

The CLI makes the most sense if you already pay for Proton Drive (see the current plans and prices) and want encrypted, scriptable backups without a third-party tool in the chain. Proton's announcement does not say whether the CLI is available on the free plan, so check from your own account before planning around it.

Our verdict: a welcome and well-designed first version, honest about its scope. Treat it as an upload and download tool you can schedule, not as a sync engine, and it does that job cleanly.