The new Proton Drive CLI v0.8.0 is out. We focused mostly on UX based on the feedback we got.

• General help is now expanded to tell you about fs and other shortcuts,
• CLI gives you hints what commands you probably meant if you use ambiguous shortcut (for example, you can type just fs and it will list all commands for given category, easier discovery),
• version command also tells you if the CLI is up-to-date,
• help for upload and download commands explains in detail what various conflict strategies do,
• and finally, we reworked conflict strategies to be more explicit and tailored for each operation instead of using general terms that was leading to major confusion (with that, we had to remove setting conflict strategy for both files and folders, now it must be specified separately),
• and also some bug fixing as usual.

For example, fs up -h:

Options:
    -f, --file-conflict-strategy STRATEGY
                             Conflict strategy applied to files. Values:
                             * create-new-revision: Create a new revision of the
                             existing file.
                             * rename: Add a unique suffix to the name.
                             * replace: Trash the remote file or folder and
                             upload the local copy.
                             * skip: Skip the conflicting file or folder.
    -d, --folder-conflict-strategy STRATEGY
                             Conflict strategy applied to folders. Values:
                             * merge: Merge folder contents.
                             * rename: Add a unique suffix to the name.
                             * replace: Trash the remote file or folder and
                             upload the local copy.
                             * skip: Skip the conflicting file or folder.

https://proton.me/download/drive/cli/index.html

Heya! The new Proton Drive CLI v0.7.0 is out. The main feature is several commands for albums and photos management. Now you can upload to and download from Photos timeline, manage albums, or add and remove photos to/from albums. The list of new commands:

album list
album create
album update
album delete
album photos
album add-photo
album remove-photo
photo timeline
photo upload
photo download

Besides this change, upload command now by default automatically skips conflicting nodes with the same content. You can change your command from fs upload --folder-conflict-strategy merge --file-conflict-strategy skip (which would skip existing nodes, even if the file changed) to, for example, fs upload --conflict-strategy merge which will upload only when file changed and keep previous revisions (depending on your plan).

Heya! The new Proton Drive CLI v0.6.0 is out. The main feature is PROTON_DRIVE_CREDENTIALS_STORE env variable which you can set to "pass" on Linux instead of the default OS keychain that requires GUI setup in the headless context.

Hey r/ProtonDrive,

Michal, manager of the Drive web team here.

In May this year, we shared that photos and albums load faster on web (original post). Some of you saw a real difference. Others didn't, and you were right to call that out.

We took this feedback on. The first release was a step forward, but some key pieces were missing. We've been focused on fixing this. Here's what changed, why, and what's next.

SDK migration (the foundation)

The web client is now fully powered by our SDK. Photos was one of the last major sections to migrate. You won't see a visible difference from this alone, but it unblocked everything else.

Think of it as replumbing the house before renovating the kitchen: crypto and API logic are now separated from the photo UI. That separation matters because it lets us ship photo improvements faster, without fighting tightly coupled code.

This migration also cleared accumulated technical debt. We removed unnecessary API calls and batched others more efficiently. Before the migration, that wasn't really possible. UI and data logic were intertwined, and performance was capped by how React re-rendered the view. This was the main improvement in our first announcement, and for many users it made a noticeable difference.

Smarter loading (not just faster loading)

Making requests faster wasn't enough on its own. The app also needed to load the right things first.

Previously, we fetched thumbnails for everything near the viewport including a few rows above and below, but requests ran in parallel with no clear priority. The app could finish thumbnails quickly while you were still staring at spinners on the photos you were actually looking at.

Now, we load truly visible items first, then preload what's just off-screen for smooth scrolling. We also cancel queued thumbnail requests when you scroll away. Previously, if you jumped around quickly, previous work still sat in the queue and competed for bandwidth. Several jumps meant a growing backlog and slower loads. Requests that haven't started yet are now cleared when you move on.

Persistent thumbnail cache

We can optimize network and scheduling all we want, but the best load is no load at all.

We recently added an encrypted thumbnail cache in IndexedDB. It's overdue, and we're glad it's here. It stores roughly 500 recently viewed thumbnails. Enough to make return visits to the same albums feel instant if you've been browsing there recently.

To be upfront: a cold cache (first visit, new album, or cleared browser data) still has room to improve. That's a focus area for us. If things felt snappy only after you'd already been clicking around, the cache is likely why.

Firefox: a browser regression

Proton pushes browser crypto harder than most web apps, and that stress test exposed a bug in Firefox's crypto library. The photo improvements above were working, but on Firefox they were effectively masked by that underlying issue.

We mitigated by reducing parallel work in the meantime. The latest Firefox already addressed the root cause. More detail here: Why Drive web performance regressed on Firefox.

What's coming

HTTP/2 for thumbnail fetching

Every thumbnail is encrypted, so we fetch and decrypt each one ourselves rather than serving plain files from a CDN. Our storage API has historically been on HTTP/1.1, which creates a hard ceiling: browsers open only ~6 connections per domain, so loading many thumbnails in parallel hits a wall quickly.

HTTP/2 removes that bottleneck. We're working through one remaining blocker before we can switch. We hope to begin testing by end of Q3. We know "historical reasons" isn't satisfying, this is a real infrastructure constraint, not something we overlooked because photos didn't matter to us.

Better full-screen preloading

When you preview photos full-screen, we don't yet preload the next image as aggressively as we should. That means more spinners between photos than we'd like. This is already in progress; preview-modal preloading should land in the coming weeks.

More to come

Photos has always been one of the hardest Drive features to make fast. Encryption adds real cost that most cloud photo apps never pay. We're investing more in it now that the solid foundation is there.

Thanks for sticking with us, and for the honest feedback. It genuinely helped us prioritize and focus on the things that matter.

If you're still seeing slow photos after a hard refresh, let us know your browser, approximate library size, and whether it's first load or return visit. That helps us track down what's left.

The Drive Web team

Some of you may have noticed that Proton Drive feels sluggish on Firefox lately, we wanted to give you full transparency on what's going on and where things stand.

What's happening
After reports from users and internal testing, we traced the slowness to a performance regression introduced in Firefox 150. This isn't a Proton Drive bug, it's a browser-level change that affects how our app (and likely others) behaves. Chrome and Safari are unaffected.

How we found it
We bisected across Firefox versions to pinpoint exactly when it started, then went deeper into nightly builds to narrow it down to a specific Mozilla commit. We even compiled Firefox locally to test reverts and confirm the culprit. Once we had a solid case, we filed a Bugzilla report (Bug 2046401).

Working with Mozilla
This is where we want to give a genuine shoutout to the Mozilla team as they were incredibly responsive and collaborative throughout this process. We gave them a dedicated account to reproduce the issue, they dug in, confirmed multiple root causes, and got to work fast. One fix has already landed, with more on the way. These should all ship in future version of Firefox. If everything goes right, this should be uplifted in future Firefox 152 patches.

What we're doing in the meantime
We've shipped client-side mitigations to reduce the impact while waiting for the Firefox fix. The main one is thumbnail caching, so while the very first load may still feel slow, subsequent visits to Photos will be near-instant. This is rolling out progressively right now.

We'll update this post once the Firefox fixes are live. Thanks for your patience.