Proton Drive CLI makes encrypted file workflows scriptable across three operating systems

Proton Drive CLI is a command-line tool for interacting with Proton Drive without writing an integration or opening a desktop app. It runs on macOS, Windows, and Linux, and its useful promise is straightforward: file operations and sharing can become script steps instead of manual browser work. Proton’s official guide documents authentication, listing, uploads, downloads, folder invitations, interactive shell use, and JSON output.

That makes Proton Drive CLI interesting for production-minded builders, but not because a terminal command magically makes a backup reliable. The useful engineering question is what the CLI can do today, how to compose those operations safely, and which guarantees your own wrapper still needs to provide.

What Proton Drive CLI does today

The short answer: it lets you authenticate, inspect a Drive, upload and download files, invite collaborators, and process command output from a script. Proton describes the tool as being built on its Drive SDK and available for users, developers, and businesses.

The documented command shape is deliberately readable:

./proton-drive auth login
./proton-drive filesystem list /my-files
./proton-drive filesystem upload ~/Documents/* /my-files/Documents
./proton-drive filesystem download /my-files/Documents ./
./proton-drive sharing invite --user proton@proton.me /my-files/Documents

These are not abstract API examples. They are the operations Proton publishes in its official Proton Drive CLI guide. The guide also says that --help exposes the full command list and that --help can be applied to a specific command to show its flags.

The practical boundary is important: the CLI gives you a programmable interface to Drive. It does not decide your retention policy, prove that a backup is complete, or define how your deployment pipeline should respond to a partial failure. Those are application decisions.

How do you authenticate without turning a script into a credential dump?

Start with the interactive login flow. Proton’s documented command is:

./proton-drive auth login

The CLI opens a browser for authentication. That is a better starting point than putting an account password into a shell history entry, CI variable, or copied script. Keep the first login interactive, inspect where the tool stores its session on the target machine, and treat that session as a secret with the same care as any other authenticated client state.

For a scheduled job, separate authentication setup from the job itself. The backup script should receive a known working session, not a password argument. Run a harmless listing before the first upload and fail if authentication is missing:

#!/usr/bin/env bash
set -euo pipefail

DRIVE="/my-files/nightly"
SOURCE="./export"

./proton-drive filesystem list "$DRIVE" >/dev/null
./proton-drive filesystem upload "$SOURCE"/* "$DRIVE"

This example is intentionally small. It does not pretend to solve every backup problem. It establishes two useful properties: the job stops on a failed command, and it checks access before it begins transferring files.

Do not treat a zero exit code as a complete backup until you have designed that check yourself. Record the source manifest, the destination path, the command output, and the job timestamp in your own system. The CLI is the transport surface; your application owns the evidence.

What can you automate with Proton Drive CLI?

Three workflows are an immediate fit.

File exports. A product can export reports, invoices, or customer-requested archives to a controlled Drive folder. The application creates the files; a worker invokes the CLI; an operator can inspect the destination later.

Scheduled backups. A scheduled process can upload a directory after a database dump or media export. The useful sequence is not “copy everything and hope.” It is “create an immutable local artifact, upload it, record the result, and alert on failure.”

Scripted collaboration. The documented sharing command can invite a user to a folder:

./proton-drive sharing invite --user proton@proton.me /my-files/Documents

Before using a sharing command in a customer-facing workflow, add an allowlist and an approval boundary. A typo in an email address is not a CLI bug; it is an authorization bug in the wrapper around the CLI.

For machine-readable processing, Proton documents the --json parameter. That gives a script a better input than parsing human-oriented table output:

./proton-drive filesystem list /my-files --json > drive-list.json

Pin the expected fields in your own adapter and keep a sample response in tests. Command output is an interface. If your code depends on it, test it like one.

How should a production wrapper handle retries?

The CLI can perform the file operation, but it cannot know whether your process should retry after a network interruption. Make the wrapper conservative.

Use a unique run directory, a stable destination name, and a manifest. If an upload fails halfway through, the next run should not silently claim success because the folder exists. If the operation is not safely repeatable, upload to a temporary path and promote it only after verification. If promotion is unavailable, use a completion marker that your reader understands.

A simple manifest might contain:

{
  "run_id": "2026-08-31T12:00:00Z",
  "source": "billing-export",
  "files": 42,
  "destination": "/my-files/nightly/2026-08-31",
  "status": "uploaded"
}

The values here are an example of a record shape, not a Proton guarantee. Your worker should compute the count and timestamp, then persist the record only after its own verification step. If a customer can download the result, expose the run status rather than making them infer it from a folder listing.

This is the same boundary that matters in background jobs for AI features: a request starts work, a worker performs it, and the system records a result that survives a dropped connection. Proton Drive CLI can be one worker dependency. It is not the job state machine.

Where does Proton Drive CLI fit in a cross-platform workflow?

The value of one CLI across macOS, Windows, and Linux is operational consistency. The command vocabulary can remain recognizable while the host changes. That helps when a team develops locally on one operating system and schedules a worker on another.

Still, “cross-platform” does not remove host differences. File globs, path separators, permissions, shell behavior, and process scheduling remain your responsibility. Keep platform-specific code at the edge:

• Resolve the source directory in the host language instead of concatenating paths by hand.
• Pass explicit paths to the CLI and log the resolved destination.
• Run the same smoke test on each operating system you support.
• Use JSON output for adapters and human output for operator debugging.
• Test a missing session, an empty source directory, a rejected invitation, and an interrupted transfer.

If you are building a web and mobile product, do not put storage credentials or arbitrary shell execution in the client. Put the CLI behind a controlled server-side worker with a narrow input contract. The client requests an export; the worker chooses the destination and records the outcome.

What Proton Drive CLI does not replace

It does not replace a backup policy, an access review, a restore drill, or an audit trail. It also does not turn a shell command into a safe public endpoint.

Those distinctions are useful because the tool is genuinely practical. Proton has exposed enough file and sharing operations to make terminal workflows worth testing. The mistake would be to stop at the happy-path command and call the workflow finished.

For builders who want the rest of the product surface ready before they wire in an external storage workflow, OTF’s full-stack app templates provide owned application code with sign-in, payments, a database, AI-tool configuration, and deployment scripts. That is a separate layer from Proton Drive CLI, but it is the layer where export permissions, job status, and recovery behavior belong.

Proton Drive CLI is best understood as a scriptable Drive client with documented commands, not as a complete backup platform. Use the official commands today, wrap them in explicit authorization and verification, and keep the durable workflow state in your own application.

Sources

• Using Proton Drive CLI — Proton

Originally published at otf-kit.dev — full-stack app templates for web and mobile. See the templates →