When Proton began in 2014, our only service was Proton Mail. Proton VPN(yeni pencere), our second service, came out in 2017, and we recently released Proton Calendar and Proton Drive(yeni pencere).
As we grew and released new services, we realized we needed to unify the Proton brand and our public websites. That’s where the new Proton website’s story starts.
Proton’s beginning
Our journey begins with Proton Mail.
When Proton Mail was our only service, it probably appeared to the untrained eye as though we only had a single public website, which we used to promote our service and share our company vision. But in reality, that single website was actually made up of three separate websites:
- Our main web pages were static pages.
- The Proton Mail blog, which used WordPress.
- The Proton Mail Support blog, which also used WordPress.
In 2017, when Proton VPN came out, we decided to create a dedicated Proton VPN website using the same model. That meant we were managing six websites between Proton Mail and Proton VPN.
Besides their number, there were other aspects of these websites that made managing them on a day-to-day basis somewhat complex:
- Many portions of the Proton Mail and Proton VPN websites were handcrafted piece-by-piece over time, making it difficult to update some of those pages.
- We used different technology stacks on our static pages and WordPress sites, which made updating common elements across all sites, such as headers or footers, quite complex.
- Only developers could update the content on our static pages. This made it difficult to quickly update our website, especially when the engineering teams were busy.
- Our products are for everyone, which is why we have localized versions of the Proton Mail website in 26 languages. But this introduces many challenges from a technical perspective.
This is how our websites worked when we were focused on just Proton Mail and Proton VPN. But even as we were launching Proton VPN, we knew that we would eventually introduce more services in the future.
Issues that come with growth
Proton has experienced explosive growth ever since it began, and our early websites were successful engines of growth for us. However, we knew that as we continued to grow, we would need to change our approach. We could see several issues rapidly approaching that would require a wholesale shift in how we approached our website development and maintenance.
More services
Most obviously, we were beginning work on Proton Calendar and Proton Drive. These services would have their own users that would need their own service-specific information, blog posts, and support articles. According to our original model, we should build dedicated websites for both.
Considering all the daily complexities we encountered managing six websites, we did not want to deal with 12. It was obvious we would need a new model, which is what first led to us considering a single website.
Technology stacks
The different sections of our Proton Mail and Proton VPN websites used different technology stacks. The static pages mainly use a JavaScript stack, and our blogs and Support blogs used WordPress sites and were based on PHP and MySQL. To further complicate things, our web applications use React(yeni pencere) — yet another stack to maintain.
Supporting so many different stacks required a wide range of engineering skills and meant some engineers were more or less dedicated to specific projects. This often created bottlenecks when a specific engineer was not available.
As we looked ahead, we wanted to reduce the number of technology stacks we used for our websites. If everyone works on the same stack, we will all have the same requisite knowledge and be able to help on any project.
It was also a challenge to maintain a high level of quality while supporting so many stacks. Keeping the Proton community and their data safe is our number one priority, which is why we put such emphasis on our services’ quality and security.
Supporting and managing such a wide variety of programming languages and tools made this more difficult. For example, anytime an engineer changed the header or footer of the Proton Mail website, that change needed to be applied three times on each separate website (static site, blog, and support blog). If this engineer wanted to make this change on their own, they had to be able to work in JavaScript, PHP, and MySQL. We wanted to limit this as much as possible going forward.
Content updates
Last but not least, one of our biggest challenges was making timely updates to our websites’ content. If we were going to design a new website, we wanted anyone to be able to add text or make simple edits, not just engineers. As we launch more and more services, the number of web pages and the amount of content we have to manage grows exponentially, and it was already hard to rely only on busy developers to apply fast content changes.
This was just the beginning. We also need to manage localized content. Previously, all texts were contributed by developers in English in the code base. This English text was used to create a translation string. Then our localization team translated it with help from our great localization community.
This system had a serious flaw. Anytime we had to change the existing text on a webpage, even if it was as simple as adding a comma, developers needed to update the text in the code base. This update modified the translation string, which meant the localization team needed to translate the string as though it were entirely new.
Improving content management as a whole was another challenge we wanted to address with our new website.
How and why we built the Proton website the way we did
Once we identified all the challenges our current system presented, we wanted to find a solution that would fix all of them. It required a technical solution but also improved practices from technical and organizational standpoints. Here is what we have done so far and what we are still working on.
Gatsby
One of our first decisions was to choose a technical framework to manage our static website that would simplify our technology stack.
It was not difficult. Our web applications use the React framework, and most engineers on our team already know it and are comfortable using it, leading us to look for a solution also based on React. This is the main reason we chose Gatsby(yeni pencere) to manage our static web pages. It is also a widely used framework with a big community, which provides insurance that it will not disappear anytime soon.
We chose Gatsby early on, so we were able to check that it would work for us by giving it a test run. First, we used Gatsby to build some pages for the Proton VPN static website. As the site was static already, we could simply build new pages with Gatsby and push them out among the existing ones. There were obviously some technical challenges to solve when we merged Gatsby to the static site, but they’re basically invisible from an end-user perspective.
We also wanted to systematize how we build pages as much as possible to improve our agility when editing web pages’ content. Many of our old static web pages were built piece-by-piece over time while others were copied and pasted, meaning there was no uniformity from page to page. This made maintenance labor-intensive. We figured switching to a new technical framework would be a good time to leave this piecemeal approach behind.
We decided to adopt a component strategy from the very beginning with Gatsby. Our Product and Design teams worked hard to define and create a set of components we can reuse to build new pages in the future. This way, we can apply any change to a component everywhere instead of having to apply the same change multiple times in different places as we did on our old websites.
These first experiments confirmed that Gatsby would be an effective solution to build and maintain our new static website.
However, these static pages were just a part of our public websites. We also had to find a solution to manage our blog and Support blog.
WordPress
Whether we should continue with WordPress(yeni pencere) was a tricky question for us. To simplify our technical stack, it would have been logical to drop it and find another way to manage our blogs and Support blogs. On the other hand, the Proton team knows WordPress, as do most web content editors in general.
We also had many existing articles to import to the new website from the Proton Mail and Proton VPN blogs and their corresponding Support blogs. For example, if we only look at the Proton Mail website, we made more than 700 posts in July 2021! Migrating all that content would have been quite challenging.
When we thought about it a bit more, what caused us the most difficulties was managing front pages separately for each site. In our original setup, we actually managed four different WordPress websites: a blog and a Support blog for both Proton Mail and Proton VPN. Additionally, each of these instances of WordPress had its own set of plugins and dedicated themes.
In the end, we decided to keep WordPress and simplify how we manage front pages.
WordPress Multisite
Once we decided to keep WordPress, the next logical choice was to select a multisite version. If you’ve never heard of a WordPress Multisite, it’s basically a standard WordPress instance configured to let you manage multiple subsites on a single WordPress site. This interested us because a multisite instance lets you share users, plugins, themes, and configuration settings across all the subsites. This feature alone made managing our WordPress sites much easier. For example, with a multisite instance, we only need to click a single button to update WordPress or a plugin for all its subsites. Previously, we needed to update each site individually.
This obviously saves us a lot of time compared to our previous setup, but we thought we could go even further. Our dream was to use WordPress as a headless CMS.
WordPress as headless
We already knew in early 2020 that we would need to find a better solution for our websites, and we built some blog pages with Gatsby using WordPress REST API as a test. Unfortunately, the technical options at that time were not optimal. The building process, in particular, was too slow for our needs.
We decided to try again in early 2021. We investigated and found out that there had been several promising updates. The Gatsby team had done a lot of work to allow Gatsby to source content from WordPress. Crucially, plugins(yeni pencere) were developed for Gatsby and WordPress, allowing them to work together. These plugins optimize the build with cache management and provide a way to preview articles from WordPress.
So we created a proof of concept with articles from the Proton Mail blog to check how a headless WordPress CMS would work. To our delight, it worked quite well. To summarize our setup, we basically expose a GraphQL API of WordPress content that we can use Gatsby to query to get the content and build the page as we like. In the end, we managed to get all our blog posts and support articles in WordPress to generate static pages using Gatsby.
At this point, we only need to use one tool to build front-end pages, and we can implement changes once and have them applied on multiple sites instead of going through and implementing them on each site individually. That’s progress!
We were already happy with how much we’d been able to simplify our development process — but we thought there was still more we could do.
Prismic
We continued looking for ways to make managing the content on our websites even easier. Ideally, we wanted to remove engineers from the content update process entirely.
Under our old system, engineers had to implement every content update on our static pages. Other internal teams, such as Growth, Content, and Design, would send their edits to an engineer who would update the codebase. This system helped maintain code quality but made it difficult to update existing content or publish new content quickly.
We began looking at ways to allow the Content team to manage the text on our static sites themselves without risking the quality of our code. We evaluated several solutions, but ultimately, we decided to go with Prismic(yeni pencere). Prismic is a headless CMS that allows you to create components that editors can use to build complete pages. We saved even more effort by using the components we first defined and built using Gatsby. Once these components were configured, we could quickly build any web pages we needed and hand over the maintenance of the content to the content editors.
The last thing to take care of was getting this content in Gatsby. Fortunately, Prismic exposes a GraphQL API the same way WordPress does, making this simple. All we had to do was map the queried content onto our existing components.
Where we stand
Currently, the Proton website uses the setup described above to serve Proton Calendar, Proton Drive, and Proton Mail. We migrated our Proton Mail websites to proton.me and built new web pages for Proton Calendar and Proton Drive. Our Proton VPN website still needs to be migrated.
The new Proton website’s setup is a big step forward compared to where we started, even without the Proton VPN migration. By bringing Proton Mail, Proton Calendar, and Proton Drive onto a single site, we’ve built a unified ecosystem where the interactions between our services serve to better protect our community’s privacy.
From a technical perspective, we still have more work ahead of us. For instance, at the moment, we have a single build process for the whole website, and we deploy it daily within a fixed window to handle updates or publish blog articles.
This works fine, but we could be more efficient if we had more granular builds and deployments. There are some technical challenges we’ll need to overcome to achieve this as we’re managing everything internally. This is one of the many issues we plan to investigate in the coming weeks and months.
We hope you enjoyed this explanation of how we built the Proton website. It will help us protect our community’s data and privacy and sets us up to handle further growth in the future.
