Summary

  • Rock-Hosting SASU is an active French hosting company, founded in 2014, and its current legal identity can be properly linked to AS207911 without substituting an access provider, a data centre operator, a former ASN holder or a customer network.
  • Its low-cost offering combines mature hardware, OpenVZ-based VPS plans, IP-KVM for dedicated servers, provider-side monitoring, automatic anti-DDoS protection promises and a failover address for €2.49 per month that can move between Rock-Hosting machines.
  • AS207911 visibly emits two/24IPv4 and one/48IPv6, but these routes have different control and ownership histories: one IPv4 range remains allocated to RapidSeedbox, so the route origin must not be confused with Rock-Hosting ownership.
  • The biggest unanswered questions concern the exact datacentre, the DDoS protection envelope, path diversity, failover failure domain, service levels, backup and restoration evidence, current operating system images, security controls and data processing conditions.

The promise begins with a cursor

Imagine the moment when Rock-Hosting really sells. A small French software company moved its website from a virtual server to a dedicated machine. The new server is ready, but the public address still points to the old instance. Instead of reducing DNS TTL values, waiting for caches and accepting a period when users reach two different machines, an administrator opens the Rock-Hosting console and clicks. The provider claims that the same failover address can be routed to any of the customer's VPS or dedicated servers 'in seconds', without modifying DNS.

This is a compact and useful promise. An address becomes a mobile handle above the machines. The customer can replace a host, change product class or recover from a guest failure without asking every resolver on the internet to forget the old answer. Rock-Hosting'sfailover pagemakes this mobility sufficiently central to be priced separately at €2.49 HT per month per address. Itshomepageadds two adjacent assurances: the infrastructure is protected by default against distributed denial-of-service attacks, and the servers are located in France on what it calls an Iliad data centres network.

These three claims — filtering the attack, moving the address, controlling the route — fit together better than a list of server specifications. They turn a small host into a continuity service. A customer is not simply renting old CPU cycles. They are asking a single operator to notice a traffic problem, keep an address usable, change where that address lands, and respond when automation is limited public evidence.

But control has layers. A failover click may modify an internal route while leaving both machines in the same rack, the same room, the same power domain and the same upstream path. An anti-DDoS system may clean common floods, rate-limit legitimate users, or blackhole the attacked address to save the rest. An autonomous system number allows a provider to emit routes; it does not make every emitted range the provider's property, create a second operator, or prove the physical server is where an IP geolocation service says.

Even the console is a dependency: a customer cannot click during an outage if the control plane, authentication path or operator is unavailable.

Rock-Hosting is therefore most revealing when read as a chain of controlled transfers. The company controls some parts directly, delegates others to transit, datacentre, software and payment providers, and leaves the customer responsible for the operating system and application. Its public documents are concrete enough to map much of this chain. They are not complete enough to allow a serious buyer to assume that 'failover', 'anti-DDoS' or 'France' settles the resilience question.

The SASU behind the promise

The identity bridge is solid. The French government's open company search resultindicatesROCK HOSTING under SIREN 800 111 957 as administratively active, with its main establishment at 58 rue de Monceau in Paris, SIRET 800 111 957 00034 and the hosting/data processing activity code 63.11Z. It names Yann François Jacques Guern as president of the simplified joint stock company. The provider'slegal noticegives the same legal name, same identifiers, same activity code, VAT number and address. RIPE network records will later connect this same Parisian company to AS207911.

Pappers, drawing on French register data, adds a useful timeline. The company was created in 2014, has a capital of €1,000, moved its registered office from Saint-Raphaël to Paris in November 2025 and remains active. It declares one to two employees for 2023 and indicates that accounts are confidential. These facts support the 'small host' description, but only with limits. A dated employee bracket is not a current service roster, and a small legal headcount may use subcontractors, automation, upstream operation centres and remote datacentre hands. The evidence does not disclose 2026 revenue, cash position, customer concentration or on-call coverage.

Rock-Hosting claims to have been born in 2014 and to serve more than 5,000 customers today. The first part matches company records. The second remains a company assertion: no definition is given whether 'customers' means active paying accounts, all registrations since launch, individuals, companies or services. Public network estimates and domain counts cannot reliably resolve this question. One customer may operate hundreds of domains; another may run a private server without any.

There is nevertheless limited third-party evidence of real hosting use. The French association Qualisport names Rock-Hosting SASU as host of its server in itslegal notice. The page still bears Rock-Hosting's old Fréjus address, so it must not be read as proof of a newly signed contract or current server placement. It shows that the company name is not simply a register label attached to an empty ASN. It has appeared at the customer end of a real hosting chain.

This accuracy matters because several more famous names will enter the story: Iliad data centres, Opcore, OVH, Eurofiber and RapidSeedbox. None is the designated company. Rock-Hosting SASU is the contractual and analytical subject. An upstream's capacity is not Rock-Hosting's capacity unless the contract says so; a datacentre operator's certification is not Rock-Hosting's certification; a customer's address block is not Rock-Hosting's asset. Preserving these boundaries is the difference between assessing a small host and silently replacing it with its suppliers.

Eight offers, mature parts and two contradictory figures

The public catalogue is exceptionally easy to read. Rock-Hosting displays four VPS plans and four dedicated server plans, all priced monthly before tax. The VPS range starts at €3.99 for one vCore, 2 GB RAM and 20 GB storage and reaches €12.99 for five vCores, 16 GB and 200 GB. TheVPS cataloguedescribes SAS storage under RAID 5, a gigabit connection with lower bandwidth per plan, unlimited traffic, one IPv4 address and optional failover addresses. Anti-DDoS, reinstallation, reverse DNS and monitoring are around the server rather than appearing as premium enterprise modules.

TheVPS Large detail pageprovides the architectural fact that the comparison grid does not highlight: the service uses OpenVZ on Dell hardware with Xeon E5-2670 processors. OpenVZ is operating-system-level virtualisation. Customers receive isolated environments that share a host kernel rather than independent hardware-virtualised kernels. This can be efficient and economical, especially for ordinary Linux workloads, but it changes the due diligence questions. Kernel features, host system patching and certain resource controls remain provider decisions; a customer cannot install an arbitrary kernel nor assume the isolation boundary of a KVM virtual machine.

The hardware also explains part of the price. Intel identifies theXeon E5-2670as a Sandy Bridge EP processor launched in Q1 2012, subsequently discontinued, with maintenance updates ending in 2020. Mature equipment is not automatically unreliable. A well-managed operator can replace disks, test memory, stock spares and extract useful work from amortised servers. The economic advantage is that most acquisition costs have already been consumed. The operational cost is that performance per watt, spare part availability, firmware history and component failure rates deserve evidence rather than assumptions.

The dedicated range makes this trade-off more visible. Thededicated cataloguestarts at €14.99 for an Atom C2750 with 8 GB of DDR3 and a 1 TB SATA disk. It rises via older Xeon L3426 and E5620 systems up to a Xeon E3-1230 v3 at €45.99 with 32 GB and two 2 TB disks. TheDedicated Small detail pagepromises a 200 Mbit/s allocation on a 1 Gbit/s connection, one IPv4 address, up to two failover addresses, remote reinstallation, a rescue environment and IP-KVM. This out-of-band console is valuable: a customer can access the screen and keyboard after a firewall or network misconfiguration has cut SSH.

The smallest dedicated plan indicates only a single disk, so the generic RAID mention elsewhere on the site must not be applied to it. The medium and upper offers list two disks and hardware RAID 0 or 1. RAID 1 can preserve service after a disk failure; RAID 0 increases risk; neither is a backup. The pages do not disclose disk age, power-on hours, media error policy, spare inventory, rebuild monitoring, replacement time or whether the customer can inspect SMART data.

Two contradictions are more immediately testable. The VPS comparison page announces 200 Mbit/s for Large and 250 Mbit/s for XL. The individual pages displayed 100 and 200 Mbit/s respectively on 17 July 2026. A buyer should specify guaranteed bandwidth, burst ceiling, traffic policy and packets-per-second treatment in the order rather than picking the most attractive page. 'Guaranteed bandwidth' and 'burst up to 1 Gbit/s' also require an observation point: at the server port, at the provider edge, or towards a named external test network.

The image catalogue raises another freshness question. Rock-Hosting's publicVPS distribution liststill announces Debian 8 to 10, Ubuntu 16.04 to 19.10 and CentOS 6 to 8. TheDebian version tableidentifies Debian 13 as the current stable release in 2026 and shows older versions beyond the project's ordinary support. The correct conclusion is not that Rock-Hosting necessarily deploys an unpatched image today; the page may be out of date. The right test is to ask for the actual template catalogue, build dates, checksums, update process and supported migration path before provisioning.

The monthly price buys a boundary, not an administration

Rock-Hosting'sterms and conditionsexplain where the displayed low price stops. Services are prepaid in euros, normally by card via Stripe or by PayPal. The minimum subscription period is one month, and cancellation takes effect at the end of the already-paid period. This makes the commercial commitment short. The same terms indicate that the offer is open to a natural or legal person with a French tax address, narrowing the apparent market even if the public network profile describes a European scope.

The customer receives infrastructure and control functions, not a fully managed application. Rock-Hosting states that technical support provides one-off assistance and handles hardware failures. Unless a specific optional service level states otherwise, it does not administer software, websites or services after delivery. The customer must provide accurate identity information, protect credentials, install security updates, comply with acceptable use rules and monitor messages in the account console.

The provider reserves the right to interrupt a service immediately to protect its systems when a machine is compromised, used for phishing, left vulnerable or involved in forbidden relaying and abuse.

Backup is the clearest economic transfer. The terms say that Rock-Hosting does not perform any backup of customer data unless an option states otherwise; optional backup services can be ordered via the console. A VPS at €3.99 is therefore not a continuity plan for €3.99. The customer must add backup capacity, another location, retention, encryption, monitoring and restoration work — or accept the possibility that a storage or human failure destroys the service. The contract specifically places elementary backup measures on the customer, even in case of loss, damage or human error.

The same boundary applies to availability. Rock-Hosting states that it will endeavour to provide 24-hour access, subject to planned maintenance and difficulties beyond its responsibility. The public terms define total internet unavailability around essential network elements but do not publish a percentage, measurement period, probe, service credit table or restoration commitment. '24/7' in this document is an effort and an access goal, not a numeric service level.

The included operational tools remain significant. Remote reboot, reinstallation and rescue can shorten recovery. IP-KVM can recover a dedicated server whose operating system is alive but unreachable. The provider'smonitoring pageindicates that customers can select ping, HTTP and other checks and configure email recipients. Yet it does not give probe locations, frequency, timeout, retention or escalation path. Provider-side monitoring is useful for alerts; it is not an independent availability register and cannot tell whether real users can perform a transaction.

This division of work is consistent for a budget host. Automation keeps labour out of ordinary provisioning, and the customer provides system administration skills. The purchase error would be to buy the friendly word 'support' while budgeting as if it included guest patching, database recovery, application diagnosis and incident command. The useful test is to write ten probable failures and assign each to Rock-Hosting, the datacentre, the upstream or the customer before paying.

Failover moves an address, not a business

Rock-Hosting's failover address elegantly solves a restricted problem: keeping a public IPv4 address when changing the machine behind it. A customer moving from an OpenVZ instance to a dedicated server can copy data, prepare the destination, stop writes, perform a final sync and redirect the address. No public DNS change is required. The customer can also retain control of reverse DNS via the console. For a mail server, an authoritative service or a legacy application whose address is embedded in partner systems, avoiding an address change can be far more valuable than the €2.49 monthly fee.

But the page describes a user-triggered action, not automatic high availability. It does not say that a health checker decides when to move, that the target already has the current application state, or that sessions survive. 'A few seconds' seems to describe provider routing, not the time for neighbour caches, firewalls, stateful applications and clients to converge. A database that has not been replicated is still stale after a perfect address move. A web service whose TLS private key is missing from the target still fails. The address is a pointer, not a recovery plan.

The failure domain is equally important. Rock-Hosting says an address can be sent to any of the customer's VPS or dedicated servers, but it does not say that these servers can occupy different datacentres, power supplies, routers or metropolitan areas. If both machines share a single data hall and the hall loses power, the click has nowhere to go. If they share the same access circuit and it fails, moving the destination behind that circuit changes nothing. If the customer console depends on the affected network, a manual failover may not be available when needed.

Failover also creates provider-specific convenience. The address remains usable as long as the destination stays with Rock-Hosting. The public page does not promise that a customer can take the address to another host, announce it from their own ASN, use an API to automate changes or export the configuration. This is a real switching cost even when the compute workload is portable. A monthly contract reduces legal lock-in, while a familiar address and console increase operational lock-in.

The right test is therefore deliberately mundane. Put a non-critical service on a VPS and a second copy on a dedicated server. Generate writes, move the address during a controlled window, measure packet loss and application recovery from several external networks, then move it back. Repeat while the primary guest is unreachable rather than cleanly shut down. Record who clicks, what evidence authorises the action, whether the target can be preconfigured, how reverse DNS behaves and what happens to traffic already in flight. A successful brochure demonstration is worth less than a failed exercise that reveals the missing runbook.

AS207911 has three ownership stories

Rock-Hosting's autonomous system is real, current and legally linked to the designated company. RIPE's aut-num entitynamesAS207911asROCK-HOSTING, links it toORG-RA1229-RIPEand Rock-Hosting's maintainer, and records its creation on 30 July 2025. The corresponding organisation entitynamesRock-Hosting SASU and gives the same Parisian address as the French registers. This is the decisive identity bridge.

It also avoids a tempting historical error. The Rock-Hosting company dates from 2014, but this current RIPE aut-num entity dates from 2025. RIPEstat's long routing historycontainsroutes under the same number from years earlier, and a direct fetch ofIPinfo's AS207911 pagestill returned the old identityLINKTEL-NWin a snapshot even if a fresh index described Rock-Hosting. Autonomous system numbers can be returned and reassigned. Old routes attached to the number are not evidence that Rock-Hosting operated them, had an ASN in 2019 or inherited the previous holder's network.

The current observation is much cleaner. RIPEstat's announced prefixes viewshowedthree routes on 17 July 2026:82.25.135.0/24,193.27.21.0/24and2001:678:10d8::/48.bgp.toolsandIP2Locationindependently showed the same two IPv4/24s and one IPv6/48. The larger numbers from PeeringDB — ten IPv4 prefixes and five IPv6 prefixes — are policy or prefix limit fields, not evidence that fifteen prefixes are emitted.

The three current routes do not mean the same thing.

The RIPE record for82.25.135.0/24describesanASSIGNED PAspace associated with a Rock-Hosting organisation entity and a route emitted by AS207911. Provider-aggregatable space is normally linked to an allocation chain; the record supports a Rock-associated assignment and current use, not an unreserved claim that the SASU owns a freely portable/24.

The record for193.27.21.0/24is more important because it belongs to someone else's allocation. The inetnum isALLOCATED PAto RapidSeedbox Ltd, and the route object naming AS207911 is maintained by RapidSeedbox's maintainer. Rock-Hosting's AS visibly emits the range, and the current RPKI observation qualifies the origin as valid. This is consistent with a customer routed, transit or network service arrangement. It is not evidence that Rock-Hosting owns the addresses, hosts every machine using them, or even that the commercial arrangement has the form an outsider would guess. The public register must be reported exactly: space held by a third party, currently emitted by Rock-Hosting's ASN.

The IPv6 record for2001:678:10d8::/48isASSIGNED PI, named for Rock-Hosting, linked to ORG-RA1229-RIPE and maintained by its maintainer. The provider-independent status gives the company a stronger portability position than a PA assignment. It does not show how much IPv6 is used, whether every plan receives some, or whether the customer console supports equivalent failover and reverse DNS functions. The public plan tables highlight one IPv4 address and say little about IPv6, so a buyer should ask for a working IPv6 allocation and failover test rather than inferring product parity from the route.

The three routes were indicated as RPKI valid by current BGP sources. This means the observed origin was authorised by the corresponding route origin authorisations. It does not authenticate the full path, stop a leak by an authorised origin, encrypt traffic, prove address title or locate a server. RPKI is a valuable routing security control, but a single control.

This small set reveals why ASN control can be commercially useful. Rock-Hosting can emit its own PI IPv6 space, operate an assigned IPv4 range and carry a third party's range behind a routing policy. This can support failover, customer addressing and upstream negotiation. The same evidence also sets a strict limit: origin authority is a routing fact, not a title to every address in the announcement.

A visible upstream defines the anti-DDoS envelope

At the search snapshot, RIPEstat's neighbour observationshowedone adjacent network: AS35625, Eurofiber France. bgp.tools showed the same upstream. This is not absolute proof of single-homing. A private backup, a low-visibility path, a temporarily inactive circuit or a collector hole may be invisible. It is enough to make concentration a purchase question: if every publicly visible path goes through Eurofiber, what happens when that handoff, that datacentre cross-connect or that commercial account falls?

Administrative records do not replace a live answer. Rock-Hosting's RIPE aut-num text lists an import and export policy with AS2027 and AS57199, while current collectors see AS35625. The entries may be outdated, forward-looking or incomplete. bgp.tools also detects a 10 Gbps session at GNM-IX, while Rock-Hosting'sPeeringDB pagelists no public exchange or datacentre sessions. A remote exchange port, a reseller arrangement or a detection artefact is possible. None should be turned into a second physical path without a circuit diagram.

Eurofiber's public technical material helps delimit what may lie under Rock-Hosting's anti-DDoS promise. ItsAS35625 policyexposes route control communities for transit, peering and private interconnects. It also documents a customer blackhole community,35625:0, which allows traffic to be discarded towards a more specific destination and propagates a corresponding reject signal to supporting upstreams. Blackholing is valuable during a severe attack because sacrificing one destination can protect links and neighbours. It does not keep the attacked service online; it deliberately makes that destination unreachable.

Eurofiber separately markets anInternet Dédiéservice with standard anti-DDoS, symmetric access up to 10 Gbps, customer-owned address options, redundancy choices and a 24/7 network operations centre. This makes Rock-Hosting's automatic protection claim plausible as a product dependency. It does not reveal which Eurofiber product Rock buys, its circuit speed, detection threshold, included scrubbing capacity, scrubbing location, attack classes, overflow treatment or whether blackholing is a last resort.

These missing dimensions determine the outcome for the customer. A 100 Gbps volumetric flood and a low-rate application attack are different problems. A UDP reflection may be recognised at the network edge; a valid-looking HTTP request may require application context. Scrubbing may preserve good traffic but add latency or false positives. Rate limits may keep a host alive while excluding legitimate bursts. IPv4 protection may not imply identical IPv6 protection. 'Automatic' may mean always-on filtering, a telemetry-triggered diversion, a threshold alarm followed by an operator, or a provider action after congestion begins.

A buyer should ask for the protection envelope as a technical schedule: protocols and addresses covered, always-on or on-demand design, detection interval, diversion mechanism, scrubbing capacity, maximum attack duration, packet rate limit, IPv6 parity, customer controls, false positive escalation, emergency blackhole policy, reporting and service recourse. They should then conduct a table-top exercise with Rock-Hosting and obtain an authorised test method. Launching an unsolicited flood would be imprudent and likely prohibited; asking the provider to demonstrate an authorised test or provide a recent anonymised report is ordinary diligence.

ASN control strengthens Rock-Hosting's position because the company can shape announcements and work directly with an upstream. It does not make the upstream disappear. The anti-DDoS product is only as useful as the clean path back to the rack, and the failover address is only as useful as the surviving path to its new destination.

The datacentre is still a name without an answer

Rock-Hosting's public statement is precise at the country level and vague below: servers are in France and use a network 'provided by Iliad data centres'. This is evidence of what the company claims, not sufficient to identify a site. No address, centre code, hall, electrical design, remote hands arrangement, certification number or customer-side datacentre contract appears on the pages examined.

The name itself has a history. Opcore's operator timelineindicatesthat Iliad data centres was created as a colocation business in 2009, combined into the Scaleway brand in 2020 and separated under the Opcore name in 2023. Rock-Hosting's phrasing is therefore understandable as a legacy or familiar datacentre label. It still does not tell a 2026 buyer whether the machines occupy an Opcore site, which site, under which counterparty or under which current insurance scope.

Current routing does not bridge the gap. Eurofiber can provide transit in many French datacentres. Rock-Hosting's empty datacentre list on PeeringDB proves only that no datacentre is disclosed there. An IP geolocation result may identify a probable country or metro and still be wrong at the building level. A traceroute may reveal an upstream interface while hiding the cross-connect, transport circuit and rack. The third-party RapidSeedbox range carries a German country label in its registry record, but that field is not proof that the service behind every address is physically in Germany.

Even Rock-Hosting's web presence illustrates the danger of layering confusion. At the 17 July observation, the public website and console domain resolved to an address emitted by OVH, while the three service network routes were emitted by AS207911. There is nothing intrinsically wrong with placing the storefront away from the customer-serving network; the separation can improve survivability. It means that 'the website is online', 'the console is online', 'the Rock ASN is reachable' and 'the customer server is online' are four different measures.

The datacentre question must be concrete. Name the building and the contracting operator. Identify which plans are located there. Provide relevant power, cooling, fire, physical access and network designs; the certificate holder, scope and validity; remote hand hours and authorisation; spare part and disk destruction processes; and the boundaries between Rock-Hosting and the datacentre. Most importantly, say whether two servers used for failover can occupy independent power and network failure domains. Without that last answer, the mobility function is a host migration tool, not a site resilience.

French location may still matter. It gives the French customer a familiar contractual jurisdiction, predictable physical data questions and potentially low latency. But a Paris registered office address does not locate customer data, and a French datacentre operator site does not in itself prove that backups, monitoring data, support access or payment data remain in the same country. Locality is a chain, not a flag.

The low price is a division of labour

Rock-Hosting's entry prices are genuine public offers, but their economic meaning comes from the work left out. A VPS at €3.99 includes a small OpenVZ environment, an address, basic console controls and an anti-DDoS claim. It does not include by default customer data backup, guest administration, a published availability recourse, a dedicated kernel, a modern image guarantee or disclosed multi-site recovery. An additional failover address increases the monthly price of that smallest VPS to €6.48 excluding tax — about 62% increase — before backup or administration.

The dedicated economics follow the same pattern. The entry machine at €14.99 uses a mature low-power processor, DDR3 and a SATA disk. Rock-Hosting can price it low because the acquisition cost is old and automation reduces handling. The customer accepts lower absolute performance and owns more of the recovery process. IP-KVM, rescue and reinstallation are the tools that make this market acceptable for a technically competent buyer.

The plan can be rational for a hobby service, a test environment, a low-traffic website, a small community or a secondary node whose owner values root access over a formal service level. It becomes dangerous when a procurement team sees 'dedicated', 'RAID', 'anti-DDoS' and 'monitoring' and assumes a managed business continuity service. A single disk is dedicated but not redundant. RAID may survive some disk failures but not deletion. Anti-DDoS may protect reachability but not a vulnerable application. Monitoring may send an email but cannot restore the database.

Large-scale competitors squeeze the raw-spec argument. On 17 July, OVHcloud'sVPS France pageannounced an entry plan at €3.81 HT with 2 vCores, 4 GB, 40 GB NVMe, one-day automated backup and 500 Mbit/s. Kimsufi'sdedicated France catalogueplaced budget bare metal near Rock-Hosting's entry range while naming French datacentres and including anti-DDoS. These are volatile snapshots, not recommendations, and support, stock, virtualisation and terms differ. They show that Rock-Hosting cannot rely on 'cheapest server' as a lasting moat.

Its plausible differentiation is rather coordination. A small provider can know a customer's topology, allow an unusual routed range, move an address between product classes and provide human context continuity. The current ASN gives it more direct network control than a simple reseller. This value is hard to capture in a CPU table, and the public support language does not yet prove it with response distributions, named escalations or case evidence.

The total cost must therefore be calculated from the workload backwards. Add backup storage outside the failure domain, restoration tests, failover addresses, licences, monitoring from independent locations, system administration time, after-hours response, migration labour and the expected cost of slower hardware. Then price the same design elsewhere. Rock-Hosting may remain attractive. If so, the reason will be that its narrow controls match the customer's runbook — not that €3.99 is the total bill.

Security starts where the shield stops

Network filtering protects availability; it does not patch a guest, secure a password, separate admin roles or detect data theft. Rock-Hosting's contract makes the guest boundary explicit. The customer is responsible for security updates, software and content. The provider may suspend a compromised, vulnerable, phishing or abusive service to protect the wider system. This is a sensible shared hosting power, but it creates another continuity mechanism: a poorly maintained customer can be taken offline by policy even if the rack, route and DDoS platform function perfectly.

The outdated public image list makes provisioning the first security test. Ask which images are currently offered, when each was built, whether installation pulls current packages, how signatures are verified and when a template is retired. On OpenVZ, ask the host kernel family, update policy, container isolation controls and resource limits. On dedicated servers, ask firmware history, disk wiping, motherboard management isolation and how IP-KVM credentials are issued, rotated and logged.

The console deserves the same attention as the server. It can reboot, reinstall, modify reverse DNS and redirect addresses. These are high-impact privileges. The public login page establishes that a console exists, but the examined material does not document enforced multi-factor authentication, role-based access control, separate billing and technical roles, single sign-on, an API, immutable audit export, session controls or staff privileged access approval. Absence from the public pages is not proof that a feature is absent. It is a reason to ask for a demonstration.

Privacy and compliance documents add a visible consistency problem. The main legal page now shows the 2025 Paris office, while theprivacy charterstill directs postal privacy requests to a pre-2019 address in Juan-les-Pins. The privacy text says Rock-Hosting uses Google Analytics and account cookies, while the site banner says it uses no cookies. The charter describes collected account, identity, login, browsing and purchase data and says some may go to subcontractors and partners, but it does not publish a current subcontractor list, retention schedule or complete data location map.

These divergences do not prove illicit practice. Pages may lag systems, and a particular analytics configuration may have changed. They show that a buyer cannot use the public privacy page as a current control document. The French data protection authority says in itssubcontractor security guidethat a data controller must have an Article 28 contract, understand technical and organisational measures, consider the full subcontractor chain, verify geographic location and retain audit means over access, logging, authentication and security.

A customer processing personal data should therefore obtain a current data processing agreement, a subcontractor inventory, support access locations, breach notification timelines, deletion/return conditions, encryption limits, access logs and audit rights. A health data buyer should ask for the exact certification required for their use rather than assuming 'hosted in France' suffices. A certificate belonging to a datacentre or upstream should be mapped to the service scope before being cited.

There is no contradiction in a budget host refusing to publish an enterprise assurance library. There is a purchase mismatch if a regulated customer treats silence as assurance. The right claim is modest: Rock-Hosting offers French infrastructure under a French company and exposes some useful technical controls. Compliance depends on the order, the data, the customer configuration and the evidence exchanged outside the storefront.

Incidents, support and the cost of silence

No credible public leak from Rock-Hosting or major service incident appeared in the frozen evidence set. This is not proof of an incident-free history. The homepage links to separate documentation and status hostnames, but both failed DNS resolution at the 17 July observation. The website itself remained reachable. The conclusion is narrow: a potential customer could not inspect a public status history via the advertised link at that time.

This missing history matters because an availability percentage is less useful than an operator's narrative of a real failure. A good archive shows start and detection times, affected products, customer symptoms, mitigation, restoration, root cause and preventive work. It also reveals whether maintenance notices and service incidents share the same clock. Rock-Hosting publishes none of this on the accessible pages examined, and its terms provide no public service credit formula.

The visible upstream offers an example of why dependency incidents need careful attribution. Eurofiber disclosed a compromise in November 2025 of its ticketing and cloud portal environment, later publishinglessons and corrective actions. It indicated that a blind SQL injection led to data exfiltration while telecom and cloud services remained operational. Nothing in the evidence shows Rock-Hosting's data or service was affected. This is not a Rock-Hosting incident. It is a useful diligence scenario: if an upstream control system or support platform is compromised, what customer information is shared, who notifies whom, and can routing changes continue via a separate channel?

Support is where a small host might respond to this scenario better than a giant. Rock-Hosting promises friendly and responsive service seven days a week, and its terms confine ordinary help primarily to one-off assistance and hardware problems. The public pages do not specify hours per channel, staff vs. on-call coverage, severity levels, response targets, restoration targets or escalation authority. '7/7' is not the same as a guaranteed engineer at 03:00.

The purchase should test support before production. Open a normal technical ticket, then conduct an agreed exercise outside hours. Ask a question that crosses guest, host and network boundaries and observe whether ownership is clear. Verify emergency identity control for a failover request, because a fast unauthorised route change is a security flaw. Ask who can coordinate Eurofiber and datacentre remote hands, and whether the customer can reach that person when the console is unavailable. Human context has value only when escalation survives the failure.

The cost of switching lies in addresses and knowledge

Rock-Hosting's short subscription period makes cancellation easy on paper. A normal Linux workload can be copied to another VPS or bare-metal machine, especially when using standard files, databases and configurations. The biggest lock-in is not a proprietary database API. It is the accumulated operational knowledge around a particular console, address, route, recovery procedure and support contact.

The failover address increases reliability within the provider while increasing the value of staying. Partners may whitelist it; mail reputation may attach to it; reverse DNS may become operationally important. The public service does not promise external portability. A customer using Rock-Hosting's PA space should assume they must renumber on exit unless the contract proves otherwise. The PI IPv6 block belongs at the provider level, not automatically to each tenant.

A customer bringing their own routed range may have a different exit path, but the RapidSeedbox prefix shows only that AS207911 emits third-party-held space, not the conditions under which a new customer can do so.

Data exit is not documented either. The pages describe reinstallation, not a full export API, disk image format, snapshot export, transfer allowance during departure or secure destruction certificate. OpenVZ containers can be portable at the application and filesystem level, but kernel and host assumptions may emerge during migration. Dedicated server customers control their files but still need a destination, enough transfer time and a plan for a failing source disk.

The most effective exit test happens at entry. Build the first server from documented automation or a script. Keep DNS zones, secrets and monitoring outside the provider. Store encrypted backups in another failure domain. Export a workload and restore it elsewhere before it becomes important. Record the steps needed to replace the failover address with a new one. If departure is tested, the monthly contract becomes truly flexible; otherwise, operational habit may outlast any formal commitment.

Buy the promise as a sequence of exercises

Rock-Hosting is too small and the public evidence too incomplete for a logo purchase. It is also concrete enough for a disciplined pilot. The following tests turn its three main controls — anti-DDoS, failover and ASN operation — into observable outcomes.

  1. Link the legal counterparty.Write Rock-Hosting SASU, SIREN 800 111 957 and the current Paris address into the order. Reconcile the invoice, payment beneficiary, terms, privacy contact and abuse contact. Ask why the standard terms still contain old geographical phrasings and request the version in force that governs the order.
  2. Freeze the exact plan.Fix the CPU, RAM, storage, virtualisation, bandwidth, traffic, address count, taxes, setup, delivery and renewal terms. Resolve VPS Large and XL bandwidth conflicts in writing. Confirm whether the CPU is dedicated, how resources are limited and what 'guaranteed' means.
  3. Inspect a delivered instance.On VPS, record kernel visibility, CPU flags, steal or throttle indicators, disk latency and sustained network throughput at different times. On bare metal, inspect disk health, firmware, memory, IP-KVM isolation and reinstallation support. Benchmarks should model the customer's workload rather than chasing a performance score.
  4. Validate the image chain.Obtain the current supported template list and build dates. Provision a current OS, fully update it, reboot, scan it and confirm that a reinstallation produces the same documented base. Ask how a vulnerable template is retired and whether customers receive lifecycle notices.
  5. Map every failure domain.Obtain the datacentre name, hall or service boundary, power path, access circuit, router pair, upstreams, remote hands process and certification scope. Place the primary and failover targets in demonstrably independent domains where the workload requires it. 'Two servers' is not enough.
  6. Execute the address move.Replicate a non-critical service between VPS and dedicated targets. Move the failover address in both directions, measure packet loss and full application recovery from external probes, and test reversion. Repeat when the source goes down uncleanly. Determine if automation or an API exists and whether the control plane remains available during network problems.
  7. Test state, not just reachability.Submit transactions before and after the move. Check database consistency, queues, TLS keys, sessions, cron tasks and monitoring. A ping that recovers in seconds may hide minutes of application recovery or lost writes.
  8. Get the DDoS envelope.Record protected prefixes, attack classes, detection and diversion timelines, included capacity, rate and packet caps, IPv6 treatment, clean path design, false positive response, blackhole rules, reporting and recourse. Use an authorised provider test or a table-top exercise. Never improvise a hostile traffic test.
  9. Reconcile BGP evidence.Ask why live collectors see AS35625 while the RIPE policy lists AS2027 and AS57199, and what the detected exchange session represents. Ask for current logical and physical diagrams, backup path activation criteria, route filters, RPKI and IRR maintenance, maximum prefix controls and emergency communities.
  10. Separate routed space from provider space.For each assigned address, identify the resource holder, status, usage right, RPKI origin and exit treatment. If a customer brings a range, define who maintains route and ROA objects, how quickly announcement changes happen, what happens at termination and how hijack or leak incidents are handled.
  11. Restore a backup.Do not accept 'backup available' as a test. Delete a non-critical service, recover it on another machine, verify integrity and record recovery time. Confirm encryption, retention, immutability, admin access, geographic separation and failure mode when the Rock-Hosting account itself is unavailable.
  12. Exercise support and suspension.Agree on severity definitions, contacts and identity checks. Open a timed ticket during service window and an agreed exercise outside hours. Walk through compromise, abuse complaint, false positive and emergency suspension scenarios. Determine whether data can be recovered after suspension and who can authorise reactivation.
  13. Secure the console.Require multi-factor authentication or an equivalent strong control, role separation, session and recovery protections, event logging and staff access governance. Export evidence of a reboot, reinstallation, reverse DNS change and failover action. Treat IP-KVM and password reset paths as privileged infrastructure.
  14. Complete the data protection file.Obtain the current privacy notice, Article 28 terms where applicable, subcontractors, locations, security measures, breach notification, audit provisions, return/deletion process and support access geography. Verify that the contract reflects the actual datacentre and upstream chain rather than a generic 'hosted in France' statement.
  15. Perform exit before scaling.Export the workload, restore it with another provider, renumber, update reverse DNS and measure data transfer time. Confirm cancellation, final billing, deletion and address release. Keep the runbook under customer control.

This sequence is deliberately stricter than clicking 'buy', but it is proportionate to the claim. Rock-Hosting's value is supposed to appear when something changes quickly: a machine fails, an address moves, an attack arrives or support must act. A pilot that never creates controlled change cannot evaluate the product.

What is worth watching

The first monitoring point is network maturity. AS207911 in its Rock-Hosting incarnation is young. A second independently visible upstream, a reconciled RIPE policy, a published looking glass, datacentre disclosure and clearer PeeringDB entries would make route control assessment easier. Prefix growth counts would matter less than evidence that filters, RPKI, incident response and customer routing procedures evolve with it.

The second is product documentation refresh. Consistent VPS bandwidth, current OS images, named virtualisation versions, a working status archive and a dated service schedule would remove several avoidable purchase questions. Updating the privacy address, analytics/cookie language and contract version would improve trust without changing a single server.

The third is continuity evidence. Rock-Hosting could publish anonymised failover distributions, DDoS incident summaries, restoration test successes, hardware replacement times and support response percentiles. None need expose customers or defensive thresholds. A small operator cannot match a hyperscaler's catalogue, but it can sometimes describe its own system more honestly and respond faster.

The fourth is datacentre and supplier concentration. The historical Iliad data centres phrasing should resolve to a current site and counterparty. Eurofiber's role should resolve to contractual path diversity and protection scope. The separate storefront hosted at OVH should have an explicit recovery path. Every dependency may be entirely sensible; the risk is in treating the chain as a single invisible 'French infrastructure' box.

Finally, watch the address boundary. The RapidSeedbox range is a useful demonstration that Rock-Hosting can emit third-party-held space, but it must remain labelled as such. Future customer routes, address leases or bring-your-own-IP services will make provenance, abuse handling, RPKI authority and exit rights more important, not less.

Control is the product only when it is visible

Rock-Hosting SASU is an honest subject for a technology company article. It is active, its storefront still offers genuine low-cost server plans, its corporate identity is linked to a current autonomous system, and routing evidence shows more than a decorative ASN. The provider can emit Rock-associated space and a third-party range, while presenting failover and DDoS protection as customer-side controls.

Its strongest idea is also its greatest burden of proof. A small host can compete with large-scale providers by making infrastructure controllable: a console, a known operator, an address that moves and a network that reacts. Yet every control stops somewhere. Address move does not replicate state. ASN does not own every route. RPKI does not secure every path. Anti-DDoS does not define a scrubbing capacity. A French company does not name the datacentre nor complete a data processing contract.

This does not make the proposition empty. It makes it testable. For a technically competent customer with modest workloads, external backups and a disciplined runbook, Rock-Hosting may offer a useful combination of low monthly cost and direct operational leverage. For a customer who needs audited multi-site continuity, formal response commitments or regulated assurance, the public evidence is only the beginning of the purchase.

The decisive question is not whether a €3.99 server is cheap. It is whether Rock-Hosting can show, under controlled failure, that its button, its route and its people move the customer's service — not just its IP address.