The €10 Server and the Invisible Supply Chain: What CLOUDWEB LAYER S.R.L. Actually Controls

Summary

• CLOUDWEB LAYER S.R.L. is the current legal operator named on NeoServer.ro, and the same company is the registered organisation behind AS203942. That establishes the required bridge, but NeoServer, Hostsrc, AS203942, OVH and Voxility remain distinct operational surfaces.
• The company controls product configuration, resource limits, the Pterodactyl environment, provisioning, support workflow and the use of its own address space. It does not by itself control upstream fibre, a supplier’s physical server, a third-party scrubbing platform or the quality and security of customer-installed game software.
• Public product pages state attractive chip names, NVMe storage, included backups, gigabit connectivity and DDoS filtering, yet they do not disclose several variables that determine real performance: CPU share or pinning, node occupancy, disk contention, usable bandwidth, protection policy, recovery objectives or a contractual availability commitment.
• AS203942 provides meaningful network-resource evidence: one active IPv4 /24, a valid route-origin authorisation and visible upstream connectivity to OVH. It is not evidence of broad route diversity, and it may not be the path used by every NeoServer product.
• A serious buyer should treat a low monthly price as the start of diligence, not the end. The decisive procurement test is a written, workload-specific schedule covering node resources, test IPs, DDoS behaviour, support escalation, backup isolation, data export and the exact remedy for failure.

Start with the first ninety seconds of trouble

Imagine a Counter-Strike community at 20:00 on a Friday. Thirty players join, voice chat fills, the server begins missing ticks and two players report packet loss. The administrator opens the panel and sees memory below its limit. The machine’s advertised processor name still looks excellent. A support reply has not yet arrived. Is the fault an overloaded game plugin, contention on a shared CPU core, storage latency during a backup, a route from one Romanian access provider to Frankfurt, or a DDoS filter learning the difference between attack traffic and a legitimate burst?

That is the moment when the meaning of a hosting order becomes clear. A buyer has not purchased a single, indivisible thing called “performance.” The purchase combines at least six different services. CLOUDWEB LAYER chooses a package and places a workload on a node. Pterodactyl gives the customer a console, file access and controls. A physical-server supplier provides the machine and its local connection. One or more networks carry the packets. A mitigation supplier may inspect or discard suspicious traffic. The customer selects, configures and updates the game, plugins, maps and credentials.

Each layer can make the same symptom—lag, disconnection or an unavailable service—appear at the player’s screen.

NeoServer’s own pages make several parts of this chain visible. The home page says most servers run on dedicated machines from OVH, with Germany, described as Frankfurt, as the principal location. It names Pterodactyl as the panel, advertises gigabit connectivity, included DDoS protection of up to 1 Tbps at the filters and a support intervention time of no more than 25 minutes. Product pages place some workloads in Germany and others in Bucharest. The FiveM page specifically names Voxility protection for its Bucharest offers. These are useful disclosures. They are also claims made by the seller, not measurements or a complete contract.

The distinction matters because a capacity figure at a scrubbing network is not the throughput reserved to one game server. A chip’s peak boost frequency is not a dedicated core. “Backup included in the panel” does not say whether the copy survives loss of the node. “24/7 support” does not say whether the person responding can change a route, tune an upstream filter or replace a failed supplier machine. A buyer therefore needs to translate each headline into an accountable control, a metric and evidence.

The strongest reading of CLOUDWEB LAYER is not that a small Romanian host must own every component. That would be economically unrealistic. Its useful role is orchestration: selecting suppliers, configuring the service, monitoring the boundaries, answering one ticket and making the chain legible to the customer. The risk is not supplier use itself. The risk is a gap between a simple retail promise and a complex delivery chain.

The identity bridge is real, but the names are not interchangeable

The legal and operating bridge can be established without guessing. NeoServer’s current contact page names CLOUDWEB LAYER S.R.L., gives Romanian fiscal identifier 50562595, trade-register number J2024023332005 and a Bucharest address. Its legal page repeats the same company, identifiers and address in the privacy and service terms. That is direct first-party evidence that the assigned company is the present contracting and data-handling entity presented by NeoServer.

Independent Romanian company-data services corroborate the identifiers. Risco records incorporation on September 18, 2024 and the main activity as data processing, web hosting and related activities. It reports zero turnover, a RON 6,343 loss and no average employees for 2024. Firmeo gives the same fiscal and registration numbers. Those first-year figures are a scale signal, not a current headcount. A newly incorporated company may have had only a partial first reporting period, may use contractors or affiliated operations and may have changed materially by 2026. A buyer should not turn an old filing into a claim that nobody operates the service today.

The network bridge is equally direct. The RIPE Database aut-num record for AS203942 points to organisation ORG-CLS16-RIPE, and the organisation record gives the exact name CLOUDWEB LAYER S.R.L. The registered description says the network is designed for game servers and edge workloads. The route record connects 81.181.244.0/24 to AS203942. This proves that the company has a recognised network-resource role, not merely a reseller landing page.

It does not make every public name equivalent. NeoServer is the retail brand and website through which the researched offers are presented. The NeoServer home page now carries a notice that it is part of Hostsrc. Hostsrc has a separate public site describing instant, credit-based game-server use. AS203942 appears as “HOSTSRC” in the self-submitted PeeringDB entry, while the PeeringDB organisation is CLOUDWEB LAYER. The NeoServer privacy text uses hostsrc.com contact addresses. Together, these facts show an operating connection, but they do not supply a public corporate-ownership chart or say that every Hostsrc commercial term governs a NeoServer subscription.

The safe conclusion is narrow: CLOUDWEB LAYER is the present legal operator identified by NeoServer and the resource holder behind AS203942; NeoServer and Hostsrc are public service names associated with that operator. A buyer should still put the legal company name, fiscal number, service name, location and governing terms on the order. This is especially important because the NeoServer brand appears to predate the company: the site claims a 2020–2026 copyright period, while the company was incorporated in 2024.

The sources reviewed here do not establish the earlier ownership chain, so historical businesses should not be silently folded into CLOUDWEB LAYER’s record.

The customer portal illustrates why this precision matters. Its network-status URL is login-restricted rather than a public history of nodes and incidents, and the visible footer carries a different company name. There is not enough evidence to treat that other company as the same operator. The reasonable procurement response is not an accusation; it is to ask CLOUDWEB LAYER to confirm in writing which legal entity invoices the service, which terms apply and which status surface is authoritative.

The price buys an allocation, not the processor printed beside it

NeoServer prices its game hosting in familiar retail units: a monthly amount, a player or memory tier and a list of included features. The CS2 page advertises 14 slots for €12 a month, 24 for €16 and 32 for €20, all in Germany, and associates them with an AMD Ryzen 9 9950X3D, NVMe storage, Pterodactyl, two MySQL stores, DDoS protection and a panel backup. The CS 1.6 page offers 14, 24 and 32 slots for €10, €15 and €20 on a Ryzen 9 5900X in Germany. The Minecraft page offers several server types at €5 a month with 4 GB of memory, 30 GB of NVMe storage and an Intel Core i9-9900K in Bucharest. FiveM tiers run from €5 for 2 GB to €16 for 8 GB, also in Bucharest.

The low prices are commercially plausible because the customer is generally not renting the whole named machine. One physical node can run many isolated game processes, and demand is uneven: communities peak at different hours, some servers sit empty and some packages use little CPU even when their memory remains allocated. The operator turns a lumpy dedicated-server bill into smaller recurring subscriptions. Pterodactyl is free and open source, reducing the licence cost of the retail control layer. Automation reduces provisioning work. Upstream DDoS protection may be bundled into the physical server or bought at network scale.

These are the basic economics of the offer.

But the product page does not reveal the denominator. A Ryzen 9 9950X3D name says which processor may be in the node; it does not say how many customer servers share it, whether a customer receives a fixed core, a fraction of a core, relative priority or access to spare cycles. AMD describes 5.7 GHz as a maximum boost for the Ryzen 9 9950X3D, and AMD’s own explanation says boost is the maximum frequency achievable during a bursty workload. Intel likewise lists 5.0 GHz as the maximum turbo frequency of the i9-9900K. Neither number is a promise that a customer process will sustain that clock, or even remain scheduled on one physical core.

The distinction can be expressed precisely because NeoServer says it uses Pterodactyl, and Pterodactyl says it runs game servers in isolated Docker containers. Docker’s official resource-constraint documentation explains that CPU shares are relative weights when cycles are contested, while CPU quotas can impose a ceiling. Shares do not reserve a particular amount of CPU. Docker also supports core pinning and memory limits. The host therefore has several legitimate ways to sell “CPU,” with very different consequences during a busy evening.

For a latency-sensitive game, the useful disclosure is not only the chip. It is the scheduling rule: the CPU limit expressed in cores or quota; whether the limit is a reservation or merely a maximum; whether cores are pinned; whether simultaneous multithreading siblings are sold separately; the maximum number of comparable game instances per node; and what evidence triggers migration from a congested node. Disk disclosure should similarly include whether NVMe is local or networked, whether it is mirrored, the per-service storage quota, I/O limits and what happens when a neighbour performs a large backup.

Memory is easier to count but not automatically easier to guarantee. A hard 4 GB container limit can be genuine, yet the node can still suffer if the aggregate commitments exceed physical memory or if a game is killed when it crosses the cap. A buyer needs to know whether swap is enabled, how out-of-memory events are reported and whether the package includes enough headroom for the selected game build. “Unlimited slots” on FiveM or Minecraft is a commercial label, not an engineering capacity statement. Player capacity depends on scripts, entity counts, map state, plugins, tick rate, network packets and the CPU time actually delivered.

The product pages also contain signs that the catalogue is changing. The home page’s general infrastructure text names older processors while the CS2 page names a 9950X3D. The home page has at times labelled Minecraft and FiveM as coming soon at prices that differ from live detail pages. This is normal in a small, evolving catalogue, but it makes the order confirmation important. A buyer should retain a dated copy of the exact product page and obtain confirmation that the product-specific hardware, location and limits prevail over generic marketing text.

Pterodactyl makes control visible, not complete

The control panel is the most tangible part of the purchase. NeoServer says customers receive an emailed password after payment and can use Pterodactyl for console access, allocated-resource statistics, reinstalls, backups, additional users, logs and start commands. Its FAQ adds SFTP access and two MySQL stores. This gives a community administrator much more useful control than a simple “start server” button.

Pterodactyl’s architecture matters. The project describes the Panel as the user interface and its node component, Wings, as the server control plane. Game processes run in Docker isolation. Wings includes an SFTP service, which explains how a host can expose files without granting a customer access to the physical machine. This boundary lets CLOUDWEB LAYER decide resource limits, images, ports and allowed actions while the customer manages the game directory and console.

The panel can therefore provide evidence about immediate consumption. A graph may show memory use, a console may reveal a plugin exception, and an activity log may show who restarted a server. Yet a panel graph cannot on its own show physical-node occupancy, the duration of CPU scheduling delays, upstream packet loss or whether a backup lives in another failure domain. It is an observability window chosen by the operator, not an independent account of the whole service.

This creates a practical division of responsibility. CLOUDWEB LAYER should maintain the Panel and Wings, patch the operating system, configure container isolation, allocate resources, protect administrative interfaces, manage node capacity and ensure that panel actions correspond to the billed service. The customer should protect its password, limit sub-user permissions, maintain game and plugin software, review logs, test changes and keep a portable copy of valuable worlds and configuration. Pterodactyl supplies useful controls to both sides, but it does not decide whether either side uses them well.

Patch transparency deserves special attention. Pterodactyl remains actively maintained. The project’s release history shows security fixes in recent releases, including changes to remote-node access scope and revocation of SFTP sessions after password changes or account deletion. This does not show that NeoServer runs an affected or outdated release; its installed version is not publicly disclosed. It does show why a buyer should ask for the current Panel and Wings versions, the patch target after a security release, multi-factor authentication support and the last successful restore test.

Backups are the clearest example of a control whose label can conceal different outcomes. “Included in the panel” may mean a customer can create a local archive on the same node. It may instead mean an entity-storage copy in another facility. Pterodactyl can support both local and S3-compatible storage, but the product page does not state NeoServer’s choice. A local backup is convenient for reversing a bad plugin update; it may be useless if the node’s storage fails or all files are deleted after account termination.

The buyer should ask where backups reside, who can delete them, retention and frequency, whether MySQL is captured consistently, whether copies are encrypted and how long a measured restore takes.

AS203942 is evidence of control, not evidence of universal reach

An autonomous system gives a network operator a recognised identity in interdomain routing. It can originate approved prefixes, express routing policy and choose upstream relationships. For CLOUDWEB LAYER, that is more substantial evidence than a generic “low latency” badge.

The RIPE records show that AS203942 was created on November 7, 2025 and assigned to ORG-CLS16-RIPE. The company’s IPv4 block, 81.181.244.0/24, contains 256 addresses and has a route object naming AS203942 as origin. RIPEstat’s announced-prefix view showed that /24 active at the evidence freeze. RIPEstat routing history recorded AS203942 originating it from November 8, 2025 through the current observation window with high collector visibility. RPKI validation returned valid, with a route-origin authorisation covering the exact /24 and origin.

Those are positive controls. A valid route-origin authorisation enables networks that perform RPKI origin validation to reject an unauthorised origin for that prefix. A properly maintained route object helps filtering. A dedicated abuse contact and meaningful reverse DNS can help the company investigate misuse and maintain address reputation. The company can decide which customer receives which address and can work with providers on routing changes.

The visible topology is small. The RIPE aut-num policy lists imports from OVH’s AS16276 and Romania’s AS39383. A registered import statement expresses intended or permitted policy; it does not prove that both paths carry production traffic. At the freeze, RIPEstat’s neighbour data showed AS16276 on the observed upstream side. BGP.tools, IPinfo and CIDR Report also observed one originated IPv4 /24 and OVH as the visible upstream. PeeringDB did not list a public exchange port or looking glass.

For the /24, this is evidence of a functioning stub network with one currently visible upstream, not a demonstrated multi-transit design. That is not inherently unsuitable for inexpensive game hosting. OVH is a large supplier, and a single commercial path can be stable. It does mean that CLOUDWEB LAYER should not market the registered second import as active resilience unless it can show traffic, failover tests and distinct physical paths.

There is another important limit: AS203942 may not carry every NeoServer customer. The site says most servers are on OVH dedicated machines. Such machines can use OVH-assigned addresses originated directly by OVH rather than CLOUDWEB LAYER’s /24. The FiveM page names Voxility for Bucharest filtering, which may involve a different address and routing arrangement. A buyer cannot infer its path from the company ASN alone. It must obtain a test address for the exact product, location and protection tier, then verify the origin and route before ordering and again after provisioning.

Location labels require the same care. IPinfo’s point-in-time view placed the measured AS203942 address footprint in Germany and showed a very short trace from a Frankfurt probe. That is consistent with the site’s German hosting claim, but geolocation is not proof of a particular building and one nearby probe is not a latency study. “Frankfurt” may describe the service region while OVH’s exact facility is elsewhere in the wider route. The order should name the facility or at least the supplier region, and the buyer should measure from the networks where actual players connect.

RIPE Atlas offers a reproducible route to that evidence. Its measurement network can run pings and traceroutes from selected vantage points. A Romanian community could test from probes on Digi, Orange and Vodafone; a regional tournament could add Hungary, Bulgaria, Germany and the Balkans. Measurements should run at quiet and peak hours and record median and tail latency, packet loss, route changes and mitigation periods. CLOUDWEB LAYER can control its placement and routing choices, but it cannot control every access provider between a player and the server.

DDoS protection is a policy and an escalation path, not a capacity slogan

Game services are unusually exposed to denial-of-service attacks. Public server addresses are easy to discover, communities have rivalries, and many games rely on UDP. A flood can saturate the host or an upstream link before a local firewall has a chance to help. Cloudflare’s explanation of a UDP flood notes that sufficiently large traffic can overwhelm a firewall’s state capacity and make server-level mitigation irrelevant because the bottleneck is upstream.

NeoServer acknowledges the risk and repeatedly says protection is included. Its home page advertises filters able to handle up to 1 Tbps. The FiveM packages specifically say “Voxility”; German products are described as running mostly on OVH dedicated machines. This points to at least two possible protection chains.

For an OVH-hosted service, the capabilities depend on the actual dedicated range and its configuration. OVH’s official Game DDoS Protection guide distinguishes general infrastructure protection, focused mainly on layers 3 and 4, from a game-aware application firewall. The specialised protection is available only on eligible Bare Metal Game servers. It requires rules for each protected address and game protocol, and OVH recommends a default-deny policy. The guide also warns that some Eco ranges may lack or limit the feature and tells customers experiencing false positives to provide traffic captures for tuning.

That detail turns a procurement question into a binary test. Is the NeoServer node an eligible OVH Game server, with the relevant address showing configured Game protection, or merely an OVH dedicated machine with general anti-DDoS coverage? If it is eligible, which game rule and ports are configured, who owns access to the OVH control surface, and can CLOUDWEB LAYER obtain mitigation telemetry and tuning? If it is not, the seller should state exactly what the included protection covers.

For the Bucharest FiveM offer, Voxility’s own anti-DDoS description offers several delivery methods: protected dedicated servers, a secure uplink and tunnels for networks with their own ASN. Voxility says traffic can be redirected to its mitigation cloud on detection and that customers can obtain attack reports through its dashboard. It also says DDoS protection on rented servers is an extra option rather than an automatic property of every server. NeoServer’s product page is the evidence that it claims the option for those packages; a buyer still needs the address-specific proof.

The 1 Tbps language should be read as supplier-platform capacity claimed at a point in time, not a reservation. Even a large scrubbing estate can produce a poor game outcome if the wrong protocol rule is selected, legitimate bursts are classified as hostile, the clean-traffic link is too small, the protected address changes, or escalation is slow. Conversely, a well-tuned service can handle an attack far larger than the game server’s normal traffic without dedicating a terabit to that customer.

The most useful DDoS schedule would answer ten questions. Is filtering always on or triggered? Which layers and game protocols are covered? What are the normal port rules? What clean-traffic bandwidth reaches the node? Are packet-per-second limits separate from bit-rate limits? Is there automatic null-routing, and at what threshold? How quickly can a human tune false positives? What telemetry does the customer receive? Does mitigation change the route or add latency? Is a new address offered after repeated attacks, and what happens to reputation and DNS when it changes?

Public guidance supports this operational view. The joint CISA, FBI and MS-ISAC DDoS response guidance tells organisations to recognise latency and unavailability, contact providers, gather timestamps and packet evidence, activate mitigation and document roles. A protection claim is credible when those actions have named owners. CLOUDWEB LAYER can monitor the customer service, preserve evidence, contact OVH or Voxility and communicate status. The supplier controls its scrubbing platform. The customer must report affected ports, preserve game logs and avoid interpreting every CPU spike as an attack.

IP reputation follows the address, but behaviour determines much of it

A game server needs more than reachability. Its address may be checked by server browsers, community lists, payment services, messaging platforms and security products. NeoServer’s legal page says that an address banned by certain boosting or monitoring services will be changed only with the owner’s understanding. That clause is a quiet admission that an address has history and that replacement is neither automatic nor always the correct cure.

CLOUDWEB LAYER can influence reputation through customer verification, abuse handling, egress controls, reverse DNS, clean address assignment and rapid response to compromised servers. Its /24 and abuse role give it a defined surface on which to do that. It cannot guarantee that every third-party list will accept an address, and it cannot keep a customer’s exposed plugin from being compromised.

Spamhaus explains in its IP reputation overview that reputation draws on the provider, the surrounding address range, upstream infrastructure, when an address appeared and how it was used. That is why moving a legitimate customer to another address without fixing a compromised plugin merely transfers the problem. It is also why a buyer should test the assigned address before launch, document any prior listings, confirm reverse DNS rights and agree who handles delisting.

One third-party page recorded two reports against an address in the company’s /24 with only 5% confidence. That is too little to establish malicious conduct by CLOUDWEB LAYER or even by the current user of that address. It is enough to illustrate why crowd-sourced reports must be treated as leads rather than verdicts. The meaningful evidence is a current, address-specific check across several reputation services, the host’s response to a sample abuse ticket and whether the customer can receive a clean replacement when prior use materially blocks the intended service.

Support is where the layers are reconciled

Small hosts often compete less through novel hardware than through attention. NeoServer advertises round-the-clock support and a maximum intervention time of 25 minutes. The contact page offers live chat for lower-level issues, messages, telephone help and a client area. The legal page says the safest route for technical assistance is a ticket and warns customers not to rely on social-media messages. That is sensible: a ticket creates an identifiable service, timestamps, attachments and an escalation trail.

NeoServer names WHMCS as the ticket platform. WHMCS’s support documentation shows why this can be useful: tickets can carry priorities, associated services, staff assignment, private notes, notifications and a log of changes. The software can structure work; it does not supply staffing or technical authority. A 24-hour ticket desk can still depend on one person for routing changes, and a fast first reply may not be a fast restoration.

The advertised “intervention” time needs a definition. Does it mean an acknowledgement, first diagnostic action, escalation to the physical supplier, or restoration? Is it measured every hour and every day? Which ticket priority qualifies? Is there a remedy if it is missed? No public service-level schedule reviewed here answers those questions. The buyer should not translate the phrase into a 25-minute recovery promise without a written commitment.

Incident transparency is similarly limited. The public network-status URL requires login and does not expose a historical availability graph or post-incident reports. No authoritative public incident archive for the current company was found in the frozen evidence. Absence of a public report is not evidence of an incident-free history. It means an outside buyer cannot calculate availability or mean restoration time from public material.

The company’s 2024 filing signals why continuity diligence matters, without proving a current weakness. A young operator can provide excellent hands-on service, but key-person dependency, supplier credit, documentation and on-call depth deserve examination. The most revealing questions are concrete: How many people can access OVH, Voxility, routing and Pterodactyl during an incident? Are credentials and procedures available if one administrator is unavailable? Who receives monitoring alerts? When was failover or bare-metal recovery last exercised? Does the company maintain a supplier escalation path outside its own ticket system?

A buyer can test support before entrusting a community. Ask a technical pre-sales question that crosses boundaries: request the exact CPU quota, test address, route origin, DDoS rule, backup location and escalation route. A good answer may take time, but it should be precise and should identify uncertainty. Then open a low-priority ticket after provisioning and retain timestamps. During a trial, deliberately restore a small backup, change an SFTP password, add a restricted panel user and ask for a route check. These actions reveal more than a generic support badge.

The support boundary in NeoServer’s terms is unusually explicit: help covers host and connectivity problems, while game modes and add-ons receive at most limited assistance. NeoServer says it is not responsible for providing client-side software and will not edit customer files without agreement. That is a reasonable separation, but it means a community without its own administrator is not buying a fully managed game operation. It is buying infrastructure and a panel with constrained application help.

Billing automation can become a continuity event

At €5 to €20 a month, the largest immediate risk may not be hardware failure. It may be a missed invoice. NeoServer’s legal terms say invoices arrive seven days before the due date, a reminder follows three days before, and the service is automatically suspended three days after the due date. They then say all files are deleted three days after suspension and that a customer suspended for non-payment may not request backups.

That is a short path from an expired card or missed email to loss of a game world. It also shows why the panel backup cannot be the only recovery copy: access to the same account can disappear exactly when the customer needs it. A community administrator should treat billing contacts, renewal dates and off-provider exports as production controls.

WHMCS can implement this chain. Its automation settings include invoicing, overdue notices, automatic suspension and termination after configured numbers of days. Its provisioning documentation also explains how payment can trigger service setup. The presence of automation does not prove NeoServer’s exact configuration, but the public terms state the outcome the company intends.

The refund language also deserves written clarification. NeoServer says game-server refunds take seven to fourteen days, are available only for PayPal payments and only when the service was non-functional; card, bank-transfer and certain other payments are described as non-refundable. European consumer rules can depend on whether the buyer is a consumer or a business, whether service began immediately and what information and consent were provided. EUR-Lex’s summary of distance-contract rights describes a general fourteen-day withdrawal right for many service contracts subject to exceptions. This article cannot resolve an individual contract. It does make payment method, withdrawal information, failure definition and data return valid pre-purchase questions.

There are four practical protections. Use a role email monitored by more than one administrator. Keep a payment method and a calendar alert independent of WHMCS. Export game files, configuration and MySQL content on a schedule to storage under the community’s control. Test rebuilding on another host before an emergency. The final step converts portability from a hope into a measured recovery time.

Security and compliance divide at the game directory

The customer account contains names, email addresses, payment records, IP addresses and support communications. NeoServer’s privacy statement says CLOUDWEB LAYER handles such information, names GDPR rights and provides Hostsrc contact addresses. As the service operator deciding how account and billing information is used, the company has direct privacy duties for that surface.

A game community can create a second privacy relationship. Player accounts, chat logs, allowlists, connection addresses, anti-cheat records and plugin-generated data may be controlled by the community administrator. If CLOUDWEB LAYER stores those records on its behalf, the customer may need processor terms, subprocessor information, location and deletion commitments. GDPR Article 28 requires a controller using a processor to choose one providing sufficient technical and organisational guarantees and to establish the required contractual terms. A casual private server and a commercial community will not have identical obligations, but neither should assume that a website privacy notice answers every hosted-data question.

The technical boundary sits close to the game directory. CLOUDWEB LAYER controls the physical-node operating system, Pterodactyl deployment, network controls, customer isolation, administrative access and infrastructure logging. OVH or another facility supplier controls physical access, power, hardware replacement and parts of the network. Voxility or OVH controls important filtering systems. The customer controls game configuration, plugins, server-side scripts, community permissions, secrets placed in files and the decision to expose extra ports.

Container isolation reduces risk but does not make untrusted extensions safe. A vulnerable plugin may leak player records, consume CPU, open an outbound connection or corrupt a world while remaining inside its container. The host can impose limits and block obvious abuse; it usually cannot assess every add-on without becoming responsible for the customer’s application. NeoServer’s terms correctly reserve that boundary. The customer should use maintained extensions, least-privilege sub-users, unique credentials and a staging copy for upgrades.

The host, in turn, should be able to show patch management, separation of customer data, protected staff accounts, activity logs, vulnerability handling, secure deletion and incident notification. Because Pterodactyl’s recent releases contain security changes, “open source” is not a substitute for version maintenance. Because the service offers SFTP and MySQL, account compromise can expose more than game console access. Multi-factor authentication, session revocation, credential rotation and restricted staff access are relevant even for a €5 server.

No public ISO certificate, independent penetration-test summary or detailed subprocessor list was identified in the frozen evidence. That does not establish their absence; it means they are not available to support a public assurance. A small community may accept that evidentiary level. A business hosting paying users, personal data or an important event should request a data-processing agreement, subprocessor and location schedule, incident-notification period, deletion process and security contact before purchase.

The real competition is disclosure, not another “1 Tbps” badge

Romanian game hosting is crowded with inexpensive offers built around similar ingredients: Ryzen or Intel desktop processors, NVMe storage, Pterodactyl, instant provisioning and upstream DDoS protection. When the visible stack converges, the competitive difference becomes resource clarity, routing evidence, recovery and support.

For example, BTS Telecom’s game-hosting page advertises guaranteed resources, a 10 Gbps uplink and explicit core counts on some packages. Liga Hosting’s public news records a named Pterodactyl upgrade to version 1.12.1, providing a form of patch transparency. Hosterion, in a different hosting segment, publishes a stated availability guarantee alongside Voxility protection. These are seller claims too, and none should be accepted without terms or tests. They illustrate the disclosures against which NeoServer can be compared.

NeoServer’s strengths are a low entry price, game-specific packages, Romanian-language support, familiar panel access, Bucharest and German options, and a legal operator that now has its own ASN and address space. Its limitations in the reviewed material are the absence of public CPU-allocation rules, node-occupancy policy, bandwidth commitment, status history, contractual availability, backup topology and detailed DDoS schedule. The market does not require CLOUDWEB LAYER to become a hyperscale provider. It does give the company an opportunity to compete by publishing the missing facts.

Switching costs are mixed. Pterodactyl, SFTP and conventional game files make technical export easier than a proprietary platform would. Minecraft worlds, Counter-Strike configuration, scripts and many plugin directories can be copied. The two MySQL stores can usually be exported. That lowers structural lock-in.

Operational lock-in remains. An address can accumulate community recognition and allowlist entries. DNS, server-browser rankings, monitoring and boosting services may point to it. A migration changes route latency and DDoS behaviour. Some licensed game extensions bind to an address or machine fingerprint. Staff learn a particular panel layout. Large worlds take time to transfer, and a consistent database snapshot may require stopping the service. The three-day deletion language after non-payment makes a rushed exit especially dangerous.

A buyer should therefore price the exit while the service is healthy. Measure how long a full export takes. Record the required runtime, game version and start command. Keep DNS time-to-live low enough for the community’s recovery plan. Identify a second provider and test a cold restore quarterly. Ask whether CLOUDWEB LAYER will supply a final archive and source summary on normal cancellation, how long it remains available and whether the address can be retained or announced elsewhere. The answer may be no, but the buyer can plan around a known constraint.

A procurement test built around evidence

The right diligence for a €5 friends-only world is not the same as for a tournament, a monetised FiveM community or a business dedicated-server workload. The method can still be proportional. Begin by classifying what failure costs: inconvenience, lost rankings, lost paid items, refunds to players, reputational damage or breach notification. Then request evidence at the level that matches the consequence.

First, identify the service. The order should name CLOUDWEB LAYER S.R.L., NeoServer, the exact package, location, payment cycle and applicable terms. If the checkout moves into Hostsrc or another portal, ask whether the contract, billing and support boundary changed. Do not accept a Discord message as the only record of a material commitment.

Second, pin down compute. Ask for the physical processor, CPU limit, reservation type, pinning policy, memory limit, storage quota and I/O policy. Ask how many comparable instances may occupy the node and whether the company monitors CPU steal, scheduling latency, disk queueing and thermal throttling. Request a seven-day trial or a refund condition tied to a workload test. Run the actual game build with representative plugins and synthetic players if the software permits it. Record tick time, tail latency, save duration and backup impact at the expected peak hour.

Third, identify the address and route. Obtain a test address for the exact product before purchase. Check its origin, RPKI status, reverse DNS and reputation. Use RIPE Atlas or player access networks to collect pings and traceroutes over at least 24 hours. For AS203942 space, confirm that the origin remains AS203942 and examine whether OVH is the only visible upstream. For an OVH-assigned or Voxility-protected address, document that different chain rather than assuming the company ASN applies.

Fourth, turn DDoS protection into a configuration statement. Require the supplier name, product tier, protected address, protocol rules, clean bandwidth, trigger behaviour, null-route policy, telemetry and escalation path. Ask for a redacted screenshot or report showing that protection is active on the relevant address. Request the most recent controlled test or real-attack after-action summary, with customer information removed. Run only a mutually authorised test; an unsolicited stress test is abusive and can harm other customers.

Fifth, test support. Obtain the definition of the 25-minute intervention claim and the restoration target for node, network and panel failures. Ask which clock stops when the issue is escalated to OVH or Voxility. Confirm an emergency channel if the customer portal itself is unavailable. During the trial, open tickets for a panel question, a network trace and a restore. Quality is demonstrated by correct ownership and evidence, not merely a rapid greeting.

Sixth, test recovery. Create a small world and database, back them up, delete a non-critical file and perform a restore. Ask whether the backup sits on the same physical node, another node or object storage in another facility. Record recovery-point and recovery-time outcomes. Keep an independent encrypted copy. The UK National Cyber Security Centre’s cloud resilience guidance advises customers to establish that backups can restore a known good state and to examine service-specific availability. NIST’s cloud guidance similarly treats a usable, timely data export and an exit plan as part of continuity.

Seventh, resolve billing and data return. Put more than one person on invoice notices, confirm the suspension and deletion timetable, record the refund terms for the chosen payment method and ask whether a grace extension is possible before an important event. The customer should be able to export without opening a support ticket. If a missed payment can erase the only copy, the architecture has failed regardless of uptime.

Eighth, cover security and privacy. Ask for Panel and Wings versions, patch cadence, staff multi-factor authentication, customer multi-factor authentication, log retention, backup encryption, subprocessor list, data locations, incident notification and secure deletion. A commercial community should obtain appropriate processing terms for player data. The customer should document its own plugin patching, sub-user permissions and secret handling.

Ninth, ask for incidents, not adjectives. Request twelve months of node and network availability, planned maintenance, significant DDoS events, data-loss events and median restoration time. A small provider may not have a polished public status site. A candid spreadsheet with ticket references and corrective actions is more useful than an unsupported “guaranteed uptime” phrase. If there is no history, agree on future reporting and start with a non-critical workload.

Finally, define acceptance and exit. A practical acceptance schedule might require median latency below the community’s threshold from named networks, 95th-percentile latency and packet loss within agreed bounds, stable tick performance under a representative load, a successful restore within a defined period and a clean address. The exit schedule should require an archive, source summary, configuration notes and a deletion confirmation. These are not enterprise ornaments. They are the facts that convert an inexpensive subscription into an operable service.

What CLOUDWEB LAYER can own, and what it must make visible

CLOUDWEB LAYER can control more than its size might suggest. It can choose honest package limits, avoid excessive node density, pin or reserve CPU, maintain Pterodactyl, protect staff access, place backups away from a node, keep address records clean, maintain RPKI, monitor the customer experience, escalate to suppliers and publish incident evidence. Its own ASN gives it a stronger network identity and a platform for better routing discipline.

It cannot abolish the supply chain. OVH or another infrastructure company controls the physical host and important network functions. Voxility or OVH may perform the heavy DDoS filtering. Access providers determine part of every player route. Pterodactyl’s maintainers fix faults in the panel code. Customers choose game extensions that can ruin performance or security. Good service comes from managing these boundaries and refusing to promise direct control where none exists.

The current evidence supports a cautious, useful verdict. The legal link from NeoServer to CLOUDWEB LAYER and the network link to AS203942 are established. The company’s retail offer is technically coherent for low-cost game hosting: dedicated-node supply, containerised control, conventional game access and upstream protection. Its public evidence does not yet justify treating chip names, “1 Tbps,” “gigabit” or “24/7” as workload-specific guarantees. The network has one active IPv4 /24 and one currently observed upstream path; that is a real footprint, but a narrow one.

The watchpoints are straightforward. Does AS203942 add genuine path diversity or merely retain a second policy line? Does the company publish a public status history and incident reports? Does it state CPU reservations, node density and bandwidth? Are panel backups off-node and restorable after account trouble? Do NeoServer and Hostsrc receive clearer contractual separation? Can support show protection telemetry rather than repeat a capacity number?

For a small private server, the low price and panel convenience may justify proceeding after a test. For a monetised community, tournament or dedicated workload, trust should follow written evidence. The most valuable thing CLOUDWEB LAYER can sell is not the illusion that it owns every layer. It is a clear, measured promise about the layers it operates—and a reliable way to reach the supplier or customer responsible for the rest.