Remote Patient Monitoring (RPM) is changing how care is delivered. By tracking health data through connected devices outside traditional settings, it helps clinicians act sooner, reduce readmissions, and focus resources where they’re most needed. With rising NHS pressures and growing demand for digital care, RPM is becoming central to how both public and private providers support long-term conditions, recovery, and hospital-at-home models. This guide explores how RPM works, where it’s gaining ground, and why healthcare leaders are paying attention.

What is Remote Patient Monitoring?

RPM refers to systems that collect patient data remotely using at-home or mobile devices, which clinicians then review. These systems can work in real time or at scheduled intervals and are often integrated with a patient’s electronic medical record (eMR) or practice management system (PAS). The goal is to monitor patients without needing in-person visits, while still keeping clinical oversight.

Devices Commonly Used in RPM

The success of any RPM programme depends on the devices that power it. These tools collect, track, and transmit key health data- either in real time or at regular intervals. Whether issued by clinicians or connected through a patient’s tech, they underpin the delivery of safe, responsive remote care.

These devices support the management of a wide range of conditions, including diabetes, heart disease, COPD, asthma, sleep disorders, high-risk pregnancies, and post-operative recovery.

Device Type	Primary Function
Blood pressure monitors	Measure systolic/diastolic pressure for hypertension monitoring
Glucometers	Track blood glucose levels for diabetes management
Pulse oximeters	Monitor oxygen saturation (SpO2) and heart rate
ECG monitors	Detect heart rhythm abnormalities such as arrhythmias
Smart inhalers	Track usage and technique for asthma or COPD
Wearable sensors	Monitor movement, sleep, temperature and heart rate
Smart scales	Measure weight trends, often linked to fluid retention or post-op care
Sleep apnoea monitors	Detect interrupted breathing patterns during sleep
Maternity tracking devices	Monitor fetal heart rate, maternal blood pressure, or contractions

These tools can either be prescribed by clinicians or integrated with consumer health tech like smartphones or smartwatches.

For example, a cardiologist may use a mobile ECG app paired with a sensor to track arrhythmias from home.

Safety and Regulation

The boundary between wellness wearables and clinical devices is still being defined. While some tools simply gather data, others have therapeutic applications, such as managing pain or respiratory issues. This matters for compliance. Devices that influence treatment decisions must meet higher regulatory standards, particularly around safety, accuracy, and data security. Developers and suppliers need to stay aligned with MHRA or equivalent guidance to avoid risk to both patients and business continuity.

How Remote Patient Monitoring Works

RPM follows a structured process:

1. Data collection from connected medical devices
   
2. Secure transmission to a clinical platform
   
3. Integration with existing systems
   
4. Analysis and alerting via algorithms or clinician review
   
5. Intervention where thresholds are breached
   
6. Feedback to patients through apps or direct communication

RPM Adoption is Accelerating

Globally, the uptake of RPM is increasing. In the US, patient usage rose from 23 million in 2020 to 30 million in 2024 and is forecast to reach over 70 million by the end of 2025 ( HealthArc ). The NHS is also scaling digital pathways. Over 100,000 patients have been supported by virtual wards in England , with NHS England increasing capacity to 50,000 patients per month by winter 2024. RPM is central to this shift.

Core Technologies in RPM

These technologies work behind the scenes to capture, transfer, and make sense of patient data, so that clinicians have timely, accurate insights to act on.

Wearables and sensors
Track vital signs like heart rate, oxygen levels, and movement patterns.

Mobile health apps
Used by patients to report symptoms, manage medications, and receive support.

Telemedicine platforms
Enable direct communication between patients and clinicians through chat, phone, or video.

Analytics engines
Help identify risk trends or changes in condition using automated flagging systems.

Why RPM Matters for Healthcare Leaders

The NHS is under sustained pressure. According to the NHS Confederation , over 7.6 million people are currently on elective care waiting lists, while ambulance delays and A&E overcrowding persist. RPM supports care outside the hospital by freeing up beds, reducing readmissions, and improving patient flow. At a system level, RPM:

• Cuts avoidable admissions
  
• Shortens hospital stays
  
• Reduces time-to-intervention
  
• Frees up staff capacity
  
• Lowers infection risk
  

Cost savings are also significant. Some estimates suggest RPM can reduce total healthcare expenditure by 20–40%, particularly for chronic conditions.

RPM in Action: Key Use Cases

The real impact of RPM is seen in the way it supports different stages of the care journey. Here are some of the most common and most effective use cases.

Chronic Disease Management

RPM allows patients with diabetes, COPD, or hypertension to track metrics like blood pressure, oxygen levels or glucose and share results with care teams. Interventions can be made earlier, reducing the chance of deterioration or escalation.

Mental Health Monitoring

Wearables can capture signs of stress or low mood by tracking heart rate variability, sleep patterns, and daily activity. RPM helps clinicians spot early signs of relapse in conditions like anxiety and depression, particularly when patients are less likely to reach out themselves.

Post-Operative Recovery

Patients recovering from surgery can be monitored for wound healing, temperature spikes, or pain trends. A 2023 BMC Health Services Research study showed RPM helped reduce six-month mortality rates in patients discharged after heart failure or COPD treatment.

Elderly Care

For older adults, RPM supports safety without constant in-person contact. Devices with fall detection, medication reminders, and routine tracking can help carers respond quickly to changes, reducing emergency visits and supporting independent living.

Clinical Trials

RPM speeds up trials by reducing the need for travel, offering more continuous data, and improving patient adherence.

Pandemic and Emergency Response

During COVID-19, RPM enabled safe monitoring of symptoms like oxygen saturation or fever, supporting triage and resource allocation when systems were overwhelmed.

Benefits Across the System

RPM not only benefit patients, but it also improves outcomes and operations across every part of the health and care system. Here’s how you can gain from its use.

	Key Benefits
Patients	Greater independence, faster recovery, fewer hospital visits
Clinicians	Real-time data visibility, increased capacity, and better focus on complex cases
Carers	Peace of mind, early alerts, and less reliance on manual checks
ICBs & Providers	Lower readmissions, improved resource use, and more coordinated care

Where Tech Comes In

Behind every reliable RPM system is a reliable tech stack. In high-risk, high-volume environments like healthcare, platforms need to be built for stability, security and scalability.

That’s why some platforms use programming languages such as Erlang and Elixir, trusted across the healthcare sector for their ability to manage high volumes and maintain uptime. These technologies are being adopted in healthcare systems that prioritise performance, security, and scalability.

When built correctly, RPM infrastructure allows providers to:

• Maintain continuous monitoring across patient groups
  
• Respond quickly to emerging clinical risks
  
• Scale services confidently as demand increases
  
• Minimise risk from tech failure or data breach

To conclude

Patients recover better when they’re in a familiar place, supported by the right tools and professionals. Hospitals function best when their time and space are reserved for those who truly need them. Remote Patient Monitoring is not just a digital upgrade. It’s a strategic shift, towards smarter, more responsive care.

Ready to explore how RPM could support your digital care strategy? Get in touch .

The post What is Remote Patient Monitoring? appeared first on Erlang Solutions .

Release Highlights:

This release focus on integration in a wider federated network, with support for spam fighting features, better compliance with Matrix network and native support for PubSub Server Information to have your server count as part of the wider XMPP network (for example, you can register your server on XMPP Network Graph .

• Spam filter with block lists support
• Support for XEP-0485: PubSub Server Information
• Support for older Matrix rooms in ejabberd XMPP <-> Matrix Gateway

If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

Other contents:

• Workaround for zip module in unpatched Erlang
• Erlang/OTP 28 supported
• Erlang/OTP 25 required
• New mod_antispam with RTBL support
• New mod_pubsub_serverinfo
• Improvements in Matrix gateway
• XEP-0431: Full Text Search in MAM
• New rest_proxy options
• New auth_password_types_hidden_in_scram1 option
• New host_alias option
• New predefined keywords
• Link to Converse in WebAdmin
• Updates in source code formatting
• New target test-group
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.07 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

Workaround for zip module in unpatched Erlang

A vulnerability was published three weeks ago that affects the zip library included in Erlang/OTP: CVE-2025-4748: Absolute path in zip module .

The ejabberd installers and the ejabberd container image already use a patched version Erlang/OTP 27.3.4.1, but the ecs container image uses Erlang/OTP 26.2.

ejabberd 25.07 includes a specific protection that workarounds that vulnerability regardless of what Erlang/OTP version you are using.

Erlang/OTP 28 supported

Updating ejabberd to support Erlang/OTP 28 has required quite some work due to the replacement of ancient ASN.1 modules from Erlang/OTP public_key library.

Improvements were done on ejabberd, fast_xml , p1_acme , xmpp libraries, and also rebar / rebar3 binaries were recompiled.

However, there is still one last problem not yet solved which implies that ACME support is broken when using Erlang/OTP 28.0.1. The fix will probably be included in the next Erlang/OTP 28 release.

Erlang/OTP 25 required

The minimum Erlang/OTP version supported since now is 25.0.

However, we are aware there are still a few specific cases where older Erlang/OTP versions are being used. For that reason, the source code support for those versions is still available, and static source code analysis tools like xref and dialyzer are still run with Erlang/OTP 20 in runtime.yml .

If you really need to use ejabberd with Erlang/OTP 20 - 24, you can bypass the version check during compilation with this ./configure option: ./configure --with-min-erlang=9.0.5

New mod_antispam with RTBL support

mod_antispam is a new module that filters spam messages and subscription requests received from remote servers based on Real-Time Block Lists (RTBL) , text lists of known spammer JIDs and/or URLs mentioned in spam messages.

This module is based in mod_spam_filter which was originally published in ejabberd-contrib . If you were using that module, you can update your configuration and start using mod_antispam instead.

New mod_pubsub_serverinfo

mod_pubsub_serverinfo adds support for XEP-0485: PubSub Server Information to expose S2S information over the Pub/Sub service.

This module was originally published in ejabberd-contrib . If you were using that module, you can remove it, as now it&aposs included in ejabberd.

Improvements in Matrix gateway

While we are preparing another big update for the Matrix gateway. The most important change is that we added support to a larger number of room versions. It allows users to let them join a lot of rooms that were already created a while back and running an older version of the room protocol.

Here is the main list of changes to the matrix gateway:

• mod_matrix_gw : Support older Matrix rooms versions starting from version 4
• mod_matrix_gw : Don&apost send empty messages in Matrix rooms (#4385)
• mod_matrix_gw : Fix key validation in mod_matrix_gw_s2s:check_signature
• mod_matrix_gw : When encoding JSON, handle term that is key-value list (#4379)

XEP-0431: Full Text Search in MAM

Support for XEP-0431: Full Text Search in MAM has been added. For now, it only works if mod_mam is using the MySQL storage backend.

New rest_proxy options

With those new options you can make modules using rest.erl module (like ejabberd_oauth_rest ) use HTTP proxy when performing HTTP requests.

The related new top level options are:

• rest_proxy : Address of a HTTP Connect proxy
• rest_proxy_port : Port of a HTTP Connect proxy
• rest_proxy_username : Username used to authenticate to HTTP Connect proxy (optional)
• rest_proxy_password : Password used to authenticate to HTTP Connect proxy (optional)

New auth_password_types_hidden_in_scram1 option

This option was added to help with adding new password types in auth_stored_password_types option to existing installations. Adding new password type made server advertise it to clients, but that caused problems for users that didn&apost have new password type stored, and which clients used SASL1 authentication, if client tried to authenticate with it, authentications would fail.

With this new option, server admin can choose which password types should not be presented to SASL1 clients (they still will be offered to SASL2 clients for users that have password compatible with this type), to later after users update password to have new type, being able to enable them.

This option takes list of password types from auth_stored_password_types that should be disabled

auth_password_types_hidden_in_scram1:
  - scram_sha512
  - scram_sha256

New hosts_alias option

The new hosts_alias toplevel option is used by the ejabberd_http listener to resolve domain names into vhosts served by ejabberd.

For example, ejabberd is serving the vhost redacted.lan , but you configured DNS so xmpp.redacted.lan resolves to that host. If you configure in ejabberd:

hosts:
  - redacted.lan

hosts_alias:
  xmpp.redacted.lan: redacted.lan

listen:
  -
    port: 443
    ip: "::"
    tls: true
    module: ejabberd_http
    request_handlers:
      "/bosh": mod_bosh
      "/ws": ejabberd_http_ws
      "/conversejs": mod_conversejs

modules:
  mod_bosh:
  mod_conversejs:
    bosh_service_url: "https://xmpp.redacted.lan/bosh"
    websocket_url: "wss://xmpp.redacted.lan/ws"

then ejabberd_http will accept https://xmpp.redacted.lan/conversejs and deliver it to vhost redacted.lan

In previous ejabberd releases, an option called default_host was documented for the ejabberd_http listener, but it didn&apost work at all correctly.

New predefined keywords

A few months ago, ejabberd 25.03 introduced new predefined keywords like HOST , HOME , VERSION and SEMVER .

And now two more predefined keywords are added:

• CONFIG_PATH : Path to the configuration directory, for example "/home/ejabberd/opt/ejabberd/conf"
• LOG_PATH : Path to the log directory, for example "/home/ejabberd/opt/ejabberd/logs"

Those keywords are specially useful when configuring mod_antispam : you can copy text files to the configuration directory where the module will read them, and also configure the module to write the dump file on the log directory.

Link to Converse in WebAdmin

mod_conversejs has a new tiny improvement: it adds a link in the WebAdmin menu to the local Converse instance.

Additionally, when HTTPS with encryption is enabled, that link logins directly with the account used in WebAdmin.

Updates in source code formatting

A year ago, ejabberd 24.06 introduced make format and make indent .

Now that script uses Perl to work correctly in Mac OS too.

And there&aposs a new section in the documentation, see Format that describes how to use that feature, and tips for Git hooks and Git alias.

New target test-group

ejabberd includes a Common Test suite with 1456 test cases, which typically takes around 10 minutes to run.

When developing new source code, you may want to run only tests from a specific group and a specific storage backend, as documented in the ejabberd testing documentation :

CT_BACKENDS=mnesia rebar3 ct --suite=test/ejabberd_SUITE --group=antispam_single

To facilitate this usage, a new target is available:

CT_BACKENDS=mnesia make test-antispam_single

Acknowledgments

We would like to thank the contributions to the source code, documentation, and translation provided for this release by:

• Stefan Strigler and Holger Weiß for mod_antispam and the original mod_spam_filter
• Stefan Strigler for mod_pubsub_serverinfo and test-group target
• Bruno MATEU for the missing comma in postgres schema
• GiannosOB updated the Greek translation
• Tamil Neram updated the Tamil translation
• Максим Горпиніч updated the Ukrainian translation

And also to all the people contributing in the ejabberd chatroom, issue tracker...

Improvements in ejabberd Business Edition

Customers of the ejabberd Business Edition , in addition to all those improvements and bugfixes, also get the following changes.

Monitoring

The following new metrics has been added to mod_mon :

• message_receive_packet : number of message stanzas of any type received by the server on c2s connections
• message_send_packet : number of message stanzas of any type send by the server on c2s connections
• iq_receive_packet : number of IQ stanzas received by the server on c2s connections
• iq_send_packet : number of IQ stanzas send by the server on c2s connections
• iq_get_receive_packet : number of IQ stanzas of type get received by the server on c2s connections
• iq_set_receive_packet : number of IQ stanzas of type set received by the server on c2s connections
• iq_result_receive_packet : number of IQ stanzas of type result received by the server on c2s connections
• iq_error_receive_packet : number of IQ stanzas of type error received by the server on c2s connections
• iq_get_send_packet : number of IQ stanzas of type get send by the server on c2s connections
• iq_set_send_packet : number of IQ stanzas of type set send by the server on c2s connections
• iq_result_send_packet : number of IQ stanzas of type result send by the server on c2s connections
• iq_error_send_packet : number of IQ stanzas of type error send by the server on c2s connections

The metrics c2s_receive & c2s_send now count all stanzas on c2s connections.

The cpu_usage probe now gives more reliable values.

Prometheus support has been improved.

A new mod_mon_dump command has been added to dump probe values to help debug the monitoring setup.

Mobile push

It is now possible to use rest_proxy* options to use a HTTP proxy for mod_applepush & mod_gcm outgoing calls.

ChangeLog

This is a more complete list of changes in this ejabberd release:

Security fix

• ext_mod : Add temporary workaround for zip including absolute path

Compilation

• Raise the minimum Elixir tested version to 1.14.0 ( #4281 )
• Raise Erlang/OTP minimum requirement to 25.0 ( #4281 )
• configure.ac : Allow to specify minimal erlang version using --with-min-erlang
• Makefile.in : Add target test-<group>
• rebar3-format.sh : Replace csplit with perl
• Container: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4
• Installers: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4, libexpat 2.7.1, OpenSSL 3.5.1

Configuration and Tests

• Add rest_proxy* options to configure proxy used by rest module
• ejabberd_c2s : Add auth_password_types_hidden_in_scram1 option
• ejabberd_http : Remove unused default_host option and state element
• ejabberd_http : New option hosts_alias and function resolve_host_alias/1 ( #4400 )
• New predefined keywords: CONFIG_PATH and LOG_PATH
• Fix macro used in string options when defined in env var
• Use auxiliary function to get $HOME , use Mnesia directory when not set ( #4402 )
• ejabberd_config : Better lists:uniq substitute
• Tests: update readme and compose to work with current sw versions
• Update Elvis to 4.1.1, fix some warnings and enable their tests

Erlang/OTP 28 support

• Add workaround in p1_acme for Jose 1.11.10 not supporting OTP 28 ecPrivkeyVer1 ( #4393 )
• Bump fast_xml and xmpp for improved Erlang/OTP 28 support
• Bump xmpp and p1_acme patched with Erlang/OTP 28 support
• Fix make options in Erlang/OTP 28 ( #4352 )
• Fix crash in rebar3 cover with Erlang/OTP 28 ( #4353 )
• Rebar/Rebar3: Update binaries to work with Erlang/OTP 25-28 ( #4354 )
• CI and Runtime: Add Erlang/OTP 28 to the versions matrix

SQL

• Fix mnesia to sql exporter after changes to auth tables
• Update code for switching to new schema type to users table changes
• Add mssql specific implementation of delete_old_mam_messages
• Make delete_old_mam_messages_batch work with sqlite
• ejabberd_sm_sql : Use misc:encode_pid/1
• mysql.sql : Fix typo in commit 7862c6a when creating users table
• pg.sql : Fix missing comma in postgres schema ( #4409 )

Core and Modules

• ejabberd_s2s_in : Allow S2S connections to accept client certificates that have only server purpose ( #4392 )
• ext_mod : Recommend to write README.md instead txt (processone/ejabberd-contrib#363)
• ext_mod : Support library path installed from Debian (processone/ejabberd-contrib#363)
• ext_mod : When upgrading module, clean also the compiled directories
• gen_mod : Add support to prepare module stopping before actually stopping any module
• mod_antispam : Imported from ejabberd-contrib and improved ( #4373 )
• mod_auth_fast : Clear tokens on kick, change pass and unregister ( #4397 )( #4398 )( #4399 )
• mod_conversejs : Add link in WebAdmin to local Converse if configured
• mod_mam : Present mam full text search in xep-431 compatible way
• mod_mam_mnesia : Handle objects that don&apost need conversion in transform/0
• mod_matrix_gw : Don&apost send empty messages in Matrix rooms ( #4385 )
• mod_matrix_gw : Support older Matrix rooms versions starting from version 4
• mod_matrix_gw : When encoding JSON, handle term that is key-value list ( #4379 )
• mod_matrix_gw_s2s : Fix key validation in check_signature
• mod_mix and mod_muc_rtbl : Support list of IDs in pubsub-items-retract (processone/xmpp#100)
• mod_pubsub_serverinfo : Imported module from ejabberd-contrib ( #4408 )
• mod_register : Normalize username when determining if user want to change pass
• mod_register : Strip query data when returning errors
• WebAdmin: New hooks webadmin_menu_system to add items to system menu

Full Changelog

https://github.com/processone/ejabberd/compare/25.04...25.07

ejabberd 25.07 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub .

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity .

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags .

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs . The alternative ejabberd container image is available in ghcr.io/processone/ejabberd .

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues .

In today’s interconnected world, digital sovereignty has become increasingly important for individuals and organizations seeking to maintain control over their data, infrastructure, and technologies. Openfire, an open-source, real-time collaboration (RTC) server that uses the XMPP (Extensible Messaging and Presence Protocol) protocol, offers a secure and customizable communication platform.

About Openfire

Openfire, produced by the IgniteRealtime community , is a mature, robust and scalable XMPP server that facilitates real-time communication and collaboration. It supports a wide range of features, including instant messaging, group chat, voice and video calls, and file sharing. Openfire’s open-source nature and extensive plugin architecture make it a versatile and customizable solution for organizations of all sizes. Openfire’s compatibility with various XMPP clients, including but not limited to IgniteRealtime’s own Pádè and Spark clients, further enhances its versatility and utility.

Data Privacy and Security

One of the key aspects of digital sovereignty is the ability to protect sensitive information and ensure data privacy. Openfire provides a secure communication platform that supports end-to-end encryption, secure authentication, and fine-grained access control. By hosting Openfire in-house or on a private cloud, organizations can maintain control over their communication data and reduce the risk of data breaches or unauthorized access. Additionally, Openfire’s open-source nature allows users to audit the code and verify the security of the platform, further enhancing trust and transparency.

Customization and Flexibility

Openfire offers a high degree of customization and flexibility, enabling organizations to tailor the platform to their specific needs and requirements. With a wide range of plugins and extensions, Openfire can be easily integrated with existing systems and workflows, allowing users to create a communication environment that aligns with their unique processes and preferences. This enables organizations to maintain control over their communication tools and adapt them to their evolving needs.

Compliance and Regulatory Control

Openfire’s customizable and secure nature makes it an ideal platform for organizations operating in regulated industries or jurisdictions with strict data protection laws. By hosting Openfire in-house or on a private cloud, organizations can ensure that their communication data remains within their control and complies with relevant regulations. Furthermore, Openfire’s extensive logging and monitoring capabilities enable users to demonstrate compliance and maintain a clear audit trail of their communication activities.

Interoperability with Other XMPP Solutions

Openfire’s interoperability with other XMPP-based platforms and clients is another significant advantage. By supporting the XMPP protocol, Openfire enables seamless communication and collaboration with users on other XMPP servers and clients, fostering a decentralized and open communication ecosystem. This interoperability allows organizations to maintain control over their communication infrastructure while still being able to connect and collaborate with external partners, customers, or stakeholders. Moreover, Openfire’s compatibility with other XMPP solutions reduces the risk of vendor lock-in and promotes a more open and competitive market for communication tools.

Conclusion

Openfire offers a powerful and secure communication platform that supports digital sovereignty by enabling organizations to maintain control over their data, infrastructure, and technologies. With its robust security features, customization capabilities, compliance-friendly nature, and interoperability with other XMPP solutions like Pádè and Spark, Openfire empowers users to create a communication environment that aligns with their unique needs and requirements. As digital sovereignty continues to gain importance in today’s interconnected world, Openfire provides a valuable solution for organizations seeking to enhance their autonomy, privacy, and security in digital interactions.

---

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

Openfire 5.0.1 has been released!

Openfire, created by the Ignite Realtime community is a powerful chat server that lets you communicate in real-time with your team or friends. It’s like having your own private messaging solution, but with more control and customization options.

Following the release of Openfire 5.0.0 last week, a few annoying issues were reported. These are addressed in this new release:

• The Windows Launcher works again
• The bundled ‘search’ plugin is updated to address an issue in the admin console
• Certificate-based authentication can be used again with client connections
• Improvements were applied to the detection of invalid (‘ghost’) group chat users that originate from federated domains.
• The Admin Console translations for the French and Dutch languages got a significant update. Many thanks to the community members that provided those translations!

This update should be a drop-in replacement for version 5.0.0. You can find the installers in the usual places, like our Downloads page !

The 5.0.1 release of Openfire is a direct result of receiving contributions and feedback from the community. Keep it coming! As you can see, your effort, no matter how big or small, can have a direct result! Please join our community forum or group chat and let us know what you think!

Finally: GitHub appears to claim that this is our 100th release of Openfire/Wildfire. We’re not at all sure that’s an accurate count, but we’ll take the opportunity to celebrate anyway! Come join the celebrations in our chatroom ! The fiftieth person to join wins a no-expenses-paid day trip to the nearest park bench!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

Say hello to Márton Veres, our new Business Unit Leader for London.
From international consulting to leading delivery teams, Márton’s journey to this role has been anything but ordinary. In our latest team interview, he shares what excites him most about this next chapter, his vision for growing our presence in London, and a personal challenge he’s set for the summer.

Get to know Márton and his take on leadership, community, and what’s ahead.

Congratulations on your new role as Business Unit Leader (BuL) for London. Could you share more about your new role at Erlang Solutions?

Thanks! I’m proud to take on the BuL role after four years in project and delivery management here. I’ll be leading the London team, shaping and executing our business strategy, and driving growth through client relationships and new opportunities.

I’m looking forward to working more closely with our UK colleagues, connecting with the Erlang and Elixir communities, and strengthening our presence in the London market.

What have been some highlights of your career so far?

My journey has always been at the intersection of business and technology. I spent my first eight years as an IT consultant in FinTech and Telco, helping align business needs with tech solutions. Then, I led project management teams at Deutsche Telekom for eight years, gaining deep experience in large-scale delivery.

At Erlang Solutions, I’ve worked alongside brilliant engineers on cutting-edge Erlang and Elixir projects. The mix of consulting, corporate, and agile tech environments has given me a well-rounded perspective that I bring into this new role.

What are you most looking forward to in your new position?

I’m especially excited to deepen our work in London’s FinTech, Digital Health, and Energy sectors. I’m passionate about supporting and growing our team using servant leadership and business coaching skills I’ve developed, including through a recent certification programme supported by Erlang Solutions.

Digital Health is a particular interest of mine, and I’d love to expand on the work we’ve done with the NHS, HCA Healthcare, and Baxter. Being part of the Trifork Group also opens up opportunities to collaborate on end-to-end solutions, especially with their Digital Health expertise.

Outside of work, what are you most excited about this summer in London?

I’m training for the Wimbledon Half Marathon in September. My goal is to finish in under two hours! It’s a great way to stay focused and make the most of the summer. Balancing work and personal goals like this keeps me energised.

Final thoughts

It’s been a pleasure catching up with Márton and hearing about his journey, leadership vision, and what’s ahead for the London team. His story is a great reminder of the passion and purpose that drive our work at Erlang Solutions.

We’ll be sharing more team stories soon. So keep an eye out for the people behind the projects. If you’d like to connect with Márton or anyone on our team, we’d love to hear from you.

The post Meet the Team: Márton Veres appeared first on Erlang Solutions .

We are thrilled to announce the release of Openfire 5.0.0, the latest version of our popular open-source XMPP (Extensible Messaging and Presence Protocol) server. This release marks a significant milestone in our journey to provide a robust, scalable, and secure platform for real-time communication.

Openfire 5.0.0 comes packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. Here are some of the key highlights:

1. Enhanced Security: We’ve made significant improvements to Openfire’s security infrastructure. These include the restoration and improvement of Certificate Revocation support, implementation of XEP-0421 for anonymous unique occupant identifiers in MUCs and updating Jetty’s embedded webserver for enhanced stability.
2. Improved Performance: Openfire 5.0.0 is designed to handle larger loads more efficiently. We’ve optimized the server’s performance to ensure it can scale to meet the needs of your growing user base. Performance improvements include updating our network interaction layer with a recent version of Netty, optimizing database queries, and reducing duplicate code in multi-providers, resulting in a more efficient and responsive system.
3. Plugin Updates: We’ve updated several of our core plugins to ensure they’re compatible with Openfire 5.0.0. This includes updates to our monitoring, clustering, and web-based chat client plugins.
4. Bug Fixes and Improvements: We’ve squashed numerous bugs and added various features in this release, improving the overall functionality, stability and reliability of Openfire. Translations have been updated (and now include Turkish, Swedish and Italian), new group chat management features have been added, and parallelism when working with many federated domains has been improved, to name a few.
5. Updated Java Requirement: Openfire requires Java 17 (or newer) to be installed.

Our deepest thanks go to NLnet Foundation for their invaluable support. With their funding and encouragement, we successfully implemented full IPv6 support and completed a robust security audit by Radically Open Security. NLNet’s mission to strengthen open and trustworthy internet infrastructure continues to make a real difference!

The changelog lists all of the changes that have been made.

We’re incredibly excited about this release and we can’t wait to see what you’ll build with Openfire 5.0.0. Whether you’re a developer looking to build a new real-time application, or an organization looking to improve your communication infrastructure, Openfire 5.0.0 has something for you.

As always, Openfire is free and open-source, so you can download it, use it, and modify it to suit your needs. We believe in the power of open-source software to drive innovation and we’re committed to continuing to support and develop Openfire.

Thank you to everyone who has contributed to this release, whether by submitting code, reporting bugs, or providing feedback. Your contributions are invaluable and we couldn’t do this without you.

You can download Openfire 5.0.0 from our website and check out our documentation to get started. We’ve also updated our community forums where you can ask questions, share ideas, and connect with other Openfire users.

Here’s to the future of real-time communication with Openfire 5.0.0!

For other release announcements and news follow us on Mastodon or X

2 posts - 2 participants

Read full topic

It is exciting to be able to announce the immediate availability of the beta release of Openfire 5.0.0!

In this release, we have addressed approximately 125 issues! I’ll reserve the details for a blog post on the 5.0.0 (non-beta) release, but some of the important changes are:

• We’ve dropped support for Java 11. The minimum requirement is Java 17 now
• The embedded web server has received a major upgrade
• Various security-related updates were applied, including library updates and code changes that resulted from an independent security audit (more on that later!)

This beta release (and some of its precursors) have been extensively tested by the developers and other members of the Ignite Realtime community. At this stage, we’re not seeing any critical issues. However, prior to cutting the full release, we prefer to have more feedback. That is where you come in!

We are looking for your help!

Please help us test this release! If you host your own instance of Openfire, please consider upgrading it to the new beta release. If you can’t, or if you’re not running Openfire but another brand of XMPP server, please do some interoperability testing with the server at igniterealtime.org .

Are you a client developer? Please see how your application behaves, when connecting to the beta (we can make available accounts for testing to help you do this).

If you’re nothing of a tech-head but can use an XMPP client, try to interact with our domain (for example, join our chatroom at open_chat@conference.igniterealtime.org ) to see if there are any issues.

You can obtain the beta from our download page for beta releases or from the GitHub Releases page .

We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat . We are always looking for volunteers interested in helping out with Openfire development!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

When you’re moving quickly in a startup, taking shortcuts in your tech stack is tempting. A quick workaround here, a temporary fix there, with plans to tidy it all up later. But later can easily turn into never.

Those early decisions, however small they seem, have a habit of sticking around. Over time, they slow you down, create technical debt, and make it harder to scale.

This blog looks at how to avoid common startup tech mistakes by making smarter choices early on. You don’t need to build the perfect system from day one, but you do need to build something you won’t regret.

The risks of rushing your tech stack decisions

Your tech stack is the foundation of your product. Making quick choices to just keep things often comes with hidden costs.

Common examples of early tech shortcuts

• Choosing tools based on ease rather than long-term fit
• Using third-party services without proper integration planning
  
• Avoiding proper system design to save time
  
• Stacking too many frameworks or libraries to plug gaps quickly
  
• Skipping documentation, testing, or version control in the name of speed
  

What could go wrong?

Here are some of the common risks that come with rushing tech stack choices:

Risk	Impact
Technical debt	Every short-term choice adds friction later. Over time, progress slows as the team spends more time managing issues than delivering value.
Security gaps	Fast fixes can lead to poorly secured systems, especially when sensitive data is involved or best practices are skipped.
Fragile foundations	A patchwork stack becomes hard to maintain, debug, or scale, and onboarding new developers becomes a headache.
Scaling problems	Systems built for “now” can’t always support growth. Quick fixes often ignore load handling, resulting in slowdowns or breakdowns at scale.
Innovation slowdown	When all your energy goes into fixing past decisions, there’s little room left for building what’s next.

The business cost of technical shortcuts

They directly impact a startup’s ability to grow. From wasted dev time to lost customer trust, the cost of early shortcuts adds up fast. That’s not the kind of overhead most startups can afford.

The long-term cost of technical debt

We touched on technical debt earlier as one of the key risks of rushing early tech decisions. Now let’s look at it more closely, because for many startups, it’s the most persistent and costly issue that comes from cutting corners.

Technical debt is the build-up of compromises made during development, from skipping tests and rushing features to patching bugs without addressing their root cause. These short-term choices eventually slow everything down, making it harder and more expensive to move forward.

Let’s break down the long-term impact:

The hidden costs of technical debt

Consequence	What it means
Slower development	Developers spend more time fixing old issues than building new features, reducing overall velocity.
More bugs, more fire-fighting	Poorly maintained code leads to more frequent and severe bugs, increasing customer support and downtime.
Low team morale	Constantly dealing with messy code creates frustration and burnout, which can hurt retention.
Harder to scale	As the product grows, tech debt makes it harder to add new features or pivot without causing breakages.
Security risks	Outdated code or rushed fixes often introduce vulnerabilities that can be exploited later.
Increased costs	Fixing problems later is far more expensive, both in time and budget.

A Stripe report found developers spend up to 42% of their week handling technical debt. CIO research suggests 20–40% of IT budgets are spent addressing it.

When it gets out of control

Technical debt can halt progress entirely. We’ve seen startups and scale-ups locked into outdated or fragmented systems, where maintaining or updating anything becomes nearly impossible.

Here are a few real-world scenarios:

• Legacy overload : Systems running well past their intended lifespan, no longer supported or secure.
  
• Integration failure : Poorly connected tools and services that don’t talk to each other, slowing everything down.
  
• Scaling bottlenecks : Infrastructure so rigid that every new feature or user pushes it closer to breaking point.
  

Security crises : Outdated code with known vulnerabilities, eventually forcing a full rebuild after a breach.

What startups can do about it:

You can’t avoid technical debt entirely, but you can manage it by:

• Prioritising clean, maintainable code from day one
  
• Setting time aside for refactoring and testing
  
• Regularly reviewing architecture decisions
  
• Choosing tools that support long-term scalability, not just quick wins
  

Startups that manage technical debt proactively stay more adaptable, secure, and focused on building the future.

Why scalability matters from day one

Tech built in a rush might work for an MVP (minimum viable product), but without scalability and maintainability in mind, it becomes a liability, something we cover in more detail in our post on common MVP mistakes.

60% of startups face major scalability issues within their first three years (McKinsey) . These problems aren’t just technical; they slow growth, frustrate users, and drain time and resources.

Here’s why it’s critical to get it right from the start:

1. Scaling later is harder and more expensive

Retrofitting scalability into an existing product or tech is rarely clean. The cost (in both time and money) often outweighs what it would’ve taken to plan it earlier.

2. Maintainable code accelerates growth

Clean, modular code helps teams ship faster, fix bugs quicker, and onboard new engineers smoothly. Poor code slows everything down.

3. Users don’t tolerate failure

Unscalable systems break under pressure, which is exactly when users start showing up. That erodes trust, kills momentum, and makes customer retention harder.

4. Bad tech choices can limit your future

Tech that isn’t built to adapt can lock you into tools, vendors, or architectures that no longer serve your goals. That makes pivots and product evolution harder.

Early-stage teams often defer these decisions to “later.” But in startups, later usually means too late . Thoughtful, scalable, and maintainable tech choices aren’t a luxury but a growth strategy.

Doing it Right from the start: In practice

Now that we understand why scalable and maintainable tech decisions are crucial early on, here are some practical strategies to help your startup avoid quick fixes and build a strong foundation.

1. Prioritise Root Cause

Don’t just patch, find and fix the real problem. For example, optimise slow database queries instead of repeatedly fixing slow responses.

2. Adopt Agile

Work in short cycles and use user feedback. Many fintech startups rely on agile to adapt quickly.

3. Write Clean, Modular Code

Keep code simple and flexible. Use modular design to evolve without costly rewrites.

4. Test Early

Use automated tests early to catch bugs. Improve stability by prioritising testing from the start.

5. Review Regularly

Hold frequent code and architecture reviews. Startups BoardClic and Metaito used expert code and architecture reviews to ensure scalable, robust platforms.

6. Choose the Right Tech

Pick tools that fit your goals and skills. Many startups use scalable, developer-friendly stacks like Elixir.

7. Document Clearly

Keep documentation up to date to help teams understand decisions and onboard new members fast.

8. Don’t skip security checks

It’s easier to fix security issues early than patch things up later. Audits, such as SAFE (Security Audit for Erlang and Elixir) , helped startups like Koll and Twine ensure the security of their systems early on, making it easier to scale with confidence and avoid nasty surprises.

Starting with these habits cuts costly fixes later and sets your startup up for lasting growth.

Balancing speed and quality without overengineering

Startups must deliver quickly but avoid building overly complex solutions too soon. The key is focusing on essential features that address real user needs, while keeping the system flexible enough to adapt later. This helps avoid wasted effort on premature optimisation or unnecessary features.

For more on this, check out our post: Common MVP mistakes: How to build smart without overbuilding .

Build now, avoid startup tech mistakes later

Startups move fast, but speed shouldn’t come at the cost of sustainability. Those early quick fixes and temporary solutions often end up sticking around. Over time, they slow you down, create technical debt, and make it harder to grow.

You don’t need to build the perfect system from day one. But you do need a foundation that won’t hold you back.

Make smart, thoughtful tech choices early. Keep things simple. Review regularly. Focus on value that lasts. That’s how you stay fast without sacrificing your future.
If you’re ready to avoid common startup tech mistakes and build something that lasts, Erlang Solutions can help, so let’s talk .

The post Avoiding Common Startup Tech Mistakes appeared first on Erlang Solutions .