Matrix is a standard, not a product. Everything around it is work, and that work is what we do.

00

What Matrix is, and the three ways to have one.

A Matrix address works like an email address. Everything after that is a choice about who holds the machine.

Matrix is an open standard for real-time communication. An account lives on a server, an address reads as @you:example.com, and people on different servers reach each other the way email already does. Nobody has to be on the same platform, and no company sits in the middle of the network.

That leaves one decision that actually matters: who holds the server. Everything else — which client people use, which networks you bridge to, how identity is wired — can change later without changing the address anyone has.

There are three ways to have a homeserver. They differ in who owns the machine and who is woken up when it breaks, not in what the software can do.

If this is new

• What a homeserver is, and what it is not
• Why the address carries your domain, and what that is worth
• Federation in plain terms: open, limited to named partners, or closed
• End-to-end encryption, and what the server can still see
• What bridges to other networks can and cannot carry
• What it costs to run, in machines and in attention
• What changes for the people who have to use it every day
• What a realistic first month looks like

The three ways to have one, and what follows

• After an order: we agree the domain, you pay the setup invoice, and the build starts
• A working server, hardened and backed up, to the timetable agreed in the written scope of work
• Then a pilot group, then everyone, then handover. Nothing moves in one jump.
• On infrastructure we operate: dedicated, in the EU, kept current and watched
• On your own hardware or cloud account: installed, hardened and maintained by us
• Entirely on your own: a design, a build and a handover, then you run it
• Any of the three can become another later; the address and the data travel
• No shared tenancy, no per-seat licence, no lock to a client application
• The exit route is designed at the start, not improvised at the end

Not included: accounts on a public server we run for anyone who signs up. Every deployment here belongs to one organisation.

01

Deployment, operation and scale.

A homeserver that starts clean, scales on purpose and stays rebuildable.

Matrix is a protocol, not a package. A deployment is a chain of decisions: which server implementation, which database, where media lives, how the domain is delegated.

We work across the server implementations in the ecosystem and support installs driven by configuration management, containers or a Kubernetes operator. Configuration stays versioned, so a deployment can be rebuilt rather than remembered.

Growth is a separate discipline from installation. Splitting a server by function, controlling room state and testing under realistic traffic all happen before the load arrives, not after.

Install and configure

• Server implementation review: Synapse for almost everything, and the lighter implementations where the workload genuinely calls for one
• On your own hardware the requirements are plain: an x86-64 machine, a current Debian or Ubuntu, unrestricted outbound access, and a domain you control — or a subdomain from us at no cost
• Greenfield install with TLS termination, reverse proxy and hardened defaults
• Server name and delegation through well-known files and service records
• Configuration management, so the whole deployment is versioned and reviewable
• Container platform deployment through charts or an operator
• Database provisioning, tuning and connection pooling
• Media repository on local disk or object storage
• Push gateway, including one dedicated to a branded mobile application
• Registration policy: invite only, tokens, approval, captcha
• Air-gapped and offline installation for networks with no outbound access
• Multi-domain and multi-tenant topologies
• Staging that mirrors production, so upgrades are rehearsed before they land

Scale it

• Worker architecture with request routing split by function
• Stream writer and event persister separation for write-heavy estates
• Replication and cache coordination between processes
• Load balancer rules that respect the homeserver routing requirements
• Room state growth control and state compression
• Media offload to object storage and a delivery layer
• Federation sender scaling and outbound queue management
• Autoscaling policy on container platforms
• Load testing against realistic traffic rather than synthetic best cases
• Multi-region and edge placement analysis
• Large-room and large-space performance work
• Moving to a different server implementation where the workload calls for it

Not included: an on-call rota. Response times are stated in the support levels at /matrix/G. The infrastructure stays yours or your provider's.

02

Migration, relocation and portability.

Move in without losing the thread. Move out without paying for the exit.

Most Matrix projects start somewhere else: a hosted team platform, a chat server nobody upgrades, a public homeserver that was only ever a trial.

Migration runs in stages. A bridge can keep both systems live while people move, so the switch is a fade instead of a cutover.

Portability works the same way in reverse. Ownership here is power levels, not a licence, and the exit path gets designed at the start.

Coming in

• Migration from hosted team platforms, community servers, IRC or XMPP
• History import with authorship, timestamps and attachments preserved
• Account mapping between your existing directory and Matrix identifiers
• Database migration from an embedded store to a production engine
• Media store migration to object storage or a delivery layer
• Move from built-in password login to a dedicated authentication service
• Phased cutover with both systems bridged and running side by side
• Rollback and contingency planning for every stage

Moving, leaving, repeating

• Homeserver relocation to new hardware, a new region or a new provider
• Server name change and delegation strategy
• Switching between server implementations when the operating model changes
• Room version upgrades across the estate
• Export, archival and decommissioning of the platform you leave
• Internal distribution build, so teams can stand up conformant servers
• Reference architecture and golden configuration for repeated deployments
• Tenant provisioning and deprovisioning where you host on behalf of others
• Offline artefact bundles and private mirrors for restricted networks

Diagram

Eight decisions that shape a Matrix deployment for an institution. Each one made deliberately, rather than inherited from a default.

00 The record

• What this covers — Deployment, hardening, single sign-on, federation policy, moderation, calls and the documentation an institution gets asked for. Every setting below is a decision, and every decision is written down.
• What is written down — Documentation, diagrams and architecture decision records, plus a full data-protection document set: impact assessment, processing register, deletion policy and breach procedure.
• Operations: configuration review, recovery planning and database restore testing in an isolated environment.
• Topics covered — Sovereignty and privacy, self-hosting, containerisation, data protection and retention, single sign-on, branding, bots and widgets, support integration, selective federation, moderation and compliance, operations and observability, adoption, recommendations.
• Your ticked cells travel with this message.

01 Hosting

Where does the homeserver actually live?

• A. Managed cloud
• + Running the day you sign up, with nobody to hire
• + The right answer for a small team with no one to operate a server
• - The provider's retention, limits and data location become yours
• - Upgrades arrive on their schedule, not yours
• B. Dedicated server
• + Database, media and logs sit on hardware you can name
• + Retention, upload limits and hardening are yours to set
• - Somebody has to patch it, watch it and answer for it
• - A bad configuration is your outage, not a status page

Homeserver, client, identity provider, database and reverse proxy, containerised on hardware the institution controls.

02 Federation

Who is allowed to reach your rooms?

• A. Open federation
• + The whole Matrix network from day one
• + The right answer for a research group whose collaborators are already elsewhere
• - Your moderation surface is the entire network before your policy exists
• - What has federated out cannot be recalled
• B. Allowlist federation
• + The federation port stays shut until you decide otherwise
• + Partner servers are admitted by name, one at a time
• - Everything outside the list is unreachable, including things people want
• - Every new partner is a decision somebody has to make

A deployment can start closed. Federation port shut, an explicit server allowlist, and moderation in place before the first external server is admitted.

03 Identity

How does a person sign in?

• A. Local accounts
• + Login works even when nothing else is running
• + The right answer for a twenty-person pilot with no directory to talk to
• - Registration, password resets and offboarding become a helpdesk queue
• - A leaver keeps a working account until somebody remembers
• B. Single sign-on
• + One institutional identity, with the account lifecycle already solved elsewhere
• + Email-domain filtering decides who may register at all
• - The identity provider becomes a second thing you operate
• - Misconfigure it once and nobody signs in at all

Identity-provider integration, realm separation, email-domain filtering and database configuration.

04 Encryption

Which rooms are end-to-end encrypted?

• A. Every room
• + The server operator can read nothing, and that includes us
• + The right answer when the threat model includes the host
• - Search, bots, widgets and compliance review all lose their view
• - Bridges and end-to-end encryption do not compose cleanly
• B. Differentiated by room
• + Encryption where the content warrants it, plain rooms where it does not
• + Search, bots and archiving keep working where they are needed
• - Somebody has to write the rule and defend it
• - A wrong classification is a quiet mistake, not a loud one

We agree encryption room by room and document its effects on bridges, moderation, search and archiving.

05 Retention

How long does anything stay?

• A. Keep everything
• + Nothing is ever lost and nobody has to decide anything
• + The right answer where a records law requires indefinite retention
• - It is the default in most deployments, chosen by nobody
• - Every message you never deleted is one you still have to account for
• B. Server-side retention policy
• + Messages and locally uploaded media expire on a stated schedule
• + Other servers' media is cached, not archived
• - Expired is expired. There is no undo
• - The schedule has to be agreed before it can be set

One period for messages and locally uploaded media, a shorter one for media from other servers. Both are configuration, and both are documented.

06 Moderation

What happens when something goes wrong in a room?

• A. By hand
• + No extra machinery. An admin reads the report and acts
• + The right answer for one room with fifteen colleagues in it
• - Response time is whoever happens to be awake
• - Nothing learned in one room protects the next one
• B. Policy-enforced
• + One policy room applies its bans across every protected room
• + New rooms inherit protection instead of being configured
• - A bad policy propagates as fast as a good one
• - Somebody still has to own the list

A moderation bot enforces policy across the estate, alongside a plugin runtime carrying the everyday jobs.

07 Meetings

Where does the call happen?

• A. An external link
• + Whatever the institution already licensed and already approved
• + The right answer when the procurement cycle closed last year
• - A second product, a second login, a second privacy review
• - Chat is one place, the call is another, and the notes are in a third
• B. Inside the room
• + The call starts where the right people already are
• + Widgets keep the meeting beside the conversation
• - More to operate: media servers, TURN, signalling
• - Client support for in-room calling is still uneven

OpenTalk, Jitsi with Prosody, Jicofo, JVB and coturn, and LiveKit for Matrix-RTC, surfaced as widgets inside rooms.

08 Admin surface

Who can reach the control plane?

• A. Public endpoints
• + Reachable from any device, with no tunnel to distribute
• + One less system to run when the team is small
• - Anyone who guesses the hostname reaches your login page
• - The admin API is a high-value target on a very public port
• B. Network-gated
• + Admin surfaces answer to a source address, not to a name
• + There is no login page to attack because there is no route to it
• - You need a working tunnel before you can fix anything
• - Lock yourself out and recovery is a console session

Administrative surfaces sit behind WireGuard, addressed by source IP rather than DNS. Authenticated media, push without message content, upload size limits, automatic pruning of stale devices and bounded refresh-token lifetimes are all set explicitly.

09 Send the route

Tell us which column you are on and what you are trying to run. Your eight selections travel with this message.

• Rooms, people, deadline. Whatever you already know.
• No tracking on this page. No third-party requests. Nothing is transmitted from here: your route and message are written into a draft in your own mail program, and it is not sent until you send it.

Not included: guarantees about what another supplier will release to you. Export quality is their decision, not ours.

03

Federation, bridges and discovery.

Reach other organisations. Reach other networks. On stated terms.

Federation is the part closed platforms cannot copy. Separate organisations keep separate servers and still share a room.

It is also the part that needs a written policy. Open, allowlisted, partner only and fully closed are all valid, and each one changes what has to be watched.

Bridges extend the same idea past the protocol edge. They connect people who are not moving, and buy time for the people who are.

Federation policy

• Federation model: open, allowlisted, partner only or closed
• Allowlists and denylists with a review process for adding partners
• Server access control lists per room
• Well-known delegation, server discovery and certificate strategy
• Signing key management, rotation and notary configuration
• Diagnostics for state resolution, missing events, backfill gaps, stuck traffic
• Partner onboarding runbooks for cross-organisation rooms
• Cross-domain and one-way transfer designs for segmented networks
• Policy servers and shared policy-list subscription across partners
• Defederation procedure for partners who have to be removed

Bridges and finding things

• Bridge architecture: which networks, and what the room model should be
• Bridges to WhatsApp, Telegram, Signal, Discord, Slack, Google Chat, Google Messages, Instagram, Facebook Messenger, LinkedIn, Bluesky, Steam, IRC and email
• Which of those a deployment gets is your choice: each one is a component that has to be run, watched and occasionally repaired, and none is switched on by default
• Identity mapping, so bridged messages carry the right author
• Relay configuration for remote participants with no Matrix account
• Encrypted bridge configuration
• Bespoke bridges on the application service API for in-house systems
• Bridge monitoring, retirement and data handling at shutdown
• Room directory publication and discovery scoping
• Alias and permalink strategy, including stable addresses for long-lived rooms
• Space hierarchy design, so newcomers find their way without being told

Not included: control over the far side. A bridge lives and dies by the other network's API and terms of service.

04

Sign-in, accounts and directory integration.

One account, one directory, one way in.

Local passwords do not survive contact with an organisation. Matrix speaks OAuth and OpenID Connect through a dedicated authentication service, so sign-in can live where the rest of your access already lives.

The interesting work is the lifecycle, not the login. Joiners, movers and leavers have to land in the right rooms and lose the right ones without anyone filing a ticket.

Getting in

• Delegated authentication through a Matrix authentication service
• Upstream identity provider integration with directory services and brokers
• Migration from built-in password login to delegated sign-in
• Multi-factor and conditional access enforced at the identity provider
• Signed identity token exchange, so widgets and services know who is present
• Certificate pinning and device management for managed client fleets
• Guest access and invitation by email or phone where the case calls for it

Accounts over time

• Provisioning and deprovisioning driven from the corporate directory
• Joiner, mover and leaver flows mapped onto accounts, rooms and spaces
• Identifier policy: localparts, display names, avatars, vanity addresses
• Third-party identifier binding and reconciliation
• User directory scoping, so search returns only what policy allows
• Deactivation, renaming and reinstatement procedures
• Session management, token lifetime and forced sign-out paths

Not included: running your identity provider. The work stops at the integration and the mapping.

05

Keys, devices and recovery.

Encryption people can recover from.

End-to-end encryption is the easy half. The hard half is a lost phone, a wiped laptop, or someone joining a room years into the conversation.

Cross-signing, key backup and secret storage turn encryption from a demonstration into something an organisation can operate. Each one changes what search, export and archiving are able to see.

Those limits get written down rather than smoothed over.

Turning it on

• Encryption by default for new rooms, with the exceptions named
• Cross-signing and device verification, including emoji and code-scan flows
• Key backup and server-side secret storage, with recovery key handling
• Migration to the current cryptographic stack across clients and SDKs
• Bots, bridges and services made to work inside encrypted rooms
• Room key rotation strategy, and what it costs you elsewhere

Living with it

• Device and session lifecycle, including revocation of lost or retired devices
• History visibility and key sharing policy, so a join reveals what you intend
• The honest effect of encryption on search, export and archiving
• Content scanning and antivirus placement where encryption still permits it
• Key custody and recovery documentation for the organisation
• User guidance, so verification and recovery are used as they were designed

Diagram

01 → 06 · Outside In

01 Perimeter

WireGuard, closed ports, no route in from DNS

Administration is not on the public web. Admin surfaces answer only through a WireGuard tunnel, and only to a permitted source address, never to a hostname.

• The federation port stays closed until opening it is a decision rather than a default.
• nginx terminates the public side; everything behind it is reached from inside the tunnel.
• Nothing about the deployment can be found by resolving DNS.

wireguard · nginx · source-address acl · federation port closed

02 Federation

Allowlist first, open when moderation is ready

We configure federation to the organisation's policy: closed, allowlisted or open.

• Opening federation follows moderation readiness. It never precedes it.
• The allowlist is the written record of who the organisation has agreed to talk to.
• Selective federation is a policy decision, written down before it is switched on.

synapse · federation policy · server allowlist

03 Identity

Single sign-on, realm separation, email-domain filtering

Single sign-on runs on an identity provider such as Keycloak, with realm separation and email-domain filtering, so accounts follow the institution's own directory rules instead of a second private one.

• Identity-provider integration and database configuration follow the organisation's requirements.
• Refresh-token lifetime is bounded and stale devices are removed automatically.
• Branding sits in the login path itself, not bolted on afterwards.

keycloak · realm separation · postgresql · element web

04 Governance

Policy enforcement across the estate, plus everyday automation

Moderation is configured before a space opens, not after an incident. A moderation bot enforces policy across the estate; plugins carry the routine work.

• A student space and a staff space are not governed alike, on the same server.
• Bots and widgets handle routing, reminders and handoff into the support desk you already run.
• We review configuration and document recovery procedures.

moderation bot · plugin automation · policy lists · support integration

05 Data

Server-side retention, and the paperwork behind it

Retention is set at the server: one period for messages and locally uploaded media, a shorter one for media pulled in from other servers.

• Media is served only to authenticated requests. Push notifications carry no message content. Upload size is capped.
• We prepare impact assessments, processing registers, deletion procedures and breach procedures.
• Documentation, diagrams and architecture decision records say why each setting is what it is.

synapse retention · postgresql · authenticated media · content-free push

06 The Room

Encryption where it earns its place

We agree encryption room by room, with the organisation's moderation, search and retention requirements.

• Encryption changes what moderation, search, bots and widgets can do. Switching it on everywhere would quietly disable the five layers around it.
• We document how bridges affect encryption before integration.
• Calls live inside the room: OpenTalk, Jitsi and LiveKit for Matrix-RTC, self-hosted, opened as widgets.

element web · livekit (matrix-rtc) · opentalk · jitsi: prosody / jicofo / jvb / coturn

Not included: reading encrypted history without the keys. Nobody can offer that, and an offer to do it is the warning sign.

06

Client applications, chosen, themed or built.

The client is a choice. The server does not decide what people look at every day.

Matrix separates the server from the application, which means the thing people actually see is a decision you make separately, and can revisit without touching the deployment. Several mature clients exist; they differ in feel more than in capability.

Choosing is easier by audience than by feature list. People arriving from a team chat platform want something familiar. People arriving from a community platform want channels and threads. People who administer the estate want a lean desktop application that does not fight them.

Beyond choosing, there is theming, packaging and fleet management: your colours and name, distribution through the channels your organisation already uses, and a policy for which applications are allowed to connect at all.

Choose and deploy

• Element Web and Desktop for people arriving from a team chat platform
• Element X for people who live on a phone and want it fast
• FluffyChat for people who want something simple, and for schools
• Cinny for people arriving from a community platform, who expect channels
• Nheko for administrators and anyone who wants a lean native application
• Chosen by who is going to use it, not by comparing feature tables
• Web client hosted on your own domain, not a third-party address
• Desktop packaging for Windows, macOS and Linux
• Mobile distribution through the stores or an internal channel
• Push notifications through a gateway you control
• Single sign-on wired through to the client
• Fleet policy: which client versions and applications may connect
• Migration of people between clients without losing history or keys

Make it yours

• Theming: colours, name, icon, wording, first-run experience
• A branded build published under your own developer account
• Feature removal, where less is the point
• Widgets that put your own tools inside the room
• Custom work against the published client SDKs
• Accessibility review against the client you actually ship
• Client selection, theming and integration are agreed in the scope.

We select and theme an existing Matrix client to suit your organisation.

07

Clients, bots, widgets, calls and SDK work.

The room is a surface. Put the work on it.

Matrix publishes an application service API, a widget API and SDKs in most working languages. That is enough to make the room part of the workflow instead of a place to discuss the workflow.

Client work runs from a themed build to a purpose-made application: kiosk, single room, read-only display, low bandwidth, or messaging embedded in software you already ship.

Calls belong here too. Group calling needs a forwarding unit, a credential service and firewall rules, not just a button in a client.

Clients and code

• Client evaluation across web, desktop, mobile and terminal options
• Branded builds: name, icon, colours, store presence, signing and release
• Bespoke clients on the Rust, JavaScript, Kotlin, Swift, Dart or .NET SDKs
• Purpose-built clients: kiosk, single room, read-only, field and low bandwidth
• Matrix messaging embedded inside an application you already ship
• Accessibility work and localisation, including right-to-left layouts
• Application services, custom events and state for domain data in the room
• Homeserver modules: spam checks, third-party rules, custom authentication hooks
• Conformance and interoperability testing across clients and servers

Bots, widgets and calls

• Bot platform with a plugin model, so many automations share one runtime
• Bots for helpdesk intake, alerting, feeds, approvals and housekeeping
• Email-to-room and room-to-email gateways
• Widgets: whiteboards, polls, meetings, dashboards, forms, approvals
• Widget authentication with signed tokens, hosting and permission scoping
• Conferencing in standalone and embedded modes
• Forwarding unit deployment and scaling, so group calls are not a peer mesh
• Relay and traversal servers, firewall rules and address translation handling
• Mobile call notification wiring, so incoming calls ring on locked devices
• Recording, retention and consent handling where regulation requires it

Not included: widgets are not part of the specification core. Worth knowing before a roadmap leans on them.

08

Moderation, retention and data protection documents.

Policy that holds up when someone asks to see it.

Moderation here is protocol-level work: power levels, policy lists, room access control, reports. The tooling is open and available. What is usually missing is the policy behind it.

Data protection sits in the same place. A federated, replicated, encrypted system needs its records of processing, its retention rules, and an honest description of what erasure can and cannot reach.

Moderation

• Moderation tooling with a bot holding the authority it needs
• Policy lists: local lists, subscriptions to shared lists, lists you publish
• Protection tuning against join floods, spam waves and unwanted media
• Power level and role design, so moderators hold exactly what they need
• Report routing into a triage queue with a named owner
• Server bans, room access control lists and quarantine procedures
• Content scanning and hash matching at upload time
• Trust and safety runbooks, escalation paths and decision records
• Transparency reporting aligned to the regime you operate under

Records and rules

• Impact assessment support and records of processing
• Data mapping across rooms, media, keys, devices and federation traffic
• Residency and hosting-location design
• Retention and message expiry policy, and its technical enforcement
• Subject access, export and redaction with the real limits stated
• Encryption at rest and key custody documentation
• Processor and subprocessor documentation for every component in use
• Security architecture description, threat model, configuration standards
• Acceptable use, onboarding and offboarding policy text

Not included: legal advice or sign-off. These are engineering documents your counsel reviews, not a replacement for counsel.

09

Observability, maintenance and support.

Someone has to watch it on a Tuesday.

A homeserver that nobody watches is a homeserver nobody can defend. Metrics, logs and traces are what turn a report of "chat is slow" into a named component.

Maintenance is the unglamorous half: updates, cleanup, drift, and a restore that has actually been run rather than scheduled.

Support here means sitting behind your own helpdesk, not in front of your users.

Watch it

• Metrics and dashboards across homeserver, database, bridges, media and calls
• Structured logging and aggregation with retention aligned to policy
• Distributed tracing for slow requests and federation delays
• Alert rules tied to written runbooks rather than raw thresholds
• Synthetic checks for login, delivery, federation reach and call setup
• Administration console for day-to-day user and room management
• Admin API automation for the repetitive operational jobs
• Capacity and growth reporting, and cost reporting for the deployment

Keep it running

• Managed maintenance: updates, component upgrades, routine cleanup
• Security advisory tracking and patch planning for what you run
• Version tracking, upgrade scheduling and long-term-support tracks
• Configuration drift review and correction
• Backup configuration and rehearsed restore, tested rather than assumed
• Database maintenance, media hygiene, orphan cleanup and quota policy
• Incident response runbooks and post-incident review templates
• Escalation support sitting behind your own helpdesk
• Periodic health checks delivered as a written report

Not included: an on-call rota or anything that needs a second person awake. Response times are stated in the support levels at /matrix/G. Operations stay with you or your provider.

10

Independent review, training and advisory.

An outside read of what you run, the training to keep it, and advice before you commit.

Plenty of deployments work and nobody can say why. A review is bounded work with a written result: what is exposed, what is stale, what breaks next.

Training is the other half. The point of an open standard is that you are not obliged to keep anyone. Handover is the deliverable, not the risk.

And sometimes the useful answer arrives before any of that: whether this standard fits the requirement at all.

Independent review

• Configuration review against current recommended practice
• Security review of exposure, authentication, rate limits and secret handling
• Federation posture: what is reachable, what is trusted, what should be neither
• Encryption posture: cross-signing, key backup, device hygiene, open rooms
• Performance and capacity review with the real bottlenecks named
• Backup and restore validation that tests the restore, not the schedule
• Upgrade path review, including components past end of life
• Bridge and bot inventory with an owner recorded against each
• Prioritised remediation roadmap with effort and impact stated per item

Training, handover, advice

• Administrator, operator and moderator training on your own deployment
• Developer sessions on the client-server API, application services and widgets
• End-user onboarding, plus device verification and recovery habits
• Train-the-trainer material, so the organisation carries on without us
• Runbooks, handbooks and handover documentation written for your setup
• Vendor-neutral advice on whether an open messaging standard fits at all
• Build versus buy, and self-host versus managed, with the trade-offs stated
• Procurement support: requirement text, evaluation criteria, questions to ask
• Exit strategy and portability review, so the deployment stays yours to move

Diagram

Homeservers, clients and single sign-on, deployed and hardened for schools, universities and public institutions.

01 AUDIT

Stage 01 / 09

Questions before containers. What you already run decides most of the architecture, and the rest of it is policy rather than software.

• What identity you already have, and which mail domains may hold an account
• What must be logged, what must never be kept, and for how long
• Which institutions you must talk to, and which you must not
• Whether one dedicated server is honestly enough for the load you describe

OUT: written findings, a target architecture and a scope you can sign off.

02 DESIGN

Stage 02 / 09

Every choice that is expensive to reverse is written down before it is made. Architecture decision records and diagrams explain the choices for the organisation.

• Federation policy agreed before launch: closed, allowlisted or open
• Retention: one period for messages and local media, a shorter one for remote media
• Encryption applied per room as a deliberate model, not as a single switch
• Bridges assessed on paper, including where they break end-to-end encryption

OUT: decision records, diagrams and a policy set your data-protection officer can read.

03 DEPLOY

Stage 03 / 09

Homeserver, client, database and reverse proxy, containerised, on hardware you control. Every component is versioned, so the deployment can be rebuilt rather than remembered.

• One dedicated server, with no third-party operator holding your messages
• PostgreSQL configured for Synapse rather than left on its defaults
• nginx in front, with .well-known delegation so federation reads the right name
• Element Web carrying your name and your colours, not a vendor logo

OUT: a running homeserver, defined in files rather than assembled by hand.

04 IDENTITY

Stage 04 / 09

One account, one password, one place to revoke it. Single sign-on connects Matrix to your existing directory.

• An identity provider in front, with realm separation
• Filtering on mail domain decides who is allowed to hold an account at all
• Identity provider database configuration and integration
• Matrix trusts the provider, so access ends where the directory says it ends

OUT: sign-in through your own identity provider, and one list of people rather than two.

05 HARDEN

Stage 05 / 09

Defaults are written for the open internet. An institution needs the settings behind them, and a written record of which ones moved and why.

• Authenticated media, so a file is not readable by anyone holding a link
• Push notifications that carry no message content off the server
• Upload size limits, stale devices pruned, refresh tokens with a bounded life
• Admin surfaces reachable only over WireGuard, by source address, never by name

OUT: a hardening record. Every setting that differs from the default, with the reason beside it.

06 FEDERATE

Stage 06 / 09

Federation is a policy, not a switch. It opens when moderation is ready to hold it, and it opens to named servers first.

• Federation access configured to the agreed policy
• A moderation bot enforcing policy across the estate
• Bot plugins for routine room work and service integration
• Reporting, escalation and evidence handling written down before anything opens wider

OUT: a federation and moderation model your legal and student-welfare people can both read.

07 MEET

Stage 07 / 09

Chat is where the work starts. Calls and widgets are where it finishes. Real-time media hosted next to the homeserver, so a call does not leave the estate either.

• OpenTalk for scheduled meetings, hosted alongside the homeserver
• Jitsi with Prosody, Jicofo, JVB and coturn, all self-hosted
• LiveKit carrying Matrix-RTC calls inside the Matrix client
• Widgets embedded in the room, so a seminar does not have to leave the room to work

OUT: chat, meetings and calls on one estate, under one set of rules.

08 OPERATE

Stage 08 / 09

Launch day is not the interesting part. The interesting part is the Tuesday when something is wrong and someone has to understand it rather than restart it.

• Security monitoring and incident-response planning
• Configuration review and documented recovery procedures
• Database restore testing in an isolated environment
• Retention enforced at the server, not left to whoever remembers

OUT: honest scope, said in advance rather than discovered later.

09 HANDOVER

Stage 09 / 09

You should be able to replace us. The documentation is the proof that you can, and it is written for the person who inherits the system.

• Documentation, diagrams and architecture decision records
• DPIA, processing register, deletion policy and breach procedure, all prepared
• Every setting that differs from the default, with the reason it differs
• Written for whoever inherits this, not for whoever built it

OUT: the system, the documents and the accounts, with nothing left only in our head.

10 CONTACT

Target

Start at stage 01. An audit is a small, fixed piece of work, and it tells you whether the rest is worth doing.

• Scope a deployment
• Ask about moving
• Request a quote
• Just a question

No third-party scripts, no tracking, no captcha. Or write to hello@ave17.com

Not included: a pass or fail certificate. A review reports findings. Certification is a separate regime with separate auditors.

start

Start with the problem, not the product.

• Tell us what you run now, what it has to become, and what constrains it. Regulation, headcount, network isolation, an existing directory, a platform you are contractually stuck with until next year.
• You get back questions, a rough shape of the work, and a clear note on the parts we would not take on.

Write to

hello@ave17.com

About

Matrix

Not included: a fixed quote from a first message. Scope comes before price, always in that order.

A

The usual path, and the open-standard path.

Two ways to own a conversation. Neither column names a brand: the difference is structural, not competitive.

Not included: a claim that the right column is always the answer. Some requirements are genuinely served better by a product you buy.

B

Six layers between the internet and a sentence.

Every layer is a separate decision, and each one can be got wrong on its own. Select a ring to read what it decides.

Perimeter

DNS, delegation and TLS decide what is reachable before a message exists at all.

Federation

Allowlists, server access control lists and signing keys decide which servers may speak to yours.

Server

Homeserver, database and media store hold the estate. Hardening and rate limits keep it standing.

Identity

The identity provider and authentication service decide who holds an account, and for how long.

Room

Membership, power levels, join rules and history visibility decide who sees what, and from when.

Message

End-to-end encryption, device keys and cross-signing decide who can read the content. Servers relay it. They do not read it.

Not included: a promise that all six arrive configured. Most deployments do three of them well and inherit the rest.

C

How a project runs.

Six stages, each with something written at the end of it. Select a stage to read the work and what comes out.

Not included: fixed duration. Stages are sequential, but their length depends on your estate and your approvals.

D

Three ways to federate, and how to pick one.

Federation is the word that frightens procurement, usually because it is heard as "open to the whole internet". It is a setting, and it has three positions.

Closed

Your server talks to nobody else. Every account is one you issued, every room is internal, and no message crosses your perimeter. Federation is switched off, not merely filtered.

For estates where the answer to "can this reach outside" has to be no, in writing.

Named partners

Your server federates with a list of servers you name, and refuses the rest. Suppliers, a parent body, another agency: each is added deliberately and can be removed the same way.

The common case. Reach where you want it, a closed door everywhere else.

Open

Your server federates with the public network. Anyone with a Matrix address can reach your people, subject to your own join rules, room policy and moderation.

For public-facing work: communities, support, anything where being reachable is the point.

Not included: a claim that open federation is safe by default. It needs moderation, room policy and someone paying attention.

E

The questions that actually get asked.

Not an introduction to the protocol. These are the eight questions that come up once somebody is seriously considering it, answered the way we would answer them on a call.

How is this different from a free public server?

A public server is shared: your address carries somebody else's domain, your data sits beside everyone else's, and the operator's rate limits and policy are yours by inheritance. Here the deployment is yours alone, the address carries your domain, and the limits are the ones you set.

Is it really compliant, or just hosted in Europe?

Location is one fact among several, and on its own it proves nothing. What matters is who can reach the data, under what process, and whether you can check the claim rather than take it. The access section at /matrix/H sets out exactly what access exists on our side and how to verify it from outside.

Can we run it on our own hardware?

Yes, and it is the cheaper of the two. Your machine, your cloud account or your data centre; the installation, hardening and upkeep are ours. Requirements are listed under Deploy.

What happens if we want to leave?

You take the server. The address, the rooms and the history belong to the deployment, not to a contract with us. The exit route is designed at the start and written down — see Leaving.

Do you charge per person?

No. A hundred people or a thousand costs the same. Price follows the infrastructure and the work, not headcount.

Who can read our messages?

In an end-to-end encrypted room, nobody but the participants' devices — not the server, not us. Outside encrypted rooms the server holds content, and anyone with administrative access to that server can reach it. That includes us, while we maintain it. The access section at /matrix/H sets out the limits and how to audit them.

How fast do you answer when something breaks?

Standard support answers within two working days; priority support within eight working hours. An outage is always counted but never charged, whatever the plan. See Support.

Can we see it working first?

We discuss your requirements and agree how to evaluate the proposed deployment.

Not included: a promise that every answer here survives contact with your environment. Some will change once we have seen it.

F

What it costs.

Move the numbers and watch the total. Nothing is sent anywhere; this runs in your browser and is an estimate, not a quote.

Setup, once

590 EUR

Engineering outside scope

110 EUR an hour

An assessment

from 3 days at 110 EUR an hour

Above 1000 users

the ladder stops and we quote

No VAT is added: we are not registered for it, so the figure shown is the whole figure.

Setup is charged once; everything else is monthly. Unusual constraints are scoped before they are priced.

Not included: a fixed quote from a first message. Scope comes before price, always in that order.

G

What support covers, and what it does not.

Two levels. What each one covers is written down, and so is what it does not.

Working hours, Monday to Friday, excluding public holidays: a request sent on Friday evening is answered on the next working day. Three separate asks in one message count as three requests.

Covered

• The server is down, unreachable or returning errors
• A component that was installed as part of the deployment has failed
• System-level trouble: disk, memory, certificates, backups
• Reconfiguration you ask for: add a component, change a policy, adjust a limit
• Upgrades, and anything that breaks during one

Not covered

• General questions about how the underlying open software works
• Writing your own bots or application services
• Why a third-party component behaves the way it does — its own authors answer that better than we can
• A third-party component breaking after its own upstream changes
• Distribution upgrades of your operating system, on your own machine
• Advice on building a business on top of the software

Not included: a 24-hour rota. Response times are working hours, and they are stated rather than implied.

H

What we can reach, and what we cannot.

The uncomfortable half first, because a page that claims no access at all is not telling the truth.

What we can reach

• Any file on a server we maintain — maintenance runs over SSH with root
• Anything stored unencrypted, including data relayed from other networks, which by their own design cannot be end-to-end encrypted
• Database contents, logs and backups of the deployment
• Account metadata: who exists, when they connected, which devices they hold

What we cannot reach

• The content of end-to-end encrypted rooms — the keys live on the devices, not on the server
• Anything on a machine we were never given access to
• Backups are encrypted with a key you keep. While we administer the machine we have access to the data itself. After our access is revoked we cannot read the backups
• Any deployment after handover, where access has been withdrawn

What we wrote ourselves

• The configuration management that builds and maintains every deployment
• The monitoring and alerting that watches it afterwards
• Matrix client selection, theming and integration
• The backup and restore tooling, including the part that tests the restore
• Everything else on a deployment is third-party open source, named openly on the service pages

How to check, rather than believe

• Logins and program starts are recorded in the audit log on your own machine
• Ask for access to be withdrawn between pieces of work; it is a normal request
• Run the audit framework and watch at the system-call level
• Verify the infrastructure claims yourself. Public tests and instructions are in the section "Where it runs, and how to check without asking us." at /matrix/I.

Could and does are different things. The access exists to keep a server running and to repair it when it breaks. It is used for nothing else, and the way to hold us to that is the log, not our word.

Not included: a claim of zero access. Maintaining a server means being able to reach it, and pretending otherwise would be a lie you could catch.

I

Where it runs, and how to check without asking us.

Most operators end this section at "servers in the EU". Everything below can be tested from outside, by you, without asking us.

Run the tests yourself

• internet.nl — independent tests for both the site and the mail of any domain
• DNSViz — walks the DNSSEC chain and shows every signature
• Hardenize or an equivalent — one page covering DNS, mail and web posture
• An SSL report against the host — certificate, chain, protocol support
• Point any of them at ave17.com. We are not asking you to take the claim on trust.

None of this makes a chat server secure on its own. It shows how the company is kept, which is the part you can verify before you have signed anything.

Operational controls are documented and can be checked by you.

J

How to leave.

The exit is designed at the start. An operator who makes leaving awkward has told you something about the rest of the arrangement.

You own the identity

The server name is your domain. Whoever operates the machine, the addresses your people hold do not change hands.

You get the machine, not an export

A deployment is a database, a file store and a configuration. All three are handed over as they are, not converted into a farewell archive.

The configuration is readable

Deployments are versioned and reviewable. Your next engineer can read how it was built instead of guessing.

Handover is a service, not a penalty

Runbooks, a walkthrough and a named owner for each component. Priced as work, at the ordinary rate.

Access is withdrawn on request

Keys removed, sessions ended, and the removal visible in your own logs.

No exit fee, ever

There is no charge for leaving and no notice period dressed up as one.

This is also the honest answer to lock-in. The protocol is an open standard: another operator can pick your deployment up, and several exist. That is the point of not owning the protocol.

Not included: free labour. Handover is work and is charged as work — but nothing is charged for the act of leaving.

K

Who you are dealing with.

Who you are dealing with, and the paperwork that goes with it.

The full terms of service, the privacy notice and the Article 28 data processing agreement are published on this site, before anyone is asked to sign anything.

Write to

hello@ave17.com

About

Matrix

Not included: legal advice. This states our own position; your obligations are yours to take advice on.

How it works

• A · The usual path, and the open-standard path
• B · Six layers between the internet and a sentence
• C · How a project runs
• D · Three ways to federate, and how to pick one

Before you buy

• F · What it costs
• G · What support covers, and what it does not
• E · The questions that actually get asked

Before you trust

• H · What we can reach, and what we cannot
• I · Where it runs, and how to check without asking us
• J · How to leave
• K · Who you are dealing with