Inside Passbolt Support

Support is where users experience Passbolt most directly, especially when something needs fixing, investigating or explaining.

In this series, we’re meeting the people behind Passbolt Support and looking at how the team works from the inside. We’re starting with Antony, Lead Support Engineer for EMEA, to talk about how the team approaches difficult problems, what customers teach us, and where AI fits into the future of support.

Meet Antony

How did you end up in Passbolt’s Support Team?

I joined Passbolt as an apprentice a few years ago. Support is a bit like the trenches: it’s where you really learn the product, the edge cases, and everything that can go wrong.

A lot of people pass through Support on their way to something else. I just liked it too much to leave. I got hooked on helping people, digging one level deeper, and the side quests that come with it: coding, investigating, and coming up with new ideas. Now, as a lead, one of the things I’m most proud of is helping new team members become autonomous. Watching them grow, while they push me to grow too, is a great feeling.

How much of your background do you use day to day, and what has proved unexpectedly useful in Support?

I have a technical degree in computer science and a bachelor’s focused on software development and architecture. That helps me read code, understand stack traces, and work out what an error is actually telling me. It also means I can sometimes go beyond reporting a problem: propose a fix, build a quick proof of concept for a customer, or cover a use case that is not documented yet.

The more unexpected part is my eSports background. I competed for years and even tried pursuing it professionally. It taught me to stay calm and communicate clearly under pressure. When a customer is locked out of their password manager, saying the useful thing in one short sentence is often worth more than any certification.

What else does the team work on behind the scenes, except customer tickets?

Customer tickets are the most visible part of Support but we also contribute to documentation, review pull requests, test new distribution releases, work on Ansible-related tasks, and build proofs of concept or investigations for Product.

There’s also unplanned work: regressions, bugs, unclear documentation, or dependency updates that keep things running smoothly. Support sits across several teams, so there’s always something to contribute beyond the ticket queue.

What can Passbolt Support help with, and where does the customer’s responsibility begin?

Any issue related to the product is ours: a UI problem, a failed upgrade, an installation issue, or strange behaviour after a release.

The line is everything around the product. If a server goes down at two in the morning because it ran out of memory, or a certificate expires, that belongs to whoever manages the infrastructure.

That said, we won’t leave anyone stranded. Even if the issue sits outside Passbolt, we’ll still point you in the right direction and help you get unstuck rather than draw a hard line around where our responsibility ends.

What’s the most memorable support case you’ve had to untangle?

One customer had a network incident that made their Passbolt instance unreachable. The catch: the credentials needed to fix the network were inside Passbolt, and the users’ private keys were on an internal drive that was also down.

We restored a replica of the database locally, mounted it in Docker, used the organisation recovery key, worked through the PGP messages, and eventually got them back in. It was a few hours at defcon one. Cases like that reinforce your confidence in the team, and in your ability to stay calm and make the right calls under pressure.

What do you enjoy most about working in Support, and what tests your patience?

The best part is the human side. You’re not just fixing problems; you’re talking to real people, and over time you can build genuine relationships with some customers.

What tests my patience? Very little, honestly. But I do appreciate a bit of warmth in communication. Even a simple “hello” goes a long way!

When you have no idea what’s going on with a ticket, what happens behind the scenes?

Honestly, I like those cases because I know I’m going to learn something. Then it becomes an investigation: reading the product code, reproducing the issue internally, checking third-party components, and pulling in the Support or development team when needed.

Sometimes the root cause is outside Passbolt entirely. We’ve even contacted third-party providers ourselves to help get an issue resolved. Also, for the really difficult cases, team experience matters. Gareth has seen a lot, and his perspective can often connect the dots quickly!

What do you wish every customer knew before contacting Support, or before making a change that might lead to a ticket?

Honestly: RTM- Read the Manual, with a smile. The documentation often already has the answer. If it doesn’t, context helps most: your version, setup, logs, and what you’ve already tried. A ticket with that information is often half solved before we start.

Two more rules: avoid playing with your setup on a Friday, and test your backups by restoring one. The worst time to discover a backup doesn’t work is during an incident.

Now that AI can write convincing support answers, what’s your take on it? Should Gareth, Gerold and you be worried?

I’m not an AI enthusiast, but I’ve accepted that it can be a useful productivity tool. My concern is delegating too much of the thinking. Part of what I enjoy about Support is the investigation and the moment when the problem finally clicks. If AI does all of that for you, you lose both the learning and the satisfaction.

AI is great for simple questions and quick answers. I could see it helping people through our documentation, with a human available when needed. But product knowledge and judgement still matter. If the documentation is outdated or the product itself has a flaw, AI can confidently repeat the wrong answer. We know the product well enough to spot when something doesn’t add up and investigate further.

So, should we be worried? Not at all ;)

What does a normal day in Passbolt Support look like, and what happens when a ticket comes in?

“Normal” is doing a lot of work in that sentence, but there is a rhythm to it. Because I work EMEA hours, the day often starts with tickets that arrived overnight. We prioritise anything urgent, check whether it’s a known issue, and reproduce it where we can before replying rather than guessing.

From there, it’s usually investigation: logs, recreating a customer’s setup, follow-ups, or moving to a call if email starts going in circles. Customer files are handled carefully too: we use disposable containers or VMs rather than opening them directly on our machines.

Customers get a response from a real person, and we stay on the thread until it’s resolved. Our contractual response time is the next business day, though in practice it’s often much faster.

And then there are the days when none of that applies because a customer is down or a release introduces a regression. At that point, everything else moves.

What’s something customers have taught the Support team that we wouldn’t have discovered ourselves?

One surprise is how often people plug Passbolt into other tools, automations and integrations. For example, Ansible pulling a credential or certificate during deployment instead of an admin copying it manually.

That makes the API and reliability of those lookups just as important as the interface, and shows that Passbolt can be part of a company’s infrastructure, not just an app someone opens.

When does a Support ticket need Product, Engineering or Security, and how does customer feedback influence the roadmap?

When Support can’t resolve something alone, we bring in the right team. Code changes go to Product and Engineering, while security issues follow the security process.

When the same request keeps surfacing across customers, it becomes a product signal. Support adds the context to what’s blocked, how often it happens, and the impact, so Product and Engineering can weigh it against effort and priorities and decide if it reflects a real roadmap gap.

Even when a ticket moves internally, Support stays involved. Handing it over does not mean handing the customer over.

Beyond the Support Desk

What do you do when you’re not working?

I go to the gym a few times a week: it clears my head because you have to be completely present. I also spend a lot of time building a SaaS project from scratch, and spending time with my girlfriend, Lola, is what really helps me switch off from computers.

What’s a fun fact about you?

I was administering servers before I knew it could be a job. As a kid, I rented Counter-Strike Source servers, edited configs, installed plugins, and then fixed whatever I broke. Around eleven, I also built a fake Steam key generator in Visual Basic to prank my friends. It looked completely legitimate and did absolutely nothing.

Tell us a little about where you come from.

I’m French, but I grew up in an Italian family, so family has always been a big part of my life. We still get together at my nonna’s most weekends.

It taught me early on to look after the people around you and to show up when it matters- which, thinking about it, is not a bad description of Support either.

Conclusion: One team, three perspectives

Antony gives us the first look at the people behind Passbolt Support. Next, Gareth and Gerold will bring their own experiences and perspectives, and together, show what makes the team work.