Does self-hosting AWS Wickr cost less than paying for it?
Self-hosting replaces a per-user subscription with infrastructure, staff time and support, so it costs less only when your user count, retention needs and internal skills line up. If your renewal is driven by a per-seat increase or an add-on you rarely use, start by reading your current Wickr quote line by line. No per-user Wickr price is supplied here, so the figures that matter for your decision are the ones on your own order form and any add-ons it lists, such as retention or premium features. Compare those against the cost of running the stack yourself, not against a list price.
On the open-source side, the software itself is free to start. Element Server Suite Community is free under AGPL and includes Synapse and Element Call. Synapse is licensed under AGPL-3.0, and Element sells commercial licenses if your legal team cannot accept AGPL obligations. Element Server Suite Pro adds Synapse Pro, and the Sovereign edition targets air-gapped deployments. Check with Element which edition covers the features you need, such as support terms, and whether the AGPL position works for your organization before you budget. The recurring costs sit elsewhere: Kubernetes capacity, PostgreSQL, TURN servers, push notification setup, backups, and the engineers who patch and upgrade the platform. Ask any implementation partner for a quote that itemizes each of these components, who pays for each, and what recurs every year.
Your main cost drivers are the number of users, how long you must keep messages (retention is often the largest storage and compliance cost), the number of federated or bridged connections, and whether you already run Kubernetes and PostgreSQL skills in-house. Confirm these with your security and records teams before you compare totals, because retention requirements can change the answer on their own. Treat the comparison as a three-year total cost of ownership with an exit cost included, not a single annual number.
Which cost components move when you self-host Matrix and Element
This table sets the commercial Wickr side against the self-hosted Element and Synapse side, one cost component per row, and marks whether each item is one-time or recurring. Read it as a checklist for a quote: the license line is zero for the community stack, but most of the real cost sits in people, infrastructure and upgrades. Wickr pricing is not supplied here, so confirm plan and add-on fees with AWS before comparing totals.
| Cost component | Commercial side (Wickr) | Self-hosted side (Element and Synapse) | One-time or recurring |
|---|---|---|---|
| Software license | Per-user Wickr subscription plan, confirmed with AWS for your tier and region | Element Server Suite Community and Synapse carry no license fee under AGPL; Element Pro, Sovereign and commercial Synapse licenses are priced by quote | Recurring for Wickr; zero for the community stack unless you buy Element licenses |
| Compute and storage | Included in the service fee; no servers for you to size | Homeserver, worker and media hosts in your Kubernetes or VMs; media and database growth drives storage | Recurring |
| PostgreSQL | Not applicable | Synapse recommends PostgreSQL for production and requires version 14 or newer from release 1.143.0; you run backups, failover and upgrades | Setup one-time, operation recurring |
| Redis for workers | Not applicable | Needed when you scale Synapse with worker processes, since Redis relays replication between processes | Setup one-time, operation recurring |
| TURN servers | Calling is part of the Wickr service | You host TURN for calls behind NAT; bandwidth and the hosts are your cost, and Element Call setup should be confirmed in your environment | Recurring |
| Push notification setup | Mobile notifications handled by the vendor | Requires a push gateway and app registration for mobile clients; confirm the current requirements with Element before design | One-time setup, recurring upkeep |
| Implementation and identity | Admin time for tenant setup, groups and security settings | Engineering time for server_name, federation policy, delegation and SSO through OIDC, SAML2 or CAS | One-time |
| Data migration | Export and retention options depend on your Wickr configuration | Migration effort for rooms, users and retained data, with no fixed tooling assumed; scope it in writing | One-time |
| Support contract | Vendor support tied to your Wickr plan | Optional Element support or a DeployOpen retainer, priced from written scope | Recurring if chosen |
| Upgrades and patching | Vendor-managed releases | Your team tracks Synapse releases such as v1.163.0 and tests upgrades, since rollback can be hard after schema changes | Recurring |
| Internal skills and on-call | Admin console and vendor tickets | Staff who run Kubernetes, PostgreSQL, Redis, TURN and Matrix operations; ask whether this is new headcount or existing staff time | Recurring |
What pushes the self-hosted cost up or down
The self-hosted cost of Element does not scale with a per-seat price the way Wickr does. It scales with the infrastructure, the people operating it and the obligations you place on it. The six drivers below are the ones to size before you ask for a quote.
User count and growth
Infrastructure cost for a Matrix homeserver follows concurrent load, room count and federation traffic more than the headcount on a license sheet. Growth raises the size of the database, the number of worker processes and the bandwidth you pay for. Ask your team to model peak concurrent users and expected growth over your renewal term, and to confirm how the homeserver behaves under that load in a test environment before you commit to hardware.
Message and file retention
Retention is the cost driver most likely to surprise you. Keeping every message and file for years grows PostgreSQL storage and media storage, and it extends backup windows and restore times. Decide retention per room type before deployment, and check whether your records obligations require you to keep messages, which Wickr also handles through its own retention settings. Retention policy changes the database size you back up.
Edition choice across Community, Pro and Sovereign
Element Server Suite is sold as a free AGPL Community edition with Synapse and Element Call, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. Community carries no vendor fee but leaves support and commercial licensing to you or a partner. Pro and Sovereign add licensing and support costs that recur. Ask Element which features and support terms each edition includes for your deployment type.
Availability and federation needs
High availability means extra Synapse workers, a Redis instance for replication, and database replicas, each of which adds compute and an operator to watch it. Federation adds open ports, delegation records and a need to restrict which domains you talk to. Federation is optional: an empty federation_domain_whitelist disables it, which reduces exposure and operating work. Decide the availability target and whether you need federation before sizing hardware.
Identity integration through OIDC, SAML2 or CAS
Synapse supports single sign-on through OpenID Connect providers, SAML2 and CAS. Wiring an existing identity provider to these options is project work that recurs whenever you change the provider or add a federated realm. If your directory already runs as an OIDC or SAML provider, integration effort stays small. If you need a new identity service in front of Synapse, budget for it as an additional component with its own patching and backup.
Skills already on staff
Operating Synapse means running Python services, PostgreSQL, Redis, TURN servers and push notification setup, and applying upgrades that can require schema changes and rollback planning. Teams with these skills keep the recurring labor low. Teams without them pay for training, an external operator or a support retainer. Before you request a quote, ask who will apply upgrades, who is on call and how often you expect to patch.
Where self-hosted Synapse spend concentrates over time
Most of the money in a self-hosted Synapse deployment is not spent on the first install. It goes to keeping the homeserver current. The upgrade path is the largest recurring item. Synapse upgrade notes warn that rolling back can be difficult because database schema changes between releases may not reverse cleanly, so every upgrade needs a tested database backup, a staging run against a copy of production data, and a rehearsed restore. Someone must read each release's upgrade notes, plan the change window and own the decision to proceed. Ask your vendor or implementation partner to quote this as a standing task, not as a one-off cutover.
Runtime support is the second recurring driver. Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life. Synapse 1.142.0 and later require Python 3.10 or newer, and 1.143.0 and later require PostgreSQL 14 or newer. Each of these floors forces an operating system or database upgrade that can be larger than the Synapse upgrade itself, especially if PostgreSQL runs on a shared database host. Track the minimum versions named in the upgrade notes against your current hosts, and budget for the database upgrade as a separate change with its own testing.
Scaling and federation add ongoing configuration work. If you run Synapse with workers, the main process and every worker depend on Redis for replication, so Redis becomes another service to patch, monitor and capacity plan. Federation is the other recurring exposure. Synapse federates on port 8448 by default, and the docs recommend firewalling the federation listener in addition to restricting federation_domain_whitelist. Each firewall rule, delegation record and certificate renewal is small work, but it repeats for the life of the server. Confirm who on your team owns these items, how they are tested after each change, and whether the quote includes them as retainer work or as one-time setup.
How to build the comparison with your own numbers
This sequence turns a generic price comparison into a three-year cost model built from your user count, your retention rules and your own staff rates. Each step ends with a figure you can defend to finance and to the people who will run the platform.
Count active users and project growth
Start with the people who actually send messages each month, not the licensed headcount. Pull active-user counts from your identity provider or Wickr admin console, split them by business unit and external guest use, and record the growth rate your leadership has approved for the next three years. Done means you have one table with current active users, a conservative and a growth scenario, and a note on how many accounts are service or shared accounts. Confirm the counting rules with the vendor, because licensing often counts differently from activity.
Pull the current Wickr plan and add-on quote
Request a written quote from AWS or your AWS account team for the Wickr plan tier you use today, plus every add-on, such as data retention, compliance or additional capacity, and any GovCloud or WickrGov pricing that applies to you. Ask for the unit price, the billing term, any minimums and how price changes in later years. Done means you hold a dated quote, not a list price from a web page, and you can point to each line on it. Confirm that the quote reflects your region and account terms.
List retention and compliance requirements
Write down what you must keep, for how long, and who must be able to retrieve it. Include legal hold, e-discovery, regulator or records-management obligations, and whether messages, attachments and metadata each fall under them. This list decides how much storage, backup and administrative work the self-hosted side needs, and whether you need a compliance export path. Done means a signed-off requirements sheet owned by legal or compliance. Note that DeployOpen prepares controls and evidence for assessments but does not issue audit reports, so the requirements belong to your compliance function and any independent auditor.
Cost out the platform components
Price each component of the self-hosted stack separately: Kubernetes capacity or VMs, PostgreSQL (for production Synapse, the upstream documentation recommends PostgreSQL), Redis if you run workers, TURN servers for calls, reverse proxy and certificates, storage, backups, monitoring, and push notification setup for mobile clients. Use your cloud bill or your data center chargeback rates, and take sizing from Element's sizing guidance or a vendor-led sizing exercise. Done means each component has a monthly figure, a source and a note on whether it is one-time setup or recurring. Confirm each figure against your own invoices rather than published estimates.
Estimate admin and on-call hours
Estimate the hours your team will spend on patching, upgrades, database maintenance, certificate renewal, user lifecycle, incident response and on-call rota cover. Apply your own fully loaded staff rates, and separate build-time effort (initial deployment, SSO integration, migration) from run-time effort. Upgrades matter here: the Synapse upgrade notes warn that rolling back can be difficult because of schema changes, so plan for tested upgrade windows. Done means an hours-by-role table with a recurring annual figure and a one-time figure, each with the assumption behind it. Ask any implementation partner to quote this effort as a fixed scope, with deliverables written down.
Add an Element support or Pro quote if needed
If your requirements include commercial support, SLAs, Synapse Pro features, or the Sovereign edition for disconnected networks, request a written quote from Element for the edition you need. Element's public pricing shows a free Community edition, a Pro edition and a Sovereign edition, so confirm which features each includes and what support tier is attached. Done means you have a line item that is either a dated quote or an explicit decision that you will run the Community edition without a commercial contract. Record that decision and its risk in the model.
Run a three-year view by one-time and recurring cost
Build one spreadsheet with year one, year two and year three columns. Separate one-time costs (setup, integration, migration, initial hardware or licenses) from recurring costs (cloud or hosting, vendor licenses, support, staff time, backup storage). Run the Wickr side and the Element side with the same user numbers and the same growth scenario, and add a sensitivity row for user growth and for the cost of an unplanned upgrade. Done means both columns total to a three-year figure, every cell links to a source, and the owner of each assumption has signed it off. Share the model with finance before you compare the totals, so the discussion centers on assumptions.
How the comparison shifts by team profile
A small team without a single sign-on requirement usually pays most for its own time rather than for infrastructure. Element Server Suite Community, which includes Synapse under AGPL and Element Call, removes license fees, so the recurring cost is hosting, patching and the person who restarts the stack when something breaks. Illustrative example: a team of a few dozen people on one virtual machine still needs a reverse proxy, TLS certificates, backups of PostgreSQL and a TURN server for calls, and those items recur every month.
- Hosting footprint: A single node running Synapse with PostgreSQL is often enough at this size, so the infrastructure bill stays small.
- Calls and TURN: Voice and video need a TURN server and reachable ports, which adds firewall and network work even on a small deployment.
- Patch ownership: Someone must track Synapse releases and Python and PostgreSQL end-of-life dates, because Synapse drops support for versions past upstream end of life.
- Push notifications: Mobile alerts depend on push setup, which should be confirmed for your client builds and environment.
- Edition choice: Price the Community edition first, since Pro features such as Synapse Pro are unlikely to be needed without SSO or support requirements.
Before comparing totals, ask Wickr for the per-user plan that matches your head count and check the Element pricing page for the current Community terms.
An enterprise with identity provider integration and written retention rules shifts the cost toward integration and operations. Synapse supports OpenID Connect, SAML2 and CAS in its configuration, but wiring these to your identity provider, mapping attributes and testing account lifecycle usually takes more effort than the server itself. Retention policy also has to be designed, not switched on, because the requirements for keeping or deleting messages differ between departments.
- Identity integration: Expect work on oidc_providers or saml2_config, group mapping and deprovisioning tests, which are one-time costs that recur when identity changes.
- High availability: Production deployments often need PostgreSQL replication, Redis and worker processes, which raises both the build and the on-call load.
- Support contracts: Element Server Suite Pro with Synapse Pro, or a commercial agreement with Element, shifts some cost from staff time to a fixed subscription. Ask what support response and upgrade terms are included.
- Upgrade cadence: Rolling back Synapse can be difficult because of schema changes, so upgrade testing in a staging environment becomes a recurring line item.
- Retention engineering: Retained data sits on your storage and in backups, so storage growth and backup scope should be modeled.
Ask Element for the Pro edition scope in writing and ask your identity team to estimate integration effort before you compare totals.
A government or air-gapped operator usually cares less about license price and more about who can build, verify and update the software without internet access. Element Server Suite offers a Sovereign edition for air-gapped deployments, and the cost picture depends on how updates, vulnerability review and documentation get delivered into a disconnected network. Wickr's WickrGov in GovCloud and self-hosted options are priced differently, so the comparison should be built from your own accreditation path.
- Sovereign edition: Price the Sovereign edition as a separate line, since its terms for disconnected operation differ from the Community and Pro editions.
- Update path: Transferring signed packages across an air gap is a recurring process cost, including testing before each release reaches production.
- Accreditation evidence: Documentation, configuration baselines and test records are one-time work that must be kept current.
- Staffing: Cleared or specially authorized operators may cost more per hour, so staffing estimates should reflect clearance requirements.
- Federation and retention: Restricting federation through federation_domain_whitelist and firewalling the federation listener adds configuration and review work.
Confirm with Element which edition and support terms apply to your network class, and confirm the accreditation scope with your authorizing official before relying on any cost figure.
Questions buyers ask before comparing Wickr with self-hosted Element
How much effort does a self-hosted Element stack really need?
The effort is mostly in the components around the homeserver, not in the chat client itself. A production Synapse deployment needs PostgreSQL, which Synapse recommends for production, plus the reverse proxy, federation or delegation settings, TURN servers for calls, push notification setup for mobile devices, and backups. Synapse can scale with worker processes that rely on Redis for replication, so larger installations add that tier to patch and monitor. Ask any implementation partner to list each component, who installs it, and who patches it after go-live.
Can a small team run a Matrix homeserver on its own?
A small team can run a single Synapse instance on its own if it has someone comfortable with Linux, PostgreSQL and certificate management, and it can rely on SQLite for very small test setups. The harder part is the upgrade cadence. Synapse drops support for Python and PostgreSQL versions when they reach upstream end of life, and its upgrade notes warn that rolling back can be difficult because database schema changes between releases. Teams without a named owner for upgrades should plan for a support retainer or a documented on-call rota before go-live.
What skills and staff time does the self-hosted stack require?
The work splits across roles: platform engineers for Kubernetes or hosting, database administrators for PostgreSQL backups and version upgrades, network staff for TLS, DNS, federation ports and firewalls, and security staff for identity integration and access policy. Synapse supports OpenID Connect, SAML2 and CAS for single sign-on, so the identity team is also involved. Staff time recurs with each Synapse release, each PostgreSQL end-of-life date and each client update. Ask for a role-by-role estimate of ongoing hours rather than a single headcount figure.
How long does a Wickr to Element migration take?
The duration depends on user count, the number of rooms and security groups to recreate, how many devices each person uses, how single sign-on is wired, and whether Wickr retention data must be carried over. No migration duration has been fixed here, so ask the implementer to state one in the written scope with its assumptions listed. Running the two systems side by side during cutover usually adds time, and that period should appear as a separate line in the scope.
Do we need Element Server Suite Community or Pro?
Element Server Suite Community is free under AGPL and includes Synapse and Element Call, so it fits teams that accept AGPL obligations and can carry the operations work themselves. Element Server Suite Pro adds Synapse Pro, which is the path to the features and support that Element sells. Ask Element which capabilities differ between the two editions, including the features you need for compliance logging, identity federation and support response, and make sure the choice is written into the quote.
What does Element's AGPL licensing mean for commercial use?
Element moved future Synapse contributions from Apache 2.0 to AGPLv3, announced on November 6, 2023, and sells commercial licenses for organizations that cannot meet AGPL terms. Under AGPL, if you modify Synapse and offer it to users over a network, you may need to publish those modifications. Have counsel review how your internal changes, connectors and any customer-facing services fall under the license, and confirm with Element whether a commercial license is required for your use.
How should we handle Wickr retention data during the move?
Start by confirming whether retention was enabled in your Wickr network and what it covers, since only retained data can be carried into a new system. Decide which records must be kept for legal or records-management reasons, and where they will sit after migration. Matrix history does not import from Wickr automatically, so an archive or export approach may be needed. Confirm the export options with AWS and document the retention policy the self-hosted homeserver will enforce.
What should we ask for in a quote for this stack?
Ask for a written scope that lists every component: the Synapse and Element clients, PostgreSQL, TURN, push notifications, identity integration, backups, monitoring and documentation. Each line should show whether the cost is one-time (design, installation, migration) or recurring (hosting, licenses, upgrades, support). Request the assumed user count, retention settings, availability target and support hours, and confirm which items are excluded. DeployOpen works from a fixed written scope and does not publish prices, so the quote follows from that scope.
What Element's licensing means for your support budget
Synapse and Dendrite, Element's two Matrix server implementations, moved from Apache 2.0 to AGPLv3, and Element sells commercial licenses that replace the AGPL terms for organizations that need them. Element Server Suite is offered 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. Element's pricing is quote-based, so the line items that matter to your budget are not on the public page. Treat the Community edition as the cost floor for software, then price every step above it as a separate decision.
Before you compare numbers, ask Element in writing what each edition includes for support, patch cadence and security advisories, and how long your version stays supported. Ask whether Synapse Pro is a different code base or a commercial build of the same AGPL code, and which fixes reach each edition first. Ask who signs an AGPL exception, what it covers (modified versions, hosted use, internal use only), and whether it transfers if you change hosting. Confirm the support window for the Synapse release you plan to run, since Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, and upgrades can require newer database versions.
Next, have legal counsel check whether your use triggers AGPL obligations. The AGPL's network clause can require you to offer source code to users who interact with a modified version over a network, so an internal deployment with unmodified code, a deployment with patches, and a service offered to partners or customers can lead to different answers. Record your decision, because it determines whether you pay for an exception, carry patch obligations, or both. Your DeployOpen scope and the Element quote should reflect the same decision, so the budget does not change after legal review.
How DeployOpen scopes a fixed-price Element implementation
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Wickr-to-Element decision, we start with a written scope that separates Wickr spend from the Element components you would run, so the cost comparison rests on your own numbers.
How we scope
- Inventory current Wickr plans, add-ons, user counts and retention settings before any design work starts.
- Agree in writing which Element Server Suite edition, components and environments are in scope.
- Define who operates Kubernetes, PostgreSQL, TURN and push notifications after handover, and record it in the scope.
How we build
- Deploy Synapse with PostgreSQL, Redis workers, TURN and reverse proxy inside your own infrastructure.
- Configure server_name, federation settings and SSO through your identity provider, with federation limits set in writing.
- Test client sign-in, device enrollment, calling and push delivery against the agreed user profile before cutover.
How we hand over
- Document architecture, configuration, backup and restore procedures, and the upgrade path for each component.
- Provide runbooks for the Synapse upgrade notes, including database version requirements and rollback limits.
- Deliver evidence of controls and test results so your auditors can assess the system, although DeployOpen does not issue audit reports.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Ask for a quote built from the written scope, and confirm which costs your own staff will carry.
