On 1 July we started a pilot to move our internal team collaboration off Slack and onto a platform we run ourselves, based on Matrix and the Element client. One week in, the pilot already carries day-to-day conversations across the company, and we're confident we can retire Slack for internal use.
This is more than a change of chat tool. It's part of how we think about software and how we run our own services, and, frankly, it's about who ends up holding our data.
Practising what we teach
EDC4IT has always been a vendor-neutral, open source training company. We teach Kubernetes, containers and cloud native engineering because open standards and open tooling give organisations control and longevity. Running our own collaboration on Matrix (an open protocol) with Element (an open source client) means our own operations actually match what we tell people in the classroom.
Keeping our data where we can see it
Slack is convenient, but the data lives on someone else's systems, under someone else's terms. Self-hosting Matrix keeps our conversations, files and membership on infrastructure we operate ourselves. That's consistent with the other self-hosted services we already run, and it means data governance is something we decide, not something we accept by default.
Room to work with European partners
Matrix is an open standard with federation built in, which matters for public sector bodies and companies in Europe that care about data residency and digital sovereignty. Running our own homeserver means we can work more directly with government agencies and organisations on their training needs, on terms that respect where their data sits and who controls it.
Integrating on our own schedule
An open protocol means an open surface for integration. Matrix has a documented specification, a client-server API, bots and bridges, so connecting our collaboration tooling to existing products and internal systems, like course and event tooling or notifications, doesn't mean waiting on a vendor's roadmap.
How we actually built it
A short technical note, since this is the kind of work we cover in our own courses.
Our main platform runs on a kubeadm-style Kubernetes cluster. For this pilot we kept Element on its own lightweight k3s instance rather than co-locating it with the rest of our infrastructure. That gives us clean isolation, a smaller blast radius and a lifecycle we can manage independently.
The whole deployment is declarative and managed with Flux, so cluster state is driven from Git: every change is a commit, reviewed and version-controlled, and Flux reconciles the running system to match. Authentication goes through our existing identity provider, and there's no open registration. Federation is switched off for now, so the server stays a private island until we choose to open it up for a specific partner.
The subjects we teach every day
This project touches the same ground we cover every month: Kubernetes, Docker and Podman containers, GitOps and cloud native operations. If your team is heading in a similar direction, our Core Kubernetes Masterclass, Kubernetes Administration and Configuration and Docker/Podman Container Masterclass courses cover the foundations and the practice.
We'll share more as the pilot matures. For now: Slack's on its way out, and we're enjoying running our own.