Summary

  • MYCLOUD LLC's identity is unusually well cross-checked for a young, small provider: its own commercial pages, public offer and payment details align with a RIPE NCC organisation entry for an Uzbek local internet registry and with AS213165.
  • Its service catalogue is concrete rather than purely promotional, spanning configurable VPS capacity, colocation, Synology-based company storage and retained cloud video, all priced in Uzbek soum and tied to local connectivity.
  • The assurance picture remains incomplete. Public records show only two visible IPv4 /24 announcements, uneven route-origin authorisation, sparse interconnection disclosure, no named facility, and a material gap between the website's fast-support message and the response terms in its public offer.

A company name that resolves to an operator

"MyCloud" is the sort of brand that can describe almost anything from a file-sharing application to a reseller. MYCLOUD LLC becomes more legible only when several independent public records are read together.

The company's about page says it was founded in Uzbekistan in 2024. Its public service terms, effective from 25 January 2024, name ООО "MYCLOUD" as the contracting party, identify director R.K. Kurbanov, and give a Tashkent address and tax identifier. The payment page repeats the legal name, address, bank details and telephone number for business customers. A separate documents page links a state-registration certificate, service licence and public offer.

That self-published identity is corroborated by the RIPE Database. Its organisation entry names MYCLOUD LLC, country code UZ, registration number 2362063, the same Tashkent street address, the mycloud.uz email domain and a matching telephone number. RIPE records it as a local internet registry, while the associated autonomous-system entry assigns AS213165 to the name MYCLOUD. This does not establish financial strength, staff depth or service quality, but it clears an important first hurdle: the website, legal counterparty and network identity point to the same organisation.

The catalogue shows what customers are buying

MYCLOUD's product pages describe a provider aimed at Uzbek businesses that need modest infrastructure without operating it all themselves. The offers are metered in small units and billed daily, an approach that makes entry inexpensive but places billing continuity close to service continuity.

The VPS page prices virtual CPU, RAM, disk space and IP addresses separately. It includes internet and TAS-IX connectivity at up to 100 Mbit/s, with extra internet and local-network capacity sold per Mbit/s. That is closer to a configurable infrastructure service than to a fixed shared-hosting bundle. The colocation offer is equally specific: prices are given for rack units, power bands, IP addresses and switch connections, with a 1 Gbit/s switch port and up to 100 Mbit/s of TAS-IX service included. Customers remain responsible for their server software, and equipment must meet stated rack, power, fire-safety and Ethernet requirements.

Two higher-level services broaden the operating surface. MCDrive is presented as company storage built on Synology DSM, with plans from 50 GB to 10 TB, browser and mobile access, synchronisation, collaboration, access controls and automated backup. MCVideo stores surveillance recordings for remote viewing, with published 30-day and 90-day options, per-camera capacity, continuous or motion-triggered recording, and daily renewal. Limited public evidence account funds can block access when the next daily charge is due.

These details matter because they expose the actual control surface. Customers are not merely purchasing an abstract cloud. They are relying on MYCLOUD for virtual-machine allocation, rack power and switching, storage permissions, backup claims, video retention and automated account charging. A failure in any one of those layers can affect a different business process, from a web application to physical-site security.

A small network footprint with real routing evidence

AS213165 gives MYCLOUD a verifiable network presence. RIPEstat's AS overview showed the autonomous system as announced on 15 July 2026. Its announced-prefix view recorded two visible IPv4 routes, 38.226.16.0/24 and 212.47.58.0/24. The companion routing-status result counted 512 announced IPv4 addresses, no announced IPv6 space and full visibility among the 326 IPv4 RIPE RIS peers in that observation.

The routing record is meaningful, but compact. RIPE's registration entry declares traffic-acceptance and route-announcement relationships involving AS58254, Nano Telecom, and AS59668, Turon Media. At the observation point on 15 July, RIPEstat's neighbour data saw one upstream path, through AS58254. The difference is not necessarily a contradiction: registry policy can describe an intended relationship that is not visible at every collector or at every moment. It does mean that a buyer requiring path diversity should ask for current diagrams, failover tests and measured upstream availability rather than infer redundancy from registry text.

Route-origin protection is also mixed. RIPEstat reported a valid RPKI authorisation for 212.47.58.0/24, while its check for 38.226.16.0/24 returned unknown, meaning no validating route-origin authorisation was found by that service. Unknown is not the same as invalid, but a consistent valid state across advertised space would offer stronger protection against accidental origin mistakes.

MYCLOUD's PeeringDB entry adds little operational context. As of the evidence date it listed no website, traffic level, policy, exchange connection or facility. A blank interconnection profile does not prove the operator lacks facilities or private connectivity. It shows that customers cannot verify those claims there.

Locality is visible, but data location is not

The service is unmistakably oriented toward Uzbekistan. Prices are in soum; business payments use an Uzbek bank account; consumer payment instructions name local card and payment systems; the contact and registry addresses are in Tashkent; and product pages repeatedly distinguish internet connectivity from TAS-IX access. Support is offered through local telephone numbers, Telegram and a customer account channel.

Those signals make MYCLOUD relevant to organisations that value local commercial support and fast access to domestic network resources. They do not, by themselves, answer where every workload, backup or recording resides. The site refers to modern data centres but does not publicly name a facility, publish a location matrix, identify backup geography or state whether each service remains inside Uzbekistan. MCDrive's use of Synology DSM identifies a platform, not a storage location.

For customers subject to residency, confidentiality or sector rules, locality therefore has to become a contractual fact. The useful questions are service-specific: which facility hosts the primary copy; where replicas and backups sit; who can administer them; what subcontractors can access the environment; how encryption keys are controlled; how deletion is verified; and what happens to data after cancellation or non-payment. A local brand and TAS-IX reach can reduce distance without resolving those governance questions.

Support promises need a contractual reading

MYCLOUD's homepage advertises support around the clock, while its contact page states a 30-minute response time. That is an attractive promise for a small business whose server or camera archive has stopped responding. The public offer is more qualified. It directs authorised requests through the customer account, says telephone responses occur on business days during working hours, and says the support team responds where possible within a reasonable period of no more than 48 hours, with extensions possible. It also says requests must be in Uzbek or Russian.

The offer further defines the provider's obligations more narrowly than some product copy might suggest. General terms say customer internet access is outside the provider's duties, while VPS and colocation pages advertise included connectivity. The practical obligation may be resolved by the selected order and service terms, but an enterprise buyer should not leave that interpretation implicit.

This is where local support becomes a labour question, not just a contact button. Buyers should establish staffed hours, escalation ownership, incident severity levels, restoration targets and the boundary between infrastructure help and customer-managed software. They should also ask which commitment controls when marketing text, a tariff page and the signed agreement use different language.

The same reading should apply to renewal and suspension. Daily charging for storage and video can be useful for small customers, but it also turns account balance, notification quality and restoration procedure into reliability controls. A buyer should test what happens when funds lapse, when access is restored, and when retained recordings or backups are needed after a billing interruption.

Credible enough to assess, not yet assured by default

MYCLOUD's public record is stronger than its generic name suggests. There is a coherent legal identity, a dated offer, visible prices, concrete products, a national commercial orientation and a live ASN. The combination supports a reasonable conclusion that this is an operating Uzbek infrastructure provider with services designed for local businesses.

The same record sets limits on that conclusion. The routed footprint is small, IPv6 is not visible, one announced prefix lacks visible RPKI authorisation, current upstream diversity is not demonstrated, and public facility and interconnection details are sparse. Data-location controls, independent security assurance and enforceable service levels are not easy to establish from the public material.

For a test environment, a local application or a clearly scoped storage need, MYCLOUD may merit a technical and commercial trial. For critical production, regulated data or surveillance evidence, the next step should be documentary verification and a designed failure test. The cloud name opens the conversation; the contract, route behaviour, recovery evidence and accountable support team determine whether it can carry the workload.