Introduction

When choosing how to deploy eLabFTW, organizations usually compare two options: SaaS and On-Premise.

At first glance, the difference seems simple. With SaaS, the service is hosted and maintained by the provider. With On-Premise, the organization installs and operates the software on its own infrastructure.

Both models are valid. On-Premise can be the right choice for organizations with strict internal policies, dedicated infrastructure teams, or specific regulatory constraints. But in practice, the real difference is not only where the software runs. The real difference is who is responsible for keeping it secure, updated, backed up, and operational over time.

That responsibility is often underestimated.

The appeal of On-Premise

On-Premise deployments are attractive because they provide a sense of control. The software runs on infrastructure managed by the organization. Data stays within an internal environment. Access rules, network policies, backups, and integrations can be adapted to local requirements.

For some institutions, this is necessary. They may have internal security rules, procurement constraints, or compliance requirements that make self-hosting the preferred option.

But control also comes with responsibility.

Running software in-house means someone must maintain the operating system, database, web server, containers, backups, TLS certificates, email configuration, security updates, monitoring, storage, and disaster recovery procedures. It also means someone must keep the application itself up to date.

That is where many On-Premise deployments become more complicated than expected.

Software does not maintain itself

One of the most common issues with self-hosted applications is that they are installed once, then left untouched for too long.

At the beginning, everything works. Users are happy, the service is available, and there is no immediate pressure to change anything. Over time, however, the system ages. New versions are released. Security patches become available. Dependencies change. Operating systems reach end of life. Backup procedures may no longer be tested. Documentation becomes outdated.

The result is a deployment that still appears to work, but is quietly becoming harder to maintain and riskier to operate.

In some cases, On-Premise installations remain outdated for months or even years. This creates several problems:

• Security patches may not be applied.
• Bugs that have already been fixed upstream remain present locally.
• Upgrade paths become more difficult because the gap between versions grows.
• The local installation may depend on old system components.
• Support becomes harder because the running version no longer reflects the current software.

This is not specific to eLabFTW. It is a general problem with self-hosted software. Installing an application is only the first step. Maintaining it properly is the long-term commitment.

When infrastructure skills do not match the deployment

Another practical issue is the skill mismatch that can appear in real organizations.

Many laboratories and institutions have IT teams that are excellent at managing Windows environments, Active Directory, workstations, printers, file shares, and internal business systems. But an On-Premise eLabFTW deployment may require a different set of skills: Linux administration, Docker, web servers, reverse proxies, TLS certificates, database management, cron jobs, firewall rules, backups, and command-line troubleshooting.

This is not a criticism of Windows administrators. It is simply a different operational domain.

A team can be very competent and still be placed in a difficult position if they are asked to maintain a Linux-based web application stack without the time, training, tooling, or mandate to do so properly.

The risk is that the system becomes “owned” by nobody in particular. It works, so it is left alone. Then, when something breaks or a security update becomes urgent, the organization discovers that the deployment is more complex than expected.

Complexity is a cost

On-Premise is sometimes perceived as cheaper because there is no recurring hosting fee. But that view can be incomplete.

Infrastructure has a cost even when the server is already available. Maintenance has a cost. Security has a cost. Backups have a cost. Documentation has a cost. Incident response has a cost. Internal coordination has a cost.

The question is not only: “Can we host this ourselves?”

The better question is: “Do we have the resources, expertise, and procedures to operate this properly over several years?”

For a research team, complexity can also become a distraction. The purpose of eLabFTW is to help scientists manage experiments, data, protocols, and laboratory knowledge. If too much attention is spent on maintaining the infrastructure behind the platform, the organization may be spending effort in the wrong place.

When On-Premise makes sense

On-Premise can absolutely be the right choice when the organization is prepared for it.

A good On-Premise deployment should have:

• A clearly identified technical owner.
• Linux and application hosting expertise.
• A defined update policy.
• Regular security patching.
• Tested backups.
• Monitoring and alerting.
• Documentation for maintenance and recovery.
• A realistic budget for long-term operation.

When these conditions are met, self-hosting can provide control and flexibility.

But without them, On-Premise can become fragile. The organization keeps control, but also keeps the operational risk.

Why SaaS is often the pragmatic option

SaaS changes the responsibility model.

Instead of asking internal teams to maintain the full application stack, the provider handles hosting, updates, security patches, backups, and platform maintenance. Users access the service without needing to manage the underlying infrastructure.

This does not remove every responsibility from the organization. Users still need good internal practices, access management, training, and data governance. But it removes a large part of the technical burden that often causes problems in self-hosted deployments.

For many teams, this is the more pragmatic choice. Researchers can focus on their work. IT teams avoid maintaining a specialized stack outside their usual scope. The software stays current. Security updates are applied. Operational complexity is reduced.

The real question

The SaaS vs On-Premise decision is not simply a question of preference. It is a question of operational responsibility.

If your organization has the expertise, processes, and long-term commitment to maintain an On-Premise deployment properly, self-hosting can be appropriate.

If not, SaaS is often the safer and simpler option.

Because in the long run, the main risk is not where the software is hosted. The main risk is assuming that software, once installed, will take care of itself.

• info