I am trying to de-Google/de-Microsoft right now and I was excited to see Proton debut Sheets, marketed as "New" (but not "Beta"). I don't do anything crazy with my Google Sheets, it's mainly just straightforward mathematical formulas and at worst, vlookups.

But wow, I spent this weekend trying to migrate 3 sheets, running into endless bugs. I've reported 9 different issues this weekend alone.

I get it, it's new. I've also worked my entire career at tech startups, so I know that moving quickly risks bugs, especially for a new product launch. But, this really should have been marketed as beta. "Usable" would be a stretch.

Now, I'm pretty committed to de-Googling, so I spent my time working around every bug I found to get my most frequently used Sheets working. And I'll continue to do so, reporting issues as I go. I just really hope the update that's coming this week delivers a lot of fixes for formulas and functionality that really should be working for a non-beta "stable" product (like paste special and dragging formulas not adjusting reference cells correctly).

I’m actually wondering whether this is going to work out.

Ever since Proton Sheets was released, it’s been unusable. They keep saying “an update is coming soon”, “you’ll soon be able to use country-specific formats”, blah blah blah…

I’m slowly losing my patience. I’d like to finally plan and get on with the whole switch. But it’s not working out that way. I’ll have to start thinking about alternatives soon.

Start publishing a timetable at last.

About to renew and this answer will make it or break renewal for me

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

I really want to take advantage of the Summer Sale. But I can't use Proton Drive till iOS Files integration is back.

Like a lot of people here I back up my Proton Drive from a headless Linux server (restic, nightly) to whatever, Synology, pCloud, you name it.

The usual route is rclone's protondrive backend, and like others here I watched it get slower and slower until a flat folder with 785 photos took 160 seconds to list on a good day and never finished on a bad one. Six-hour hangs, dead mount points. The throttling is pattern-based: rclone walks the whole tree with thousands of metadata calls every night, and Proton's API understandably stops picking up. The part that surprised me: the official Drive SDK (github.com/ProtonDriveApps/sdk, MIT) is already good enough to fix this yourself. I built a small read-only gateway with it:

- metadata lives in a local SQLite cache, kept fresh through the SDK's event stream (the same mechanism the official apps use, polled once a minute)

- the tree is exposed as WebDAV on localhost, so restic reads it through a boring rclone webdav mount

- file contents are never stored, just streamed on demand, decrypted and integrity-verified by the SDK

Results on the same account that was being throttled: that 785-file folder lists in 0.106 seconds. First full snapshot (3,069 files, 42 GiB) took 22 minutes.

The nightly incremental run now takes 0.82 seconds and makes zero calls to Proton unless something actually changed. Restore came back bit-for-bit identical. It follows the SDK rules: identifies as external-drive-*, event-based, no recursive scans, personal use only (which the license explicitly allows). It can't write anything, so the worst it can do to your Drive is read it well 😊

Two things I ran into that might interest the Proton devs if they're reading: the incubating account package isn't on npm yet (vendoring works fine), and getSeekableStream() deadlocks under parallel load (32 of 70 concurrent ranged reads hung, reproducible; the regular download path is rock solid). Happy to file a proper issue with details.

Full write-up with all source code (free to reuse for personal setups): Medium (free) article

Not affiliated with Proton, just a subscriber who wanted his 3 a.m. backups back, and if the native Linux client lands before you build this, even better. That's the outcome I'm actually rooting for.

I havent personally seen many complaints about this, but when i try to sync files between my computers or when i upload files (videos) from my phone to use on my computer, it takes a RIDICULOUSLY long time to upload. Today i tried uploading a 300mb video and it even refused to upload it, giving errors each time. I just gave up and used google drive to upload my video because its simply not working on protondrive. I pay around 5 euro each month for this service (200GB).
The upload speed sometimes takes up to 15 minutes to sync some PDF files between my laptop and PC. WHY DOES IT TAKE SO LONG? This stuff just works on google drive, and instantly too. Why cant my paid Protondrive plan do it as good or even better? Im wondering if anyone else has these issues, because they make me really dissatisfied with this product...

Hi there,

is Proton Docs using a new file type with the .protondoc extension just because of the encryption? Couldn't it just handle common file types like odt or doc/docx? I tried it but I do not want all of my existing files being replaced by a new file.

Disclaimer: I am not a developer and ChatGPT has guided me through setting up my VM and attempting to set up the Drive CLI. Apologies if there are obvious things that I'm not catching.

I’m trying to use the official Proton Drive CLI on a headless Ubuntu Server VM for automated backups. The CLI itself installs and runs, but authentication fails when it tries to store the session in the Linux secret store. The server has no desktop environment.

Environment:

Ubuntu Server ARM64 VM
Headless / SSH-only
Proton Drive CLI installed
libsecret-1-0 and libsecret-tools installed
gnome-keyring and dbus-user-session installed

When running:

proton-drive auth login

I can open the browser login URL on another device and complete the login, but the CLI then fails with:

error: Object does not exist at path “/org/freedesktop/secrets/collection/login” (code: 19)
code: "ERR_SECRETS_PLATFORM_ERROR"

Testing secret-tool directly gives the same underlying issue:

secret-tool store --label="test secret" test proton-drive-test

returns:

secret-tool: Object does not exist at path “/org/freedesktop/secrets/collection/login”

I also tried running GNOME Keyring as a user systemd service, but it either hangs during startup or fails to create/use the expected login collection.

My questions:

1. Is the Proton Drive CLI currently supported for fully headless Linux servers?
2. Is there a recommended setup for the required Linux secret store on Ubuntu Server without a desktop environment?
3. Is there a supported way to authenticate the CLI for scheduled/cron backups without GNOME Keyring or KWallet?
4. If the CLI requires a desktop-style secret service, is server/headless backup automation not currently a supported use case?

My goal is simple scheduled backup automation: create Radicale backup archives on the server and upload them to Proton Drive.

Hey everyone.

Wanted some advice. Should I stick with Proton Sheets / Docs or go fully back to LibreOffice?

Once in a blue moon, I share secure / private information to family via Sheets (flight info, etc.) so Proton is nice in that sense. Or it's great if I want to take secure notes for calls about insurance / taxes, etc.

But Proton Docs / Sheets remains buggy, despite having used it for a year and trying to wing it out, I still encounter small bugs that can be frustrating at first (however, I understand). I love how Sheets & Docs has a nice UI and just the features I need, so it's easier to use in my opinion! : )

BUT, I do love how LibreOffice works offline, has more features, and I can just back it up to Proton Drive. Most my family are elderly / don't know how to use tech, so Proton Sheets / Docs is easy to share with them.

I hate to switch back to LibreOffice because I love the simplicity and interface of Sheets / Docs, and I want to support Proton in any way that I can, so using LibreOffice makes me feel like I'm cheating a bit lol!