Summary
- VERYCLOUD SAS is no longer just a suggestive hosting name. French public records identify an active Paris company created in April 2025, the provider describes a transfer from an earlier project, and RIPE records connect the name to AS198825, which was already operating from 2023.
- The network footprint is unusually inspectable: five IPv4 and two IPv6 prefixes were visible from AS198825 on the evidence date, every observed origin had valid RPKI, and public routing records showed two upstream-side and two downstream-side neighbours. That proves a live routing role, not ownership of every address, physical path diversity or application availability.
- The service boundary matters more than the headline uptime figure. VeryCloud's terms put ordinary backups, operating-system administration, application maintenance and much recovery work on the customer unless extra services are bought. Its French-location claims are meaningful, but subprocessors, control systems, logs and safeguarded transfers still require a service-specific data map.
- Support is part of the product, not a decorative promise. Public terms offer round-the-clock tickets for VeryCloud infrastructure, while the review record contains both praise for fast setup and older complaints about service deletion. Buyers need ticket evidence, restoration tests and clear escalation ownership before treating a routed cloud name as operating assurance.
Start with the date mismatch
Cloud providers often present themselves as if the brand, company and infrastructure appeared at the same moment. VeryCloud's public chronology is more complicated and, because it is more complicated, more useful.
The French public company register records an active company called VERYCLOUD, legal form SAS, created on April 18, 2025. It gives the registered headquarters as 60 rue Francois Ier in Paris, the SIREN as 943 573 584, the headquarters SIRET as 943 573 584 00019 and the declared principal activity as wireless telecommunications. Those details establish a current legal counterparty. They do not show a decade-old cloud company. They show a young French company with a legible registration.
The infrastructure chronology begins earlier. VeryCloud's own history says the project started in 2023, obtained AS198825 and an IPv4 /24 that March, founded the SAS in April 2025 and transferred its activities to the company on April 26, 2025. RIPE's AS198825 record independently dates the autonomous-system entity to April 19, 2023. RIPE's organisation entity for VERYCLOUD SAS, by contrast, was created on April 29, 2025. The dates align with the provider's broad story: network first, company later.
That is not inherently alarming. Projects are regularly incorporated after an experimental or association phase. It is, however, a material diligence point. A customer should ask which assets, contracts, licences, support commitments, liabilities, monitoring records and customer data moved to the SAS. The website says activities transferred. The public sources considered here do not include a transfer agreement or a customer notice explaining its scope.
Chronology also changes how older market evidence should be read. A 2023 review describes the earlier project, not a service delivered by a company that did not yet exist. It may illuminate the brand's operational history, but it cannot automatically establish the current SAS's performance. Conversely, the SAS should not claim a longer corporate record merely because the domain and ASN are older. The honest formulation is that a two-year-old French company continues a hosting project and network identity that began in 2023.
The BTW directory profile is therefore a starting pointer rather than a complete identity. It identifies a private network infrastructure operator, but the company register, website and RIPE records provide the decisive connections: legal name, place, dates and network number. For a buyer, those connections turn a generic cloud brand into an attributable counterparty. They also expose the first unanswered question: what exactly continued across the 2025 boundary?
The catalogue is broad, but breadth is not integration
VeryCloud's public offer spans several technical and commercial models. Its terms name KVM virtual servers, dedicated bare-metal servers, shared web hosting, colocation, preconfigured game servers and network services. The website adds remote IP transit and anti-DDoS protection. A buyer can therefore encounter the same brand as a tenant of a virtual machine, an administrator of a physical server, a customer placing hardware in a facility or a network operator receiving routes through a tunnel.
Those are not minor variations of one product. They allocate control differently.
On a VPS, VeryCloud controls the underlying hardware, hypervisor and provider network; the customer normally controls the guest operating system, credentials, applications and data. On a dedicated server, the customer gains an entire machine and lower-level management access, but still depends on the provider for power, physical intervention and external connectivity. In colocation, the customer may own the server while depending on VeryCloud and the facility for rack access, power and cross-connects.
Remote transit goes further: the customer's equipment can remain elsewhere while routes and filtered traffic arrive through GRE, VXLAN or EoIP tunnels.
The remote transit page makes that last model unusually explicit. It advertises IPv4 and IPv6 BGP sessions, default or full routing tables, selectable prefix limits and contact from the team after an order is validated. The network is not merely a hidden ingredient behind web hosting. It is itself a sellable service boundary.
That breadth creates two traps. The first is assuming that a common brand implies a common service level. VeryCloud's contract sets a target monthly uptime of 99.99% for VPS and dedicated servers but 99.9% for shared hosting. A tunnel, a physical server and a shared account can also have different maintenance, capacity, backup and response arrangements. The order form and special conditions matter because the homepage cannot resolve every variation.
The second trap is assuming that common infrastructure creates a single point of accountability for the customer's whole system. VeryCloud's Terms of Sale say included support covers provider infrastructure and services: network, hardware, server availability and control panels. Unless a managed service is purchased, it excludes operating-system administration, customer-application maintenance, code debugging, optimisation and customer-data recovery. A web application can be unavailable while the server, network and control panel remain within contract.
This is the difference between a service catalogue and an integrated operating model. The catalogue says what can be ordered. The operating model says who watches each layer, who diagnoses a cross-layer failure and who is allowed to restore it. Buyers should map those responsibilities before they compare processor, memory or bandwidth figures. A cheap server can become an expensive ambiguity when an application fault crosses the boundary between provider infrastructure and customer administration.
Automation accelerates the ordinary case
The appeal of a small cloud provider is often immediacy. Select a plan, pay, receive credentials and start. VeryCloud's contract distinguishes automated services such as VPS and shared hosting, which it says are deployed within minutes after successful payment, from dedicated hardware and colocation options that may require manual provisioning. Its account holds subscriptions, billing and support. Its public documentation provides self-service guides. Together, those surfaces form a compact automation chain.
In the ordinary case, this chain removes labour. Payment confirmation can trigger account checks, resource allocation, address assignment, credential creation and a customer message. A virtual server appears without a technician assembling a bespoke order. Repeated tasks become consistent enough to sell at low entry prices.
But automation does not remove decisions; it moves them. Capacity has to be available on an appropriate hypervisor. The selected image has to boot. An address has to be assigned without collision or reputation surprises. Anti-fraud rules have to distinguish an ordinary buyer from misuse. A customer who mistypes an email address or loses an authentication factor needs a recovery path. Billing state has to remain aligned with service state so that a paid instance is not treated as expired.
VeryCloud's public pages show signs of this moving boundary. The VPS catalogue offers direct order links and repeated configurations. The dedicated-server page, captured at the evidence date, showed some configurations unavailable and one configuration in stock. It also displayed a zero-euro price for that configuration, which is plainly a reason to confirm the actual order rather than treat a rendered card as a contractual quote. Dynamic catalogue state can be useful; it can also expose incomplete data or a temporary publishing error.
The contract anticipates exceptions. VeryCloud reserves the ability to refuse orders after anti-fraud, identity, sanctions or availability checks. It says significant stock or hardware delays can lead to a substitute, postponement or refund. Credentials arrive through email or the customer area, and customers have a limited period to report non-conformity. None of this is unusual. It means the apparent one-click service is backed by a queue of exception work.
An enterprise buyer should test that queue before depending on it. How is a failed deployment identified? Does an automatically created ticket carry the payment and service references? Who can reverse a mistaken suspension? Is a manually provisioned order visible in the same account? Can administrators export a list of instances, addresses, owners, renewal dates and backup status? What audit trail exists for a rebuild or credential reset?
The best measure of automation is not how quickly the success case finishes. It is how safely the service returns to a known state after a partial failure. A provider can automate creation and still rely on fragile manual work for cancellation, migration, abuse review or recovery. VeryCloud's public record makes the front of the chain visible. A serious buyer needs evidence from the middle and end.
The contract reveals the real architecture
Marketing pages describe components. Contracts reveal responsibility.
VeryCloud's Terms of Service define the customer account, the hosted content and the service relationship. They say customers remain responsible for credentials, API keys and SSH keys, with two-factor authentication strongly recommended and mandatory for some sensitive services. Suspected compromise should be reported through a ticket, and the provider may suspend an account to prevent harm. This describes an identity boundary in which both sides have work to do: the provider runs the account system, while the customer governs who can use it.
The backup boundary is sharper. The Terms of Sale state that, unless a managed backup service is expressly purchased, the customer is responsible for backing up its data. VeryCloud may keep technical backups for continuity, but those are not promised as an on-demand restoration service. At contract end, the customer receives a grace period of up to seven calendar days to extract data, subject to payment, after which deletion may occur apart from legally retained records. Migration assistance can be quoted separately.
That language should change purchasing behaviour. A customer cannot safely infer that a provider's disaster-recovery plan includes recoverable copies of every unmanaged VPS. Infrastructure continuity and tenant-data recovery are different things. Redundant power may keep a hypervisor running; it does not protect against an administrator deleting a database. A provider may rebuild a failed node; that does not prove a customer's application state can be restored to the required time.
The SLA has similar limits. VeryCloud commits to target monthly availability, defines measurement and exclusions, and offers service credits when the threshold is missed. Requests must be made by ticket within 30 days. Credits are capped and are the normal remedy for an SLA breach. The provider's aggregate liability is also limited under the terms, while loss of data without a managed backup is excluded.
The point is not that these terms are uniquely restrictive. The point is that the operational architecture is divided. The provider promises certain infrastructure outcomes; the customer retains major responsibilities for content, system administration, application health and backup unless it buys more. A dashboard saying a server is online can therefore coexist with an unrecoverable customer error. A 99.99% network figure can coexist with a broken login service. A support ticket can be answered correctly with the conclusion that the fault sits outside included scope.
For an enterprise, the response should be a responsibility matrix tied to evidence. Each service needs an owner for the guest system, application, data, identity, DNS, certificate, monitoring, backup and restoration. The order should identify which VeryCloud options change those assignments. The customer should test a restore before production, not after loss. What looks like legal detail is actually the system design written in prose.
AS198825 is the strongest public proof
VeryCloud's most inspectable operating surface is its autonomous system. That matters because hosting brands can be little more than resellers. A visible ASN does not prove every service claim, but it gives the provider a public network identity that other operators can observe.
The RIPE entity for AS198825 names VERYCLOUD-SAS, associates it with the organisation record for VERYCLOUD SAS and records assigned status. Its routing-policy fields name AS62000 and AS174 for IPv4 and IPv6 import and export. RIPEstat's announced-prefix view, captured on July 15, showed seven routes visible throughout the returned July 1-15 interval: five IPv4 /24s and two IPv6 /44s.
The IPv4 set was 82.22.2.0/24, 82.22.7.0/24, 82.22.77.0/24, 82.26.157.0/24 and 151.242.39.0/24. The IPv6 set was 2a0c:b641:af0::/44 and 2a10:4646:2e0::/44. An independent BGP.Tools view showed the same five-and-two origin count and described the network as active.
Every one of those origin-prefix pairs returned a valid RPKI result at the evidence time. For the IPv4 routes, matching route-origin authorisations allowed a /24. For the IPv6 routes, they allowed more-specific announcements down to /48. Validity means the observed origin AS matched an authorisation. It is a meaningful hygiene signal because networks performing route-origin validation can distinguish these announcements from an unauthorised origin.
It is not a universal security verdict. RPKI validity does not show whether a route is reachable from every network, whether a router is correctly configured, whether traffic follows the intended physical path or whether an application answers. A valid route can still be withdrawn. A valid route can lead to a failed server. A leaked route can cause trouble even when origin information is correct. The right conclusion is narrow and positive: VeryCloud's observed origins were authorised at capture time.
The RIPEstat neighbour view also makes part of the routing shape visible. It showed AS174 and AS62000 on the adjacent upstream side, and AS197791 and AS198339 on the downstream side. BGP.Tools also displayed AS62000 and AS174 as upstreams. That independent convergence supports the claim that AS198825 is not an isolated record.
Yet neighbour visibility is not circuit evidence. Two ASNs can be reached over facilities, ports or physical paths that share risk. A routing collector does not reveal committed capacity, support obligations, traffic ratios or failover tests. Nor does it prove the website's claim that traffic will reroute in seconds after a carrier failure. A buyer that needs resilience should ask for topology at an appropriate level, failure-domain separation and the result of a controlled failover exercise.
The ASN therefore does something valuable but limited. It proves that VeryCloud participates in routing under its own number and originates a measurable set of addresses. It gives customers and outside operators a place to inspect routes. It does not turn network identity into end-to-end service assurance.
Originating addresses is not the same as owning them
VeryCloud's network site describes 1,280 IPv4 addresses in allocation, matching five /24s. That arithmetic is correct for the routes originated by AS198825. The registry records show why the word ownership would be too strong.
Four of the IPv4 records describe VeryCloud SAS, but their RIPE status is ASSIGNED PA, they point to another organisation entity and they are maintained under a third-party maintainer. Provider-aggregatable space is commonly delegated for use without becoming portable property of the end user. The fifth block, 151.242.39.0/24, is SUB-ALLOCATED PA and is described publicly as private-customer space. AS198825 originates it, but the VeryCloud network page itself does not present it as the company's own customer-address pool.
The IPv6 records also carry different lineages. The 2a0c:b641:af0::/44 record names VeryCloud SAS and its RIPE organisation. The 2a10:4646:2e0::/44 record remains under a separate organisation associated with the founder's name. Both were visible from AS198825 and both had valid origin authorisations. Operational use, registry assignment and legal control are related but distinct.
This distinction matters during migration or dispute. A customer may receive an address that remains part of a supplier's upstream allocation. It can work perfectly for years but be difficult to move. A customer announcing its own portable prefix through VeryCloud has a different exit position from one using a provider-assigned address. The remote transit page's references to portable IPv4 and IPv6 should therefore be resolved in the order: whose prefix, whose route object, whose ROA, whose geofeed and what happens at termination?
Address reputation adds another dimension. Hosting networks can inherit abuse histories from previous users of leased space. A technically valid route does not guarantee that every address is accepted by mail providers, threat feeds or third-party APIs. Customers should test the actual assigned addresses for their workload rather than infer reputation from the ASN as a whole.
VeryCloud deserves credit for publishing its prefix list and looking glass. That makes external checks possible. The more mature interpretation of those tools is not that the company owns a fixed block of digital real estate. It is that it coordinates a layered set of routing rights, assignments and customer routes. Assurance comes from keeping those layers documented, current and reversible.
DNS shows two delivery models
The public domain record links the brand's chronology to its network. AFNIC records show verycloud.fr was created on February 8, 2023, before the SAS, and remained active at the evidence date. Its name servers were operated by Cloudflare. Public DNS for the main site, www, the account manager, documentation and status names returned Cloudflare edge addresses in both IPv4 and IPv6.
That means a reader loading the website does not directly test AS198825. Cloudflare terminates the public edge and can absorb, cache or proxy traffic before it reaches an origin. The arrangement can improve resilience and security, but it separates brand reachability from the provider's own route visibility. Seeing the website through Cloudflare during an AS198825 incident would not prove customer servers were healthy. Failing to reach a Cloudflare-fronted page would not, by itself, prove the autonomous system was down.
Other names connect more directly. lg.verycloud.fr and lg.as198825.net resolved to 82.26.157.253, inside one of the /24s observed from AS198825. The mail exchanger for verycloud.fr was mail.as198825.net, which resolved to 82.26.157.251 in the same /24. These links provide practical evidence that at least the looking-glass and mail surfaces touch address space originated by the network.
The distinction is analytically useful. The public estate combines an external edge with direct network endpoints. This is normal hybrid delivery, but monitoring should reflect it. One check should observe the website as a user sees it through Cloudflare. Another should test the origin-side dependencies. Separate checks should cover the account area, DNS, mail, looking glass and customer services. A single green homepage cannot represent all those paths.
No DS record was returned for verycloud.fr in the July 15 snapshot. That is only a delegation observation. It does not mean DNS is unauthenticated at every layer, nor does it negate Cloudflare's other controls. It does identify a specific question: whether DNSSEC is intentionally undeployed at the parent, being introduced or considered unnecessary for this domain. For a company selling network services, a documented decision is more reassuring than an assumption.
DNS also places a limit on locality claims. An edge address belongs to the delivery network, not necessarily the origin country. A direct address reveals the route, not the physical server or database behind it. Buyers should use DNS as evidence of dependencies and control points, never as a complete data-location map.
French location is meaningful, but it needs a noun
VeryCloud repeatedly says customer data is hosted exclusively in France at Telehouse 3 in Magny-les-Hameaux. The contract is more careful: it says data is hosted in France by default and provides for regulated transfers outside the European Union where applicable. Those statements can coexist if they refer to different categories of data, but the categories need names.
Customer workload data on a VPS is one category. Account identity, invoices, payment tokens, support messages, abuse reports, security telemetry, monitoring events and provider backups are others. A French compute host can use an external payment processor. A ticket platform can process support metadata elsewhere. An anti-fraud system may evaluate account information through another subprocessor. A monitoring service can retain IP addresses and event timestamps outside the server's country.
VeryCloud's terms recognise the split. For customer data processed through hosting services, the customer acts as controller and VeryCloud as processor. For customer-relationship data such as registration, billing, support and security records, VeryCloud acts as controller. The provider says a data-processing agreement is available and that its subprocessor list is available on request. It also says customers will receive information about changes under the DPA.
That framework is more useful than a flag on a product card, because it asks who can act on each dataset. A buyer should request the DPA, current subprocessor list, locations, transfer mechanism, retention periods, deletion process and breach-notification route. It should ask whether managed backups stay in France, whether control-plane logs follow the same rule, and whether support personnel outside France can access customer systems.
The Telehouse page for Magny-Les-Hameaux independently confirms a substantial facility with redundant power, generators, UPS arrangements, guarded access and facility-level management certifications. That supports VeryCloud's claim that the named site exists and has serious physical controls.
It does not certify VeryCloud SAS. A tenant inherits benefits from the building but still has to configure its racks, credentials, network, backups and procedures. Facility guards do not prevent a customer administrator from deleting a virtual disk. Redundant power does not prove that a provider's recovery sequence has been tested. A facility certification may cover the operator's management system without covering every tenant process or customer workload.
Data sovereignty is therefore not achieved by saying France often enough. It is achieved by keeping decision rights, access, copies and exits attributable. VeryCloud's location is a credible and commercially relevant anchor. The remaining work is to attach each important noun to it: production data, backup, log, ticket, account, key and recovery image.
Availability needs a public memory
VeryCloud advertises 99.99% availability for VPS and dedicated services. Expressed over a 30-day month, that target permits only a few minutes of counted unavailability. But the contract, not the decimal, determines what is counted.
The terms exclude or separately treat planned maintenance, customer-caused faults and failures outside the provider's responsibility. They define measurement and service credits, and require a ticket within 30 days of an incident. This means customers need their own monitoring. Without a timestamped external record, it can be difficult to establish when a service became unavailable, which layer failed and whether the event met the contractual definition.
VeryCloud maintains a public status page, which is a positive accountability surface. At the evidence date, the live page exposed a VeryCloud monitor through HetrixTools. A search snapshot from the same period still described an older Uptime Kuma page with a longer component list. That apparent transition may simply reflect a monitoring redesign. It also shows why a status page should preserve continuity when tools change.
A useful public status service does more than display green or red. It defines components, records incident start and recovery times, distinguishes investigation from mitigation, and preserves post-incident summaries. Customers should be able to subscribe without joining a community chat. Maintenance should remain visible after it ends. A provider can redact sensitive details while still explaining the affected service, the broad cause, the restoration path and prevention work.
Public route data can supplement that history, but not replace it. RIPEstat showed all seven prefixes visible through the returned two-week interval. That supports route continuity at collector level. It says nothing about hypervisor failures, storage latency, account access, ticketing or a single customer's instance. Likewise, a green Cloudflare-fronted homepage does not prove the VPS estate is healthy.
The evidence hierarchy should therefore be layered. Global routing monitors observe prefixes. External probes observe ports and transactions. Hypervisor and storage monitoring observe infrastructure. Application checks observe the user's task. Tickets record impact and ownership. Restoration tests prove recoverability. Status pages communicate a curated version of those facts.
VeryCloud publishes the beginning of that hierarchy: routes, a looking glass and a public monitor. Before moving a critical workload, a buyer should ask for the rest in an appropriately confidential form: availability calculations, maintenance history, example incident communication, backup success, restore tests and escalation times. The purpose is not to catch the provider in a decimal error. It is to know whether both sides will recognise the same incident.
Customer reviews show the before-and-after problem
VeryCloud's Trustpilot page is larger than the sparse directory entry might suggest. On July 15 it showed 123 reviews, a 4.4 score, 82% five-star ratings and 11% one-star ratings, with 56 reviews in the preceding 12 months. The profile was claimed in August 2023, and Trustpilot said the company invites customers to review. It also said the company had not replied to negative reviews.
Those numbers are a market signal, not a performance audit. Trustpilot explicitly says it does not fact-check reviewer opinions, though it uses screening and may verify that an interaction occurred. Invitations can change who responds. A star distribution does not control for product, workload, customer skill, service age or incident severity.
The visible positive reviews nevertheless identify useful themes to test. Reviewers described fast provisioning, accessible documentation, a usable management surface and responsive support. Those observations align with VeryCloud's automation and support claims. They suggest that speed and human help are part of the provider's perceived value, not just processor specifications.
The visible negative reviews in the captured page were concentrated in 2023 and alleged deleted services and refund problems. One visible complaint was marked as verified. These are serious allegations from individual users, not established findings. Their date is equally important: they concern the early project, two years before the SAS was created. A fair assessment neither erases them nor attributes them mechanically to the later company.
The right question is what changed. Did the 2025 transfer bring clearer billing controls, deletion warnings, account records and appeal routes? Do current terms and the customer area prevent the failure pattern alleged in the older reviews? Has the provider begun preserving service-state and payment evidence well enough to resolve disputes? Does it respond privately through tickets while leaving public reviews unanswered, or is negative feedback going unaddressed?
Recent positive volume may indicate improvement, but a score cannot answer those process questions. The company could strengthen assurance by responding to substantive negative reviews without disclosing customer data, publishing the lifecycle for suspension and deletion, and recording how paid-state disputes are escalated. Customers can also protect themselves by keeping invoices, renewal notices, ticket exports, service identifiers and independent backups.
Reviews are most useful when they produce a test. Fast provisioning can be tested with a low-risk instance. Support quality can be tested with a technically specific pre-sales question. Cancellation can be tested before a critical renewal. Data extraction can be rehearsed. Older deletion complaints should lead to an exit drill, not a verdict based on a handful of posts.
Support labour is the hidden capacity limit
VeryCloud promises technical support 24 hours a day, seven days a week through customer-area tickets, with email or chat in some cases. Its dedicated-server page also promotes French-speaking support through tickets and Discord. The contract narrows included work to the provider's infrastructure, hardware, network, server availability and control panels.
This is a sensible boundary. It also means a small number of skilled people may sit at the point where many product lines converge. A ticket about an unreachable application can require knowledge of billing state, hypervisor health, address assignment, route visibility, filtering, guest configuration and customer history before the responder can locate responsibility. Automation may open and route the case, but diagnosis is human work.
Round-the-clock access is not the same as round-the-clock depth. The public record does not show the current support headcount, shift pattern, language coverage, first-response distribution or escalation roster. It does not say whether the person answering a Discord message can make a router change, authorise a refund or replace hardware. It does not disclose how simultaneous incidents are prioritised.
For ordinary customers, Discord can be useful. Community members answer simple questions, and a visible team can make a small provider feel accessible. For security, billing and service-state decisions, the ticket should remain authoritative. Chat messages can be edited, lost in volume or seen by the wrong audience. A ticket can carry account identity, timestamps, attachments and escalation status in a controlled record.
Local labour also matters at the facility. A remote responder can inspect telemetry, but failed hardware, cabling and power feeds may require hands in Magny-les-Hameaux. The division between VeryCloud staff, contractors and Telehouse personnel determines who can enter the space, replace a component and confirm recovery. A promise of human support should connect those roles rather than leave the customer to coordinate them.
Before a critical deployment, buyers should ask operational questions that reveal capacity without demanding personal information: What is the response objective by severity? Who can declare a major incident? Is there an on-call network engineer? How are hardware interventions requested? Does support retain a full ticket history? Can a customer name multiple authorised contacts? Is there an emergency path if the account portal is unavailable?
The answers matter because VeryCloud sells both automation and intervention. Servers can be created automatically, but exceptions accumulate around billing, abuse, migration, routing and recovery. The product is dependable only if the human queue has enough authority and time to resolve those exceptions.
A buyer should price the exit, not just the entry
VeryCloud competes with attractive resource bundles and a French hosting story. The visible monthly price is only one part of the commercial decision. The real cost includes administration, backup, monitoring, address portability, incident work and migration.
An unmanaged VPS transfers substantial labour to the customer. Someone must patch the operating system, secure SSH, monitor disk space, renew application certificates, test backups, respond to abuse reports and diagnose software failures. VeryCloud can provide a healthy virtual machine while the customer's service remains vulnerable through neglected administration. A low server bill can be rational if the buyer already has that capability. It is misleading if the missing labour is treated as free.
Backup economics are especially easy to underestimate. The contract excludes ordinary restoration without a managed option, and end-of-contract export assistance may be chargeable. A buyer should price independent copies, storage, transfer, retention and restore testing. It should know how long a full export takes and whether the service remains writable during migration. Seven days of post-contract grace may be enough for a prepared customer and dangerously short for an untested one.
Addressing also affects exit cost. Workloads tied to provider-assigned IPv4 addresses may need DNS changes, allow-list updates, reputation warming and customer communication when moved. Portable prefixes and BGP sessions can reduce some dependencies but add routing expertise, registry work and security obligations. Remote transit can preserve addresses across a hosting change only if the customer actually controls the relevant resources and the replacement path is ready.
The French data-location proposition has a price too. It may simplify procurement for customers seeking a domestic facility and familiar legal venue. It does not remove the need to assess subprocessors or build recovery outside one failure domain. A customer that requires geographic resilience may need a second French site, another European region or an independent backup location, depending on policy and risk.
Finally, contract remedies have economic limits. SLA credits compensate part of a monthly fee; they rarely match the business cost of an outage. Liability caps and exclusions mean the customer remains the insurer of many consequences. Criticality should therefore determine architecture. A hobby server can accept a simple arrangement. A revenue system may need multi-provider DNS, replicated data, portable configuration, external monitoring and a tested runbook.
VeryCloud may still be the economical choice after those additions. The point is to compare complete operating costs. Entry pricing answers what it costs to start. Assurance pricing answers what it costs to remain recoverable and to leave.
What stronger proof would look like
The public record already supports several conclusions with confidence. VERYCLOUD is an active French SAS. It presents a coherent service catalogue and current legal terms. AS198825 is active and visible with IPv4 and IPv6 origins. Route-origin authorisations were valid at the evidence date. Public DNS connects the brand to both Cloudflare-fronted services and direct addresses in AS198825 space. The named Telehouse facility is real. A non-trivial customer-review record exists.
The next level of assurance does not require the company to publish sensitive diagrams. It requires evidence that can be shared with a buyer under appropriate terms.
For identity and continuity, that means a clear account of the 2025 transfer, the contracting entity on invoices, and current insurance and financial standing where relevant. For services, it means a definitive order description that overrides transient catalogue cards. For network resilience, it means intended prefixes, current ROAs, dependency ownership, physical failure domains and recent failover results.
For data, the buyer needs the DPA, subprocessor list, per-service locations, access model, encryption and key ownership, retention, deletion and backup design. For availability, it needs the SLA calculation, recent measured performance, maintenance history and an example of incident communication. For recovery, it needs evidence that backups are monitored and restorations have completed within the required objective.
For support, the useful measures are not slogans but distributions: first response by severity, time to technical ownership, time to restoration, reopened cases and unresolved escalations. A small provider need not operate a vast call centre. It does need to show that urgent work reaches someone authorised to act.
The customer has reciprocal obligations. It should maintain accurate contacts, secure its account, patch what it administers, classify its data, keep independent recovery material, monitor transactions and submit timely tickets. The provider cannot restore a workload it was never contracted to back up. The customer cannot diagnose a network it cannot observe. Assurance is a set of joined responsibilities, not a badge purchased at checkout.
VeryCloud's public evidence is strongest where internet operations are naturally public: ASN registration, route origins and DNS. It is weaker where service outcomes are private: incident handling, storage recovery, support capacity and customer configuration. That pattern is not unusual. It is exactly why a buyer should use the strong public evidence to ask better private questions rather than treating the absence of public detail as either proof of failure or permission to assume success.
A routed name, not a finished verdict
VERYCLOUD SAS has more behind it than the thin directory label initially reveals. There is an active French company, a published transition from an earlier project, a defined contract, a real facility claim and a network that can be observed from outside. AS198825 originates five IPv4 and two IPv6 prefixes, with valid route-origin authorisations at the evidence date. That is substantial proof for a young provider.
It is proof of identity and network participation. It is not proof that every workload will remain available, every byte stays within one jurisdiction, every backup is restorable or every urgent ticket reaches the right engineer. The public product pages sometimes compress distinctions that the contract restores: infrastructure continuity versus customer recovery, French hosting versus the wider processor chain, 24/7 access versus included administrative scope, and a target uptime versus a customer's actual remedy.
The mixed market record reinforces the point. Recent reviewers often praise speed and support, while visible complaints from the earlier project raise questions about deletion and payment state. Neither side should be turned into a universal story. The provider's current controls should be tested against the failure modes the older record exposes.
For a prospective customer, the sensible sequence is straightforward. Verify the SAS on the order. Identify the exact service boundary. Confirm the address and routing model. Request the DPA and subprocessor list. Decide who owns every backup and restore. Monitor from outside. Put security, billing and incident communication in tickets. Rehearse migration before it is urgent.
That sequence does not diminish the value of VeryCloud's network. It puts the network in its proper place. A visible ASN is a better foundation than an anonymous reseller identity. Valid RPKI is better than ambiguous origins. A public looking glass is better than asking customers to trust a diagram. These are signs of an operator willing to expose part of its work to scrutiny.
Operating assurance begins after those signs have been read correctly. It emerges when legal identity, routes, contracts, data controls, status records, recovery tests and human authority point to the same service. VERYCLOUD SAS can already be identified and observed. The remaining question for each buyer is whether the private evidence behind a specific order is as coherent as the public network name.