We're expanding the mod team here on r/ProtonPass , and the same call is going out on r/ProtonMail, r/ProtonVPN, r/ProtonDrive and r/Lumo.

The job is mostly the same wherever you land: enforce the rules consistently, get support requests to the team who can actually fix them, keep the discussion useful even when people disagree, and flag anything that's spam, self-promotion or a privacy risk before it spreads. Mods can also cover our Discord and Telegram.

If you know one product inside out, say Pass or Mail, and less about the rest, that's a fit too. We want people with deep product-specific knowledge just as much as broad Proton generalists.

You won't be figuring any of this out alone. The current mod team will help you get up to speed before you're handling anything solo.

Active, positive contributors to these communities get priority. If that's you, check the link above or below...

https://www.reddit.com/r/ProtonPass/application/

Hey everyone,

We've added a new server location in China, aimed at people from China who are living or visiting overseas.

If you've moved abroad, you've likely hit the region locks that cut you off from the platforms you used back home.

This server is built for exactly that: connect back into China from wherever you are and access your local streaming services.

Currently working:

• Bilibili
• Tencent Video
• Youku
• Mango TV

To be clear

This is for connecting into China from abroad. It's an inbound use case for people overseas who want to reach Chinese content and services.

It is not built for the reverse, and although our Stealth Protocol and Alternative Routing features are highly effective at circumventing government censorship, we cannot guarantee that Proton VPN will always work reliably inside mainland China.

Your connection still runs under the same no-logs policy and Swiss privacy protections that apply across all of Proton VPN.

This is an early step and we'll be expanding platform support over time. If there's a service you'd like to see working, let us know.

Stay safe,
Proton Team

In the early hours of August 27, 2026, Proton experienced a widespread outage that impacted services for a number of users. The root cause was a total failure of the cooling system in our Frankfurt datacenter. While all systems at Proton are redundant and we have enough capacity to endure a complete data center failure, there are a small number of scenarios where the failover can take longer and lead to user-facing disruptions.

Here’s a timeline of what happened, what choices we made during the incident and why, and how it was resolved.

Timeline

Just after 11 p.m. (Central European time) on Wednesday, August 26, a cooling system failure occurred in the main room of our Frankfurt datacenter. At around 11:15 p.m., the temperature started rising from approximately 21.8°C (nominal temperature) to 51.9°C in less than half an hour, with some measurement probes reporting 60°C air temperature in the room. As the temperatures rose, server and networking equipment within the facility started to die one by one.

The user-facing incident began at around midnight on August 27, when the failures escalated to the point that critical redundancy was lost. This occurred when both the primary and backup network switch on a critical rack failed, and this rack unfortunately contained several primary database copies. While almost all Proton systems are redundant and will failover automatically/immediately, primary database failovers are not done automatically without human supervision.

We retain this control out of a desire to avoid so-called “split brain” situations, where a temporary unavailability of a primary database means that the replica copies miss some updates and become de-synced in ways that can be difficult to reconcile later. Furthermore, when a primary database failover occurs, the standard operating procedure is to failover to a replica in the same datacenter for latency and performance reasons. However, the specific nature of the problem meant that this might be ill-advised, since we potentially could be failing over to something that would also go down.

The decisions

At this point, Proton’s on-call engineers needed to make a couple consequential decisions while operating under extreme pressure.

• Do they prioritize bringing the service back online, or prioritize addressing the cooling problem and saving the hardware inside the datacenter?
• Should we failover to replicas within the same building Frankfurt (faster and less disruptive, but possibly a temporary fix if the heat could not be brought under control), or failover to Zurich?
• Do we failover everything or just what is down at the moment? We have contingencies for complete data center failure where things failover fully and mostly automatically rather quickly, but a situation where random servers are dying one by one is not handled well by our failover logic.

Ultimately the rate at which temperatures were rising forced us to prioritize saving the hardware versus bringing services back online. This is not a choice that typically needs to be made, because cooling systems are typically redundant, and the complete loss of cooling is quite rare, meaning that there is quite a bit of time before temperatures become critical. The problem is exacerbated by large increase in server power density in recent years with higher power CPUs and GPUs for AI. As a result, what used to take 3-4 hours to go critical went critical in 20 minutes.

The on-call team therefore focused their attention on communicating with the on-site datacenter operations team to restore cooling while powering off as many servers as possible to protect them. Due to a server equipment shortage tied to the ongoing AI boom, lots of this equipment — if lost — would not be possible to replace on short timelines. Saving it had to be a priority, even at the cost of potentially extending the downtime.

By 00:45 CEST, we were able to restore cooling and temperatures at the facility began to drop, and the on-call team switched focus to service recovery. At this point, we made the decision to failover the primary databases to Frankfurt if a replica was still alive, and to Zurich in cases where there was no replica alive in Frankfurt, to avoid changing our traffic flows too much and possibly creating new instability. This option was selected because we assumed that, now that we had the cooling under control, it would be relatively easy to bring Frankfurt back online and faster than switching over to Zurich.

Unfortunately, this turned out not to be the case. During the incident, many network cards in the Frankfurt infrastructure reached a temperature of 105C (normal operating temperature is 45C), which triggers a special temperature protection mode and causes the network cards to be disabled until there is a cold system reset. Our security posture limits the ability to access the out-of-band controller for our systems, which required us to wake up additional staff to assist with the recovery.

By 01:30 CEST, we were able to get most services back online for most users. However, some less critical systems, such as push notifications or payment processing, were not recovered until around 02:00 CEST.

As we reported during the initial incident report, no emails were lost, but email delivery in both directions was delayed during the incident.

While user-facing services were fully restored, that was not the end of the night for our engineers, in particular the database team. Our infrastructure was left in a highly abnormal state, with some primary databases in Zurich and others in Frankfurt, and several of them operating with reduced redundancy and/or reduced performance. Our team worked through the night to resolve the most pressing of these issues, and the work continued through the day on August 27 to restore full redundancy.

While we were able to save almost all of the infrastructure, some servers unfortunately suffered heat death, and we don’t know yet if the heating incident will impact the lifespan of the surviving equipment.

Root cause and next steps

A subsequent investigation on August 27 traced the root cause of the cooling failure to an air filter replacement on both of the redundant air compressors powering the cooling system. Unfortunately, the datacenter operator performed this operation in the middle of the night, without prior notice, and also failed to communicate the cooling failure when it happened, which dramatically cut down the time we had to respond. We are working closely with the operator to prevent a repeat of this incident.

However, it is also a known limitation of our current database infrastructure that an outage of this type could lead to a longer than normal recovery process. The series of events that led to this incident are highly improbable — yet they happened.

The database resilience work required to address this failure mode is already underway and remains planned for completion by the end of the year. Additional infrastructure capacity, including new datacenter space, is also currently being commissioned and is expected to become available within the next few weeks, which will further reduce our single site dependency.

Unfortunately, this incident occurred before those improvements were fully in place. We are now reviewing where we can safely accelerate the remaining work while maintaining the level of care required for changes to critical database infrastructure.

We recognize that our users expect a very high level of reliability from Proton, and this incident reinforces the importance of completing this work and continuing to raise our resilience standards. We apologize again, unreservedly, to every user who was impacted.

Thank you for your continued support,

Bart Butler

Proton Pass custom and extra items.

With our update from about a year ago, you can choose from 14 item types, including medical records, WiFi settings, and driver's licenses. Alternatively, create your fully-customizable item if you need something unique. Once created, you can share and pin these custom items or view their version history, just like with standard items.

With Proton Pass’s flexible item management, you can store all the information you need in one encrypted place.

Read more: https://proton.me/blog/password-manager-custom-item-management

Hi everyone,

We’ve added Categories to Proton Mail to reduce inbox noise and make important emails easier to find.

Incoming emails can now be automatically sorted into:

- Primary

- Social

- Promotions

- Newsletters

- Transactions

- Updates

Newsletters and Transactions are unique to Proton Mail, we added them to give you more granular control over your inbox.

Categories are on by default for new users. Existing users will be asked whether they want to turn Categories on, and you can choose which categories you want to see in settings.

What you can do:

- Move any email to a different category at any time (doing so will allow the model to learn from your preferred categorization)

- Control unread counts and notifications per category

- Turn off any category individually, or disable the feature entirely in settings

On mobile you can disable them in Settings → Mailbox Preferences → Categories → Disable

On web: All Settings → Messages and composing → Email Categories → Disable

You may also notice an updated inbox toolbar as part of this change.

From a privacy perspective, enabling Categories doesn’t change anything about how Proton Mail works.Your inbox remains protected by zero-access encryption, and emails you send to other Proton users (or using password protection) are end-to-end encrypted.

Learn more: https://proton.me/blog/proton-mail-categories

Try it out and let us know what you think in the comments below.

Proton Team

https://reddit.com/link/1vtlczf/video/unqo4y11ojkh1/player

Hey everyone,

Localization support is coming to Proton VPN on Linux in our next release (expected around mid-August).

The app will automatically detect your language based on your OS locale, so there is no need to head into the settings on your end.

Languages at launch:

• German
• French
• Spanish
• Spanish (Latin America)
• Italian
• Dutch
• Polish
• Portuguese (Brazil)
• Russian
• Korean
• Japanese
• Turkish
• Catalan
• Czech
• Romanian
• Chinese (Simplified)
• Chinese (Traditional)
• Belarusian
• Greek
• Slovenian

This is the initial lineup, and our localization team will keep adding more over time.

If you run into anything that looks off, whether it's a translation that doesn't fit, text that runs past its container, or a language that isn't detecting correctly, let us know by reporting a bug via the in-app report flow.

Stay safe,
Proton Team

A TED talk by Andy Yen, all the way back from 2015.

Sending an email message is like sending a postcard, says scientist Andy Yen in this thought-provoking talk: Anyone can read it. Yet encryption, the technology that protects the privacy of email communication, does exist. It's just that until now it has been difficult to install and a hassle to use. Showing a demo of an email program he designed with colleagues at CERN, Yen argues that encryption can be made simple to the point of becoming the default option, providing true email privacy to all.

https://preview.redd.it/csh44kr3xxjh1.png?width=2400&format=png&auto=webp&s=aec7f66097a00cbf213eea2d0c451e7d09539703

If you are using Gmail to send messages from your Microsoft Outlook or Yahoo email address, that feature is going away. Here’s what’s you need to know.

Google announced that it’s ending support for Gmail “Send as,” a setting that lets you send messages from a third-party address through Gmail’s own interface, citing “disproportionate maintenance resources.”

This is happening in stages: Google has begun restricting new Gmail “Send as” configurations for third-party addresses on the web, while existing configurations will continue to work during the transition. The feature will be fully removed in January 2027. At that point, according to Google’s own support page, “you will no longer be able to send mail from third-party email accounts in Gmail on the web or in the Gmail mobile apps.” You will still be able to read and check third-party emails inside the Gmail app.

The company is also ending Gmailify in January 2027, a feature that extends Gmail’s own spam protection and inbox organization to third-party accounts.

Read more: https://proton.me/blog/gmail-ends-send-as-third-party

Do your private SSH keys currently live on disk, encrypted with a passphrase you type once per session, or with no passphrase at all? In both cases, there's now an easier and more secure way.

Proton Pass now has an SSH agent, allowing you to store the key inside your vault instead.

→ In the SSH Agent section of Settings ⚙ icon → General, tick the Use Proton Pass as SSH agent box to generate a setup command that you can then paste into your terminal.

https://preview.redd.it/ajhk99yw55jh1.png?width=1436&format=png&auto=webp&s=410de4b8921b1937643367123d50d817f2434fdd

Unlock the vault once; no more re-entering a passphrase with every connection, or sessions that die on reboot.

Managing keys becomes a vault action instead of a manual file chore. Easier to keep track of, especially on multiple machines and systems. Gain peace of mind from one less secret exposed on disk.

Solve the one place key management actually breaks down: loose encrypted files scattered across machines, and replace it with one encrypted vault with biometric unlock and access controls.

For the bulk of your SSH work (git, GitHub, GitLab, SSH to servers), using a vault is both cleaner and tighter. Give yourself centralized visibility into which keys are active and where.

Gradually rolling out now to Visionary, B2B Bundles, Pass Professional, Plus, and Family. Desktop only.