Which fits: AWS Wickr or self-hosted Matrix and Element for encrypted messaging
Matrix with Element fits when the organization must run the servers and hold the keys itself. Consider a team facing a Wickr renewal, a data residency rule from its regulator, and a wish to control its own messaging infrastructure. If the rule requires message servers to stay in a named jurisdiction and under the team's own administrators, a self-hosted homeserver is the likely answer. AWS Wickr fits when the team wants a managed service that AWS operates, when cloud operations already run on AWS, and when government workloads need WickrGov in GovCloud. Federation with partner organizations is the other main reason to choose Matrix, so confirm with AWS whether Wickr meets that need before you decide.
Matrix with Element is the stronger fit when the homeserver is a deliberate platform commitment. Synapse, the most widely documented Matrix homeserver, is developed by Element and licensed under AGPL-3.0, and Element Server Suite offers a free Community edition, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. Federation is controlled in configuration: federation_domain_whitelist restricts federation to listed domains, an empty list disables it, and the federation listener should also be firewalled. Teams with disconnected networks have the clearest case for the Sovereign edition, so confirm with Element which edition covers your support, SSO and compliance needs before you compare costs.
Three questions decide it. First, who must hold servers and keys: if the answer is the organization's own administrators inside its own network, Matrix is the candidate, and if a managed provider operating under AWS controls is acceptable, Wickr stays in scope. Second, what retention rules apply: write down how long messages and attachments must be kept, and confirm the retention settings in the Synapse configuration manual, since retention affects storage and any later migration. Third, who patches the homeserver: the Synapse upgrade notes warn that rolling back can be difficult because of database schema changes and that support ends for Python and PostgreSQL versions at upstream end of life, so name an owner for upgrades before go-live.
Which scenarios favor Wickr and which favor Matrix and Element
This table maps common buying scenarios to the platform that fits better and the condition that tips the decision. Read each row against your own policy, network and staffing rather than as a general ranking. Both products offer end-to-end encryption, so the deciding factors are usually where servers run, who operates them and how message archives are kept.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Small team wanting no server operations | AWS Wickr | No staff to run databases, TURN servers, push setup and patching, and the team accepts a managed service's terms. |
| Regulated firm needing servers in its own accounts | Matrix and Element | Policy requires homeservers, databases and logs inside the firm's cloud accounts or data centers. Confirm what hosting control your Wickr plan allows. |
| Cross-organization federation | Matrix and Element | Partners must exchange messages across organizations. Synapse federates on port 8448 by default and can be limited with a domain allowlist. Confirm the partner also federates. |
| Air-gapped or disconnected networks | Matrix and Element | Messaging must run with no outside connectivity. Confirm Element Server Suite Sovereign scope and Wickr's offline options for your network with each vendor. |
| Retained message archive | Depends on your controls | Ask Wickr which retention and export options your plan includes. With Synapse, you own the PostgreSQL data and must design the archive, backup and access controls yourself. |
| Single sign-on across the workforce | Matrix and Element | Your identity provider supports OpenID Connect, SAML2 or CAS, which Synapse can use. Confirm Wickr's SSO support for your plan. |
| Strict control over where message keys and metadata sit | Confirm with both vendors | Both offer end-to-end encryption. Decide on key custody, server location and admin controls using each product's written documentation. |
Who holds the servers, keys and data under each model
AWS operates the Wickr service infrastructure, so your team does not host or patch the messaging servers. Your control sits in the admin console, network and retention settings, and the account structure around the service. Before classifying data, confirm with AWS in writing where message content, metadata and any retained copies are stored, which region or GovCloud environment applies to your deployment, and which encryption keys sit on user devices and which sit in the service.
- Server custody: AWS runs the servers and the platform underneath them, and your staff do not operate them.
- Data location: confirm the region or GovCloud boundary that applies to your tenancy and whether any data leaves it.
- Retention: if retention is enabled, confirm where retained copies are kept, how long they persist, and who can export them.
- Assessment evidence: you rely on AWS compliance documentation for the service plus your own configuration records, access reviews and change logs.
- Exit path: ask how retained data and user records can be extracted if you leave the service.
Confirm each of these points with your AWS account team before you record them in your data inventory.
A self-hosted Synapse homeserver runs in your cloud account or data center, so your organization holds the servers, the PostgreSQL database, media storage and any retained events. Matrix end-to-end encryption keys live on user devices, so key custody depends on how you set up key backup and device verification. Identity and routing depend on configuration you control, and some of those settings are hard to change after launch.
- Identity: the
server_namesetting fixes how users and rooms are identified, such as @user:example.com, so settle it before the first users register. - Delegation: well-known delegation lets identifiers on port 443 be served from another host, while federation uses port 8448 by default. Check the Synapse federation documentation before you publish records.
- Federation control:
federation_domain_whitelistlimits federation to listed domains, an empty list disables it, and the documentation recommends firewalling the federation listener as well. - Database and rollback: PostgreSQL is recommended for production, and rolling back after an upgrade can be difficult because of schema changes, so take tested backups before each upgrade.
- Sign-in:
oidc_providers,saml2_configand CAS keep authentication in your identity provider.
Record the federation whitelist, firewall rules and server_name decision in a change record, then keep configuration files, access logs and restore test results for assessors.
The Sovereign edition of Element Server Suite is built for air-gapped deployments, where the servers, databases, media and backups stay inside an enclave with no route to outside services. The vendor is not in the data path, and your team controls both the keys material held on devices and the offline records that prove how the system was configured. Because the network is disconnected, updates, licenses and evidence all move through processes you must design and document.
- Data location: all servers, databases, media stores and backups remain inside the enclave, and you should verify that no component calls an external endpoint.
- Federation: keep federation disabled with an empty
federation_domain_whitelist, and confirm from outside the enclave that the federation listener is unreachable. - Update path: define how packages, container images and security fixes cross the air gap, including media handling and approval steps, and confirm the mechanism with Element.
- Key custody: device keys stay on user devices, so plan key backup policy and account recovery without relying on internet-based escrow.
- Assessment evidence: keep offline records of configuration baselines, transfer logs, access reviews and restore tests.
Confirm the scope of the Sovereign edition and its terms with Element through the Element pricing page before procurement.
What the AGPL license and Element Server Suite editions change for buyers
The licensing question decides whether self-hosting Matrix is cheap in practice or only in theory. Synapse, the most widely documented Matrix homeserver, is distributed under *AGPL-3.0*, and Element announced on December 13, 2023 that its future contributions would be licensed under AGPLv3 instead of Apache 2.0, with commercial AGPL exceptions sold separately. For an organization that runs Synapse unmodified inside its own network for its own staff, the AGPL generally imposes no fee. The obligations arise when you distribute the software, offer a modified version to users over a network, or bundle it into a product you sell. Those are the points where a buyer needs an answer from counsel before rollout, not after.
Element Server Suite is packaged in three editions, and each maps to a different set of obligations. The Community edition is free and AGPL-licensed and includes Synapse and Element Call. The Pro edition adds Synapse Pro, which is the path to commercial terms and support. The Sovereign edition targets air-gapped deployments. Ask Element which edition includes which components, what support and update terms apply, and whether the AGPL exception covers your use case. Also confirm the Synapse Pro and Sovereign terms in writing, because the edition names describe packaging and do not by themselves set the license terms you accept. Have counsel review whether any modifications, custom clients, or Element Call components you ship to external users trigger source-availability duties.
Treat the license review as a line item in the migration plan, alongside the technical design. Record which components you will run, whether you will patch Synapse, whether external parties such as partners or contractors will use the service, and whether the deployment is internal only. Put these answers to counsel and to Element in one written request, and keep the result with your architecture records. A short memo that states the chosen edition, the license basis and the decision owner gives procurement and auditors something concrete to check. Note that the choice of edition is not a substitute for independent legal advice, and that no part of this section is a statement of the license terms that apply to your organization.
What drives the cost of self-hosted Matrix against Wickr subscriptions
How are Wickr subscription costs structured compared with self-hosted Matrix?
Wickr is a recurring per-user subscription, and the cost scales with the number of licensed users and any add-ons you choose. A self-hosted Matrix deployment has no per-user license fee for Synapse or Element clients, but you pay for the infrastructure, the people who run it and any commercial support or Element Server Suite edition you select. Confirm the current Wickr plan terms, per-user pricing and add-on list directly with AWS, since those change and are not covered in this page. When comparing, put both sides on the same three-year view: subscription fees on one side, and infrastructure, staffing, support and migration on the other.
What does Kubernetes or VM hosting add to the cost of Synapse?
Hosting is a recurring cost that depends on how many users, rooms and federated servers you expect, and on whether you need high availability. Synapse can run on a single virtual machine for small deployments, or on Kubernetes when you want worker processes and rolling upgrades. Ask your provider or platform team for the compute, storage and network sizing they assume, and for who carries the cluster licenses and monitoring. Hosting costs also include backups and disaster recovery environments, which are often underestimated.
Why does PostgreSQL 14 or newer add to the database budget?
Synapse documentation recommends PostgreSQL for production, and Synapse 1.143.0 and later require PostgreSQL 14 or newer. If your organization already runs a supported PostgreSQL service, the added cost is mostly the storage growth and the backup and failover configuration for one more database. If you run it yourself, you pay for the database hosts, patching windows and a tested restore procedure. Confirm which PostgreSQL version your target Synapse release needs, and whether your database platform team will own upgrades.
Do Redis and Synapse workers add cost to a self-hosted deployment?
Redis is needed only when you scale Synapse with worker processes, because it relays replication between the main process and workers. A small deployment can run without workers, so Redis may not be a line item at first. When you add workers, the cost is the Redis hosting, its monitoring and the extra compute for generic workers handling client, federation and event traffic. Ask whether your target design needs workers at your expected load, since that decision changes the hosting bill and the operations workload together.
What does a TURN server cost for Matrix calls, and who runs it?
Voice and video calls across networks that block direct connections need a TURN server to relay media. The cost is the relay bandwidth, which grows with the number and length of calls, plus the server, certificates and monitoring. Many organizations run TURN in a DMZ or a cloud region close to their users, and that placement adds network and firewall work. Ask for the expected call volume, the bandwidth assumptions in the quote and whether the TURN service is in scope or left to your team. If calls are not required, this line item can be removed.
Which Element Server Suite edition changes the cost most?
Element Server Suite comes as a free AGPL Community edition that includes Synapse and Element Call, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. The Community edition removes license fees but leaves support to you, while Pro and Sovereign add commercial terms and vendor support that you need to price. Confirm with Element which features, support hours and license terms apply to each edition, and whether AGPL obligations affect your use. Choosing the edition early keeps the migration design and the support contract aligned.
Who patches Python and PostgreSQL, and what does that cost each year?
Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, and the upgrade notes warn that rolling back can be difficult because of database schema changes between releases. Someone must track those dates, test each Synapse upgrade in staging and schedule maintenance windows. That work recurs every release cycle and is usually the largest ongoing cost, because it draws on skilled staff. Ask any implementation partner for a written upgrade and support model, including who tests, who approves and how long rollback takes.
Which costs are one-time and which recur for a Matrix migration?
One-time costs include architecture and design, the initial build, SSO integration with your identity provider, push notification setup for mobile clients, data migration and the parallel run period. Recurring costs include hosting, database and Redis operations, TURN bandwidth, upgrades, backups, monitoring and on-call coverage, plus any subscription to Element Server Suite. Request the quote as two lists, one-time and recurring, each line with the owner, the assumed user count and the assumed hours or sizing. Keep the migration and the run cost separate so you can compare them with the Wickr renewal over several years.
How a move from Wickr to a Matrix homeserver proceeds at a high level
The sequence moves a Wickr network to a self-hosted Matrix homeserver in controlled stages, so each stage has a documented output before the next begins.
Decide scope and retention before building
Your security, records and compliance leads decide which Wickr conversations, users and files must move, and whether any Wickr data retention was enabled. Retained Wickr data depends on the retention settings your organization had in place, so confirm with your Wickr administrator exactly what exists and what can be exported. The output is a signed scope document listing in-scope users, rooms, retention requirements and the data that will not be carried over. Ask your implementation partner to confirm the scope in writing before work starts.
Deploy a staging homeserver with PostgreSQL
The implementation team builds a non-production Synapse homeserver inside your own infrastructure, using PostgreSQL as the database because Synapse recommends it for production. The team pins versions deliberately, checks that the database meets the minimum PostgreSQL version for the Synapse release chosen, and records the upgrade path. Because Synapse upgrades can be hard to roll back due to database schema changes, the team takes a tested database backup before every upgrade. The output is a staging server that answers client and federation requests and passes a documented backup and restore test.
Enroll users through single sign-on
Your identity team connects the homeserver to your existing identity provider using OpenID Connect, SAML2 or CAS, as the Synapse configuration manual describes, so users sign in with corporate credentials rather than local passwords. Test accounts from each user group sign in, receive the correct profile attributes and are removed cleanly when they leave the group. The output is a sign-in test log for each group and a documented mapping between identity provider groups and homeserver access. Confirm that your identity provider supports the chosen protocol before committing to a design.
Re-create rooms and access groups
Wickr networks, security groups and their membership rules have no direct equivalent in Matrix, so the team maps each Wickr group to a Matrix room with explicit join rules, power levels and invitation settings. Owners of each group confirm the membership list and who may invite or moderate. The output is a room inventory showing the old Wickr group, the new room identifier, the members and the access settings, signed off by each group owner. Any content that was not exported in the previous step is noted in this inventory as not migrated.
Set device verification and key backup policy
Security staff decide how users verify devices, where encryption keys are backed up and who can recover them. Matrix encryption keys live on the user's devices unless a key backup is enabled, so the policy must state whether backup is required, how recovery keys are issued and stored, and what happens when a device is lost. The team tests recovery on a test account by restoring a session from backup on a second device. The output is a written key backup policy and a recovery test record that the security owner has approved.
Run Wickr and Matrix in parallel
Pilot groups use the Matrix clients while Wickr stays available for the rest of the organization. The team tracks message delivery, notification behavior, file transfer, calling and the sign-in experience, and logs every issue with an owner and a fix. Mobile push notifications and TURN servers for calls need separate testing, because they depend on your own network design and not only the homeserver. The output is a parallel-run report that lists open issues and confirms that each pilot group can complete its daily work.
Cut over and retire the old network
After the parallel-run report shows no blocking issues, the team announces the cutover date, makes Matrix the default for the in-scope groups and sets the Wickr network to read-only or retired according to the retention decision in the first step. The team keeps the tested backup of the homeserver database and a documented rollback plan that covers the Synapse version in use. The output is a cutover record with the date, the approved change ticket, the rollback owner and the confirmed Wickr status for each group.
Questions buyers ask before choosing Matrix over Wickr
How much does it cost to run Matrix with Element instead of Wickr?
Cost depends on what you run and who runs it, so there is no single figure to compare against Wickr's per-user plans. Matrix itself is open source, but Synapse is AGPL-3.0 and Element sells commercial terms, and the Element Server Suite comes as a free AGPL Community edition, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped networks. Your recurring costs are infrastructure (servers, PostgreSQL, Redis, TURN, push notification setup), staff time to patch and monitor, and any subscription you choose. Ask any quote to split one-time setup from recurring operations, and to list which licenses are included. The Element pricing page is the place to confirm current edition terms.
How long does a Matrix deployment take to go live?
Time to a working deployment depends on scope: the number of users, whether you need SSO and device enrollment, how many clients you support, and whether the system runs in air-gapped networks. A small pilot on a single host is a different project from a production cluster with workers, backups and monitoring. Agree a timeline only in a written, fixed scope before work starts, which is how DeployOpen engagements are normally set up. Ask for the milestones, what each one depends on from your side, and what counts as done.
What does our team have to supply for a Matrix deployment?
You supply the environment and the decisions, and the implementation work depends on what you already have. Typically that includes:
- Hosting in your cloud account, data center or air-gapped network, with Kubernetes or a host layout you accept
- A PostgreSQL service, since Synapse recommends PostgreSQL for production and 1.143.0 and later require PostgreSQL 14 or newer
- A decision on your
server_name, DNS, TLS certificates and whether federation is needed at all - An identity provider for SSO, such as OpenID Connect, SAML2 or CAS support in Synapse
- Named owners for on-call, patching and backups
Confirm each item against your own environment before the scope is signed.
Can our internal team deploy and run Matrix without outside help?
A capable internal team can run Matrix, but it needs skills in Python or container operations, PostgreSQL administration, reverse proxies, federation DNS and TLS, and push notification setup. The harder part is the ongoing work: upgrades, backup testing, incident response and keeping pace with releases such as Synapse v1.163.0. Many teams split the work, keeping day-to-day operations in-house and buying design, hardening or upgrade support as a fixed-scope project or retainer. Decide which of these you can staff for the next few years, not only for launch.
How do I restrict federation so only approved servers can connect?
Set federation_domain_whitelist in the Synapse configuration to the domains you allow, and it will restrict federation to those domains. An empty list disables federation entirely, which suits a closed deployment. The Synapse documentation also recommends firewalling the federation listener, which uses port 8448 by default, so that only approved networks can reach it. Delegation can serve user IDs such as @user:example.com from another host on port 443, so test the whole path after changes. Confirm the restriction behavior against the Synapse configuration manual for your version.
Can we keep our existing Wickr message data after moving to Matrix?
It depends on whether retention was enabled in your Wickr network, and on what Wickr exports. Wickr's exports and retention settings are not covered by the supplied sources for this page, so confirm with AWS what can be retrieved and in what format before planning. Plan for the migration as a data project in its own right: map which rooms and security groups map to Matrix rooms, decide what history you import, and document what cannot be carried over. Treat encryption keys and device trust separately, since end-to-end encrypted history depends on keys and key backup policy. Ask any implementation partner to write down the retained data scope in the statement of work.
How are upgrades and rollbacks handled for Synapse?
Upgrades follow the release notes, and rollbacks are the risky part. The Synapse upgrade notes warn that rolling back can be difficult because database schema changes occur between releases, so take a verified database backup before every upgrade. Synapse also drops support for Python and PostgreSQL versions once upstream support ends, so plan platform upgrades alongside Synapse upgrades. Test each release in a staging environment that mirrors production, and track new versions on the Synapse releases page. Ask any support provider to define the upgrade and rollback runbook, including who approves each step.
Risks to weigh before moving encrypted messaging off Wickr
Moving from a managed Wickr network to a self-hosted Matrix homeserver trades a vendor's operating work for your own. The risks below connect because each one lands on the same small platform team, and each is easier to price before a pilot than after users depend on the system.
Operating burden and patching cadence
A Synapse deployment is a stack you run: the homeserver, PostgreSQL, Redis when you scale with workers, TURN, reverse proxies and push gateways. Synapse ships new releases often, and the most recent published version in the supplied record is v1.163.0, published October 14, 2026. Ask who applies each release, how long a security fix takes to reach production, and who is on call when a federation or client problem appears at night.
End-of-life support for Python and PostgreSQL
Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, so your operating system and database lifecycle now set your messaging lifecycle. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Before cutover, confirm which versions your base images and managed database service support, and plan a runtime upgrade window alongside each Synapse upgrade.
Features to confirm before commitment
Wickr's retention, compliance export and governance controls are configured per network, and a Matrix stack will not match them by default. Some needs, such as a specific message retention window, a compliance export format or legal hold, depend on the Synapse version and on any commercial add-on you select. Ask Element and your own compliance team to confirm each requirement in writing against the exact edition and version you plan to run.
Federation exposure
Synapse federates by default on port 8448, and a federated server accepts traffic from other homeservers, which changes your attack surface compared with a closed Wickr network. The configuration manual provides federation_domain_whitelist, where an empty list disables federation, and the docs recommend firewalling the federation listener as well. Decide whether you need federation at all, document the allowed domains, and have your security team test the listener before it is exposed to the internet.
User device and key recovery
End-to-end encryption in Matrix binds message keys to devices, so a lost or reset device can leave users unable to read older history unless key backup is set up and tested. Wickr has its own device and recovery model, and the two will not carry keys across. Define the key backup policy before enrollment, decide how SSO-enrolled users recover on a new device, and rehearse a lost-phone scenario with a pilot group.
Cost of running two systems in parallel
During migration, Wickr and Matrix must both run, and each keeps its own identity, admin, licensing and support costs until the cutover is complete. Wickr licensing continues on its own terms while you pay for hosting, staff time and training on the new stack. Ask for a written plan showing how long each system stays live, who pays for each one, and when the Wickr subscription can end.
How DeployOpen helps evaluate, implement and migrate a Matrix deployment
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Matrix and Element deployment, that means work starts from your retention, key custody and federation requirements, then moves to a running homeserver in your environment.
How we scope
- Written scope fixes the homeserver choice, client set, identity provider and hosting location before any build starts.
- Scope names which Wickr retention and compliance needs must carry over, and which can be retired.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing up front; ongoing support is available as a retainer.
How we build
- Build covers Synapse with PostgreSQL, server_name and delegation, federation limits, and SSO via OIDC, SAML2 or CAS.
- Build includes configuring federation_domain_whitelist and firewalling the federation listener to match your policy.
- Security testing of the deployed applications, APIs and infrastructure can be scoped alongside the build as a separate written deliverable.
How we hand over
- Handover includes configuration, runbooks for upgrades and database backups, and documentation of the deployed architecture.
- Operators receive guidance on Synapse upgrade notes, including the warning that rolling back after schema changes can be difficult.
- Compliance evidence is prepared for your assessors; DeployOpen does not issue audit reports, attestations or certifications.
How we support
- Retainers cover upgrades, patching, monitoring follow-up and continuous testing after handover.
- Support scope is agreed in writing, so your team knows which upgrades and incidents are covered.
- Before any retainer, confirm your own staffing for on-call, key backup policy and Element Server Suite edition needs.
