Renting a machine with Rapid.Space means you will get a single Virtual Machine (VM) on a dedicated server, or a cluster of VMs on a group of dedicated servers located on the same 10 Gbps LAN. For peformance, cost and security reasons, each server hosts only one VM.

The following constraints or "features" apply:

Incoming traffic: IPv6 or HTTP(S)

IPv4 is too expensive, because of limited address space. Your server and VM are thus allocated a /64 block of 18,446,744,073,709,551,616 routable IPv6 addresses which can be contacted from anywhere in the world through any TCP/IP protocol over IPv6.

Your machine can also be contacted through HTTP or HTTPS over IPv4 thanks to Rapid.Space Content Delivery Network (CDN) which acts as a proxy between HTTP(S) over IPv4 and HTTP(S) over IPv6. This is for example how the Nexedi web site is accessible to all IPv4 users although its backend is hosted by Rapid.Space on an IPv6 only network.

IPv6 is becoming increasingly adopted worldwide. It should thus be quite easy to find an IPv6 compatible ISP. IPv6Droid provides quite reliable IPv6 on Android about anywhere in the world. In China where IPv6 adoption is still low, Grandenet provides resilient IPv6 connectivity compliant with Chinese Laws.

Outgoing traffic: IPv6 or IPv4 with NAT

Your server and VM can access any IPv4 reachable host through any TCP/UDP based protocol (ex. HTTP, QUIC, SSH, stunnel, etc.) that supports Network Address Translation (NAT).

Your server and VM can access any IPv6 reachable host through any TCP/IP protocol (TCP, UDP, 6in4, GRE, etc.).

No Redundancy / No Resiliency

Rapid.Space architecture is not redundant because hardware redundancy increases costs a lot without improving resiliency much. Moreover, many kinds of applications do not need redundancy or even high availability.

A Rapid.Space VM is powered by a single server, a single ssd, a single network adapter, a single power supply unit in a single datacenter with a single Internet access. If any of those components becomes unavailable for some reason (fire, software bug, power outage, power surge, optical fiber cut on the nearby road by a truck, etc.) then your VM becomes unavailable too, temporarily or permanently.

Those events do happen, not very often, but often enough to be noticed. For statistics of occurrence, please refer to "Downtime statistics of current cloud solutions": even the most expensive public cloud providers are unable to provide true resiliency despite multi-level redundancy architecture (power supply, transit, datacenter, etc). Outages of a couple of hours still happen. Complete data loss still happen.

If you need true resiliency, the only effective solution we can advice is to rent another machine in another datacenter and possibly from another supplier independent or Rapid.Space (ex. OVH, Online, Hetzner, Qingcloud, etc.) then setup a software (ex. SlapOS WebRunner) which automates daily tests of disaster recovery between the two machines.

Nexedi may be able to provide consulting service for true resiliency test automation.


To save the high cost of a DDOS mitigation system, Rapid.Space uses a whitelist approach. Rapid.Space charges for outgoing IPv4 and IPv6 traffic in a way that is economically acceptable for legal applications (ex. ERP backend, Big Data lake, continuous integration, etc.) and economically unacceptable for questionable applications or malware (ex. spam, botnet, scrapping, etc.).

All incoming IPv6 traffic is blocked by default. As a user you have a free-of-charge, configurable whitelist of IPv6 that can access your VM.

All outgoing IPv4 and IPv6 traffic is blocked by default. Exceptions include an official free-of-charge whitelist (debian, npm, git, feel free to contribute) and a paid, configurable whitelist of IPs (1€ setup plus 1€/month fee for every IP address you wish to add).

Debian by Default, Other OS by NBD

By default, every VM boots on Debian 10 GNU/Linux ISO so you can install it.

You may also install remotely your own GNU/Linux distribution or any other operating system (FreeBSD, OpenBSD, NetBSD, Windows, etc.) through qemu-nbd protocol.

Root Access

Currently, root access is only possible inside the VM. No root access is possible on the host server which runs the VM.

Bare metal services deployed on the host server using nano-containers must be able to run with an unprivileged user.

Zero knowledge

For security and privacy reasons, Rapid.Space cannot access the VM. No backstops, no emergency recovery. You are by yourself.