Hyper Open Edge Cloud

How to maintain critical network infrastructure without root access?

Explains how to operate critical infrastructure offline or with dedicated NMS.
  • Last Update:2026-04-08
  • Version:001
  • Language:en

All Rapid.Space products are provided with a license for Rapid.Space cloud-based NMS/OSS/BSS which automates configuration and remote operation, including alarms, counter collection, KPI generation, software upgrades, etc.

Rapid.Space cloud-based NMS/OSS/BSS is based on SlapOS open source technology. 

The architecture of SlapOS is based on two components: SlapOS Master and SlapOS Node. SlapOS Master is the central controller that keeps tracks of every user and of every configuration of every Rapid.Space product attached to it. At the other end, every Rapid.Space Product (ORS, EdgePOD, NotePOD, DronePOD, etc.) is a SlapOS Node. Each SlapOS Node contacts SlapOS Master from time to time, collects its configuration parameters from SlapOS Master and notifies SlapOS Master of any changes in its local environment.

Resilient, offline operation

SlapOS is a resilient NMS/OSS/BSS. This means that any Rapid.Space product and any SlaOS Node can still be operated whenever Internet access is lost, whenever access to SlapOS Master is lost, or whenever SlapOS Master is down. In particular, every SlapOS Node can:

  • start and run local services, even if SlapOS Master is not available;
  • configure local services, even if SlapOS Master is not available (new feature announced at MWC 2026).

However, orchestration, software upgrade, KPI generation and remote support are not available without access to SlapOS Master.

This means that all Rapid.Space products can be operated and configured offline, or in an environment that does not have access to Rapid.Space cloud-based NMS/OSS/BSS. However, whenever access to SlapOS master is lost, some network operation features are no longer available. 

Root access

Rapid.Space Open Radio Station (ORS) and EdgePOD BBU exist in two versions:

  • a standard version that does not includes root access;
  • an "SDK" version that includes root access and is priced at least 10,000€ more.

The standard version is meant for deployment and operation using Rapid.Space cloud-based NMS/OSS/BSS. The SDK version is meant for experts who would like to use ORS as a "test & measurement" product, or for developers who would like customise ORS software, with or without the benefit of Rapid.Space cloud-based NMS/OSS/BSS.

Some Rapid.Space clients would like to obtain root access without having to pay for it an additional 10,000€ or more. Those clients usually claim that root access is required to operate Rapid.Space products in corporate environments without Internet access, without access to Rapid.Space cloud-based NMS/OSS/BSS, or simply to become independent from Rapid.Space.

Sadly, Rapid.Space can not provide root access "for free" due to Amarisoft copyright license which imposes Rapid.Space not to provide root access to clients who benefit from the cost-optimised "Amarisoft deployment licenses" used in standard versions of ORS and EdgePOD BBU. The main rationale for this requirement imposed by Amarisoft is that some early clients of Rapid.Space were using ORS instead of purchasing Amarisoft Callbox, which lead to huge market distorsion.

There are however many ways to deploy Rapid.Space in a corporate environment without Internet access or without access to Rapid.Space cloud-based NMS/OSS/BSS. Most Rapid.Space partners that integrate Rapid.Space products for multinational corporations, state-owned companies, telecom operators or governments use one of the approaches listed below.

Solution 1: offline operation

Rapid.Space product is pre-configured by partner in their lab and then deployed on client premise, without access to Rapid.Space cloud-based NMS/OSS/BSS. Local configuration is achieved using the offline configuration panel present in most Rapid.Space products. From time to time, Rapid.Space product is connected to the Internet so that Rapid.Space cloud-based NMS/OSS/BSS can handle software upgrade and generate KPIs.

This solution is suitable for deployments where backhaul network can be temporarily unavailable.

Solution 2: partner NMS/OSS

Rapid.Space partner acquires from Rapid.Space a dedicated NMS/OSS which is hosted on partner's premise. Partner's NMS/OSS is integrated with the remote maintenance network infrastructure used by the partner to support its clients. Rapid.Space products deployed by partner for its clients are attached to partner's NMS/OSS.

This solution is favored by most Rapid.Space partners who operate critical infrastructure of multinational corporations, utilities or government.

Solution 3: client NMS/OSS

Rapid.Space partner acquires from Rapid.Space a dedicated NMS/OSS which is hosted on client's premise. Rapid.Space products deployed by partner for its clients are attached to client's NMS/OSS. No remote maintenance network infrastructure is needed.

This solution is suitable for clients that can not provide remote access to their infrastructure for maintenance.

Solution 4: portable NMS/OSS

Rapid.Space partner acquires from Rapid.Space a dedicated NMS/OSS which is hosted on partner's premise and is small enough to be carried around. Rapid.Space products deployed by partner for its clients are attached to partner's NMS/OSS. Whenever partner needs to do maintenance of client infrastructure, partner carries the portable NMS/OSS to client premise and does maintenance operation. No remote maintenance network infrastructure is needed.

This solution is suitable for clients that can not provide remote access to their infrastructure for maintenance, and in addition do not have enough budget to host their own NMS/OSS.

Solution 5: technology transfer

One of Rapid.Space missions is to provide digital independence and sovereignty to its partners through technology transfer. Rapid.Space Accelerator (XXX) service organises this technology transfer until a partner can operate and extend their NMS/OSS/BSS by themselves. As part of this process towards independence, partner may obtain from Amarisoft root access to all Rapid.Space products without having to pay for "SDK" version.

This solution is favored by most mobile network operators.

The benefits of removing ssh and root access

Not having remote root access can be considered as something unacceptable by most open source developers. Yet, this is what Google did for its infrastructure by removing ssh remote access. And this is something Rapid;Space has been trying to achieve.

We discovered about ten years ago that not having root access has some unexpected benefits. It forces to automate everything, which is the only way to achieve reproducibility and quality assurance. With ssh access, someone always changes some configuration of the base system which later creates some non conformance. 

Not having root access also prevents losing network access completely, as a side effect of a mistaken local configuration of the underlying GNU/Linux system. Every user with root access which we know lost access to their ORS at least once in their life, and had to send it back for repair!

Not having root access also protects from the increased risks posed by AI agents that could remotely destroy a SlapOS Node by leveraging ssh-agent open access. Considering this new risk, rather than relying on remote root access over ssh to maintain network infrastructure, we should probably, for our own benefit, learn as soon as possible how to operate an infrastructure without root and without ssh.