The stack itself is not complicated.
The goal of the video is not to pretend that production is only a docker compose up away. Please don’t do that.
I call that hoping nothing goes wrong.
The value is in the architecture and in the habits it encourages. Separate applications. Separate databases. Separate users. A backup and restore plan. Monitoring. Something you can explain to another human being without needing a 90-slide presentation.
This is not advanced security. It is just least privilege and separation between applications. Boring? Maybe. Useful? Absolutely.
That’s operations.
Start small. Build it in a lab. Understand it. Break it. Restore it. Upgrade it. Then decide what production should look like.
Nextcloud is already well known for collaboration: files, sharing, calendars, contacts, and the kind of daily work users expect to do without thinking too much about the backend.
I have seen too many setups where tools were added one after another because there was a quick need at the time. A file tool here. A password tool there. Some shared drive nobody owns anymore. An old server still running because “don’t touch it, it works”. After a few years nobody has the full picture.
Good.
For files and credentials, I don’t like blind trust. “Don’t worry, it’s handled” is not an answer when nobody can explain where the data is, who can access it, how it is backed up, and how it would be restored.
And yes, when each application has its own database and credentials, the setup is easier to understand. Backups are clearer. Troubleshooting is clearer. Recovery is clearer.
Create one database for Nextcloud. Create one for Passbolt. Use separate users. Give each application only the privileges it needs.
The stack
So use it as a starting point.
One thing I like here is that this isn’t MariaDB pretending to do everything on its own.
It still means work. Someone has to install it, secure it, monitor it, update it, and test restores. But at least you are not limited to one provider’s features, timelines, export options, and mood.
Run it. Look at it. Break it. Restore it.
That is where the Privacy First Stack can play an important role. It is published on the MariaDB Server Ecosystem Hub, and no, I don’t like it just because it has a nice name. I like it because it addresses something I keep seeing in real environments: people need modern collaboration tools, but they also need to know where their data is, how it is stored, and how they can recover it.
Don’t start by building a spaceship.
Nextcloud for collaboration. Passbolt for passwords and secrets. MariaDB Server for the data.
So, small request: don’t put everything in one database with one user because it was faster during installation.
I don’t need one huge platform pretending to solve every problem with a dashboard, five pricing tiers, and an export button that may or may not export what I need. I prefer tools that do one job properly and are understandable by the people who have to operate them.
It is not “install these three components and now you are secure”.
It is an important part of the stack.
A real stack needs real partners
This stack is not only for large companies with compliance departments and big architecture meetings.
In the video, I go through the basic deployment flow, the containers involved, and the first checks after startup. It is a good way to understand the architecture before thinking about a more serious production setup with proper backups, monitoring, TLS, upgrades, and maybe replication or Galera later.
There are three main pieces.
The database contains a lot of important application state: users, shares, permissions, configuration, metadata, sessions, jobs, and all the pieces the application needs to behave correctly. Files may live elsewhere. Encryption and application logic matter too. Of course.
“Digital sovereignty” is one of those expressions that can quickly become annoying. It appears in slides, political speeches, and reports that nobody finishes reading.
Files are on some cloud platform. Nobody is completely sure which settings were changed two years ago. Passwords are in browsers, in chat messages, sometimes in a document with a name like credentials-final-v3. Backups? “The provider handles that.” Maybe. Where is the data exactly? “In Europe, normally.” Who has access? That’s when the room becomes quiet.
- Nextcloud for collaboration.
- Passbolt for credentials and secrets.
- MariaDB Server for the relational data.
Nextcloud gives you file sharing, collaboration, calendars, contacts, communication, all the things users expect these days.
Why this matters
In this stack, MariaDB Server stores the data for Nextcloud and Passbolt.
With Nextcloud, Passbolt and MariaDB Server, you have options. You can run the stack yourself, use a trusted provider, deploy it in your own datacenter, or put it in a private cloud.
For example:
CREATE DATABASE nextcloud;
CREATE DATABASE passbolt;
But technically, it comes down to simple questions: where is the data, who operates the service, who has access, how do you patch it, how do you back it up, how do you restore it, and how do you leave?
MariaDB Server is not just somewhere behind the application
So yes, MariaDB Server is not just “behind” the stack.
Boring things are often the things that save you when something breaks at 02:00.
Nextcloud handles collaboration. Passbolt handles credentials. MariaDB stores the data.
Passbolt gives you password and secret sharing in a way that is not a spreadsheet, not an email, not a wiki page, and not a message in a chat history from 2021.
And Passbolt is an important solution, as credentials are often handled poorly.
Yes, it may work. It will probably even work for a while.
Nextcloud. Passbolt. MariaDB Server.
Happy testing, and enjoy MariaDB!
That last part is underrated.
Not magic. Practical.
The idea is more practical: show how the pieces fit together, how Nextcloud and Passbolt use MariaDB Server, and how quickly you can build a lab environment to test the stack yourself.
Digital sovereignty, minus the big words
Small teams need this too. A small company still needs to share files properly. A school still needs to manage passwords. A lab still needs to know where its data is. A non-profit can also mess up credentials. Believe me.
I don’t trust systems nobody can explain.
Passbolt gives teams a better habit. Credentials are no longer treated like random text. They are shared through a tool built for that job, with access control, users, groups, and auditability in mind.
So the stack makes sense because each partner has a clear role:
Also, this stack reminds people that the database is not a boring backend detail.
SaaS is convenient. Of course it is.
Not only for huge organizations
That is where you really start to understand if a stack makes sense.
I don’t call that a privacy strategy.
A big part.
You create an account, invite users, upload files, and the job looks done. The problem is not using SaaS. The problem is forgetting what you delegated and what you still need to understand.
Install the stack. Test it. Break it in the lab. Restore it. Document what you did. Fix what was ugly. Then share feedback with the MariaDB community.
And I don’t really conceive hope as an operational model.
To make the stack easier to try, I also prepared a small deployment example using Docker.
What it solves
Clear is good. Especially when you are tired.
That’s it.
If you cannot answer most of those questions, you probably have less control than you think.
And I like that.
Nothing exotic.
That is where problems start.
For me, the MariaDB Privacy-First Stack solves a very concrete problem: it gives teams a clean way to run collaboration and password management while keeping control of the database and the data behind those tools.
I hear this sentence a lot: “We care about privacy.”
But later, when you need to understand permissions, check backups, move one application, restore only one part, or debug something strange, you will regret that shortcut.
It says: use known open-source tools, keep responsibilities separate, and stay in control of your data.
Probably the last one, actually.
Easy Deployment
And yes, MariaDB matters here. A lot of the application state, metadata, users, shares, permissions and configuration will live in the database. So please don’t treat the database like a small technical detail hidden somewhere behind the web interface. It is part of the design.
But when login breaks, sharing behaves strangely, an upgrade fails, or a restore is needed, suddenly everyone remembers the database exists.
MariaDB Server stores the relational data these applications need.
That separation is exactly what I want in a system I may have to operate, debug, back up, restore, and explain to someone else later. And they also work together.
That’s not paranoia.
But then you look a bit closer.
That matters.
Conclusion
No. Please no. Security does not work like that.
Maybe you need replication. Maybe you need MariaDB Galera Cluster. Maybe you need better monitoring, automated backups, and a proper runbook before you even think about high availability.
In smaller organizations, people often improvise because there is no dedicated team or process. That is how passwords end up in spreadsheets, emails, old folders, or in the head of someone who left six months ago.
That matters because privacy is not only about where files are stored. It is also about how people access systems, how secrets are shared, and how quickly access can be removed when someone changes roles or leaves.
I like the MariaDB Privacy-First Stack because it is practical.
Simple enough to explain. Which is a good sign.
