Summary
- Cloud LLC is visibly operating as the Kazan software company behind Startpack and related web-application services, but the public record does not establish that it owns a data centre, racks, servers, power capacity or a currently routed network.
- Its assigned AS199067 last appeared in public routing observations in April 2016; current views show no announced IPv4 or IPv6 space and no observed neighbours, so the number is historical identity evidence rather than proof of live redundancy or hosting capacity.
- Customers should judge resilience at the application, supplier and exit layers: where production data and backups sit, which host and transit providers carry them, how identities and payments fail, and whether usable exports can be restored elsewhere within a tolerable window.
The route that disappeared while the business remained
Cloud LLC presents an unusual starting point for infrastructure research. The company is not invisible. Its English corporate page names Cloud LLC, gives a Kazan address, identifies software development as its principal activity and lists Startpack and Deepwork as registered software. Its Russian corporate page names the same legal entity and director and points to a small family of business services. The live Startpack homepage is busy with service listings, reviews and editorial material. Those are meaningful signs of a functioning application business.
Yet the cleanest network identifier associated with the company describes something that is no longer visible on the public internet. RIPEstat’s AS overview for AS199067 identifies the holder as “STARTPACK-CLOUD Cloud LLC” and marks the autonomous system as not announced on 18 July 2026. Its announced-prefixes response returns an empty list for the preceding observation window. The routing-status record is more revealing: it first saw 91.233.212.0/24 originated by AS199067 in August 2012, last saw it in April 2016, and currently sees no address space or neighbours.
That contrast is the subject of this profile. A business can continue to deliver cloud-facing software after its own visible route disappears because an autonomous system is only one possible layer in a service. Applications can move behind another network, a hosting company, a content-delivery platform or an outsourced operations contract. A company can also retain an assigned number it no longer uses. Neither outcome is inherently alarming. What matters is that a surviving registration should not be mistaken for operating capacity, and an accessible website should not be mistaken for a disclosed recovery design.
The dates introduce another reason for restraint. The current company gives the Russian state registration number 1201600014065, which denotes a 2020 incorporation, while the aut-num was created in 2012. The RIPE organisation entity connecting Cloud LLC to the number was itself created in 2020. That chronology is consistent with an administrative continuation around the Startpack brand, but it does not by itself prove that the present legal entity operated the 2012 network. The RIPE-derived registration view preserves both the early aut-num date and the later organisation record. It is an identity trail, not a chain of title for every server or contract that may once have sat behind the route.
The durable conclusion is narrower and more useful. Cloud LLC has a current product surface, a current legal identity and a dormant public routing identity. The gap between those facts is where supplier concentration, support escalation, data location and portability risk live. Any assessment that jumps directly from “AS199067 is assigned” to “Cloud LLC runs its own resilient cloud” skips the most consequential part of the system.
What Cloud LLC actually sells
The word “cloud” in the legal name encourages the wrong mental picture: rows of cabinets, generators, fibre entrances and a catalogue of virtual machines. Cloud LLC’s own descriptions point elsewhere. Its Startpack product page calls Startpack a search-and-selection system for cloud services, built around characteristics, comparisons, user reviews and orders for work from cloud integrators. The page describes a catalogue of thousands of third-party services and a way to find specialists who can configure, integrate, back up or migrate them. That is an information, recommendation and transaction layer above other companies’ applications.
The distinction changes what “capacity” means. A conventional infrastructure provider might expose virtual CPU, memory, block storage, object storage, rack power, ports or bandwidth. Startpack exposes attention, listings, reviews, account sessions, searches, comparisons, referrals and potentially integration requests. Its integrator marketplace explicitly says that integrators help businesses introduce cloud products, connect them to existing systems and organise migrations from one service to another. The labour sits partly outside Cloud LLC, as do the underlying SaaS products. The customer may encounter one branded shelf, but each item can have its own operator, data structure, support desk, billing system and exit terms.
Other Cloud LLC products broaden the operating surface without turning the company into a documented data-centre owner. The corporate page describes Deepwork as a way to run web applications as though they were ordinary desktop programs. The Russian version currently points instead to Firework, which presents the same broad promise of faster access to web applications. The difference between the language pages may be a brand transition or simply uneven maintenance; it should not be converted into a claim about two independent platforms without contract or architecture evidence.
The company also presents Startpack Apps as a layer for unified payment, single sign-on and access management across business services. That makes identity and billing part of the critical path. A failed sign-in broker can make healthy third-party applications feel unavailable; a payment interruption can suspend subscriptions even when the software and network remain sound. Ruscribe adds another dependency by offering Russian businesses a way to pay for foreign cloud subscriptions. Here the service being sold is continuity across a commercial border, not compute in a Cloud LLC rack.
These products can still be infrastructure in the economically important sense. A catalogue determines which vendors get considered. A login hub determines whether employees reach applications. A payment intermediary determines whether licences stay active. A desktop wrapper can become the daily route into many applications. But this is control-plane and access-layer infrastructure: software that coordinates choices, credentials and commercial relationships. Its failure modes are different from those of a bare-metal host, and its recovery plan must account for third-party vendors that Cloud LLC does not operate.
The strongest public claim, then, is not that Cloud LLC sells hosted processors or owns a private cloud. It is that the company operates software around the discovery, access, payment and use of cloud services. That business still consumes hosting, storage, databases, transit, domain services, certificates, support labour and backup capacity somewhere. The identity of those physical suppliers, however, is not disclosed on the reviewed company and product pages. Treating that omission as an unknown is more accurate than filling it with the company’s old ASN.
An office in Kazan is not a data-centre map
Both corporate language pages place Cloud LLC at Soldatskaya Street 8, office 305B, Kazan. The current Startpack footer repeats the address and the legal identifiers. This is good evidence for the administrative location of the company. It is not evidence that production servers occupy that office, that the building has redundant utility feeds, or that any customer data is stored in Kazan.
There is no public facility list on the reviewed company pages. No page names a colocation provider, cloud host, availability zone, rack count, power allocation, meet-me room or fibre entrance. No diagram distinguishes a primary site from a backup site. No latency map identifies measurement nodes. The absence matters because “runs from Kazan” can refer to staff and legal control while the application runs elsewhere. Conversely, data could be hosted in Russia without being in the company’s office or under its physical custody.
The old prefix does not supply the missing map. RIPEstat’s prefix overview for 91.233.212.0/24 marks the block as unannounced and associates it with no current origin. A commercial IP2Location ASN page still associates the /24 with Cloud LLC and classifies it as data-centre, hosting or transit space. That is a useful historical association, but its displayed geography and service category are database labels. They do not locate a live rack, and they conflict with current routing evidence about whether the block is visible at all.
Nor should the corporate office, Russian software registration or a country label on an ASN be used as a proxy for data locality. Physical location has to be established asset by asset: primary database, entity store, search index, authentication store, log archive, backup copy and disaster-recovery target. A service can spread those components across facilities and suppliers. A marketing page can be served from an edge location far from the system of record. A backup advertised as “in another location” may share the same power grid, operator or contractual account.
A credible map for Cloud LLC would therefore have two layers. The first would show the legal and support centre in Kazan. The second would show production and recovery regions, the companies operating them, the type of resource in each, and whether the location is exact, metropolitan or merely national. Until the second layer is published or independently corroborated, the only defensible point on the physical map is an office—not a data centre.
The network record is history, not redundancy
AS199067 remains assigned in the RIPE record. Its WHOIS response lists the routing policy name STARTPACK-CLOUD and two import/export relationships: AS25478 and AS197765. Read in isolation, those lines look like two upstreams. They cannot be treated as current transit diversity. Registry policy can outlive sessions and contracts, and the live observations show no route and no neighbours.
RIPEstat’s neighbour response reports zero observed neighbours. IPinfo’s AS199067 page independently labels the network inactive and reports no prefixes, peers or upstreams. Cloudflare Radar’s AS overview retains the name and country, while its routing view provides a place to inspect BGP activity and incidents but does not establish a presently originated Cloud LLC route. These are observations from different products, not proof that every collector sees the same thing; together, however, they support a strong negative finding about visible self-originated capacity.
The last-seen date is particularly important. A short routing outage might show no path for minutes or hours. A prefix absent since April 2016 is a different condition. It suggests retirement, migration or long-term dormancy, although public BGP data alone cannot choose among those explanations. The ASN may still exist for administrative reasons. It might be used privately in a way global collectors cannot see. Cloud LLC’s applications might have moved into another operator’s address space. None of those possibilities restores the old /24 as current redundancy evidence.
Third-party pages illustrate why source age and method matter. IPIP’s AS record reproduces the registered import and export policy and current contact entity. IP2Location’s ASN view reports 256 IPv4 addresses, apparently by counting the historical /24. RIPEstat and IPinfo report zero currently announced addresses. The two figures answer different questions: what has been associated in a database versus what is now visible as originated space. Installed, registered and reachable capacity are not synonyms.
This also limits what can be said about route resilience. There is no currently observed pair of upstreams to compare, no advertised prefix for path-diversity analysis, no public peering record in the sources reviewed, and no disclosed denial-of-service arrangement. A retained routing policy does not demonstrate physically diverse fibre. Two contracts would not necessarily mean two conduits. Even two data centres could depend on the same carrier or metropolitan power constraint.
For the active services, the relevant network belongs to whoever now hosts their endpoints and data. That operator could provide excellent multi-homing and recovery, but Cloud LLC’s public pages do not identify it. Customers should ask for a current dependency statement rather than relying on AS199067: hosting operator, production region, autonomous systems at the edge and origin, upstream diversity, domain and DNS providers, mitigation service, failover mechanism, and the most recent exercise proving that traffic can move.
Until then, the network grade is weak for attribution—not necessarily weak in actual engineering, but weak in what a customer can verify.
Capacity means transactions and sessions, not megawatts
Cloud LLC publishes several numbers, but none is a physical capacity disclosure. The Startpack homepage displayed 3,818 services in July 2026. The product page says the system contains thousands of services and exposes ratings and reviews. Those figures show catalogue breadth and a potentially large body of indexed content. They do not reveal request throughput, simultaneous users, database size, paid subscriptions, available storage, recovery bandwidth or the headroom remaining during a supplier failure.
The same discipline applies to the old /24. A /24 contains 256 IPv4 addresses, which explains the count on some network databases. Address count is not server count. One address can front many applications; many addresses can sit unused; network address translation and load balancers further loosen the relationship. Since the prefix is not currently announced, its theoretical address count says nothing about usable production capacity in 2026.
Cloud LLC’s software accreditation document and its linked official records are stronger evidence of software status than of infrastructure scale. The Russian software registry lists Startpack’s entry, and the intellectual-property record provides a Startpack software certificate. Equivalent records exist for Deepwork in the software registry and its software certificate. These documents help establish product identity and the company’s role as developer. They do not certify uptime, reserve capacity or disaster recovery.
For this kind of business, useful capacity measures would be operational rather than architectural theatre: successful searches per second, concurrent authenticated sessions, payment instructions processed, catalogue-update lag, support tickets resolved within target, backup restore rate, and the maximum export volume that can be delivered during an orderly exit. Each measure should state whether it is a design ceiling, tested result, normal load or available headroom. A dashboard’s best day is not a promise that the service remains usable during a database failover.
No such figures appear in the public material reviewed. There is also no disclosed service-level objective, recovery-time objective, recovery-point objective, maintenance-window policy or customer-data export limit. That does not mean the controls do not exist. It means outsiders cannot distinguish installed capacity from usable capacity, or routine operation from degraded-mode capacity.
The appropriate status is therefore “operating software surface, undisclosed physical capacity.” The accessible sites and recently updated catalogue support continued service activity. The old ASN does not. Capacity should be re-evaluated only when Cloud LLC publishes metrics tied to a defined service and date, names the asset scope, and explains what remains available when a host, database, payment partner or support shift is lost.
The hidden operating stack beneath the catalogue
Startpack looks light because its interface abstracts other services. Underneath, it still requires a conventional stack. Web and application processes need compute. Service descriptions, accounts, reviews and integration data need databases and storage. Search needs an index. Login and account recovery need identity systems and outbound messaging. Public names need domain registration, DNS and certificates. Every request needs transit from the user to the serving network. Staff need monitoring and a way to deploy repairs. Each layer can be supplied by Cloud LLC or by someone else; the public pages do not allocate those responsibilities.
The control surface becomes more consequential in Startpack Apps. A single-sign-on hub concentrates authentication state. If it holds entitlement or role data, its database can determine which employees reach which services. If unified payment is part of the same account, billing status can become another form of access control. Separation matters: a payment reconciliation error should not corrupt identity records, and an identity outage should not prevent administrators from retrieving invoices or export instructions.
Ruscribe adds banks, payment processors, foreign SaaS vendors, exchange or settlement arrangements and sanctions-sensitive commercial checks to the chain. A payment may fail while every server is healthy. A foreign vendor may accept funds but suspend a Russian account under its own policy. Cloud LLC can improve the customer’s path through that complexity, but it cannot unilaterally restore a third party’s product. The service promise should make clear whether it is selling payment execution, procurement assistance, account administration or a best-efforts intermediary role.
Startpack’s recommendation and review layer has a different integrity risk. Availability alone is not enough if listings, prices, integration claims or user reviews become stale. A catalogue can be “up” while directing buyers toward obsolete plans. Cloud LLC’s own footer cautions that site information is for informational purposes. That caveat makes commercial sense, but it places more weight on update provenance and timestamps for customers using the platform in procurement.
The user agreement and privacy policy are therefore infrastructure documents as much as legal ones. They are where a customer should expect to learn who provides the service, what data is collected, which obligations are disclaimed, how accounts can be terminated and what happens to retained information. They should be read alongside the technical questions, because recovery rights that are not contractual may disappear precisely when a customer needs them.
Support labour is the final hidden dependency. A small software company can achieve excellent reliability with automation and capable suppliers, but incidents still require people who can distinguish a host failure from an application release, revoke credentials, contact vendors, reconcile payments and communicate with users. Cloud LLC publishes support and accounting contacts; it does not publish round-the-clock coverage, escalation tiers, incident-notification targets or the number of people authorised to make an emergency change. A service used mainly for discovery may tolerate a longer repair. A shared login or payment function may not.
This stack explains why the dormant ASN is not the whole story. Cloud LLC may now buy all physical capacity from a provider with deeper resilience than its old network ever had. Outsourcing can be rational. It becomes risky when the supplier boundary is opaque, the contract offers no portable data, or all recovery paths require the same account, operator and support channel.
Seven ways the service can fail
The first failure path is the host or facility. A loss of power, cooling, rack access or storage at the production location can stop the application even if Cloud LLC’s code is sound. With no disclosed production or recovery sites, customers cannot tell whether a second copy is in another fault domain or merely another virtual machine in the same building. The right question is not “is there a backup?” but “can a dated backup be restored into independently powered capacity without the primary control panel?”
The second is transit, DNS or edge service. A host can remain healthy while routes, name resolution, certificates or attack mitigation fail. AS199067 offers no current fallback because it originates no visible prefix. Recovery might rely entirely on the unnamed current host. A tested DNS or edge failover could be effective, but a low time-to-live setting alone is not a recovery plan if the authoritative DNS account is inaccessible or the replacement environment lacks current data.
The third is application and database failure. A faulty release, database-structure change, search-index corruption or overloaded query can break catalogue search and account state without a physical outage. Restoring application binaries is easier than reconciling reviews, permissions and payment records written during a partial failure. Cloud LLC should be able to identify its authoritative data stores, transaction boundaries and the point to which each can be recovered consistently.
The fourth is identity. Startpack Apps advertises single sign-on and access management, so a bad identity-provider configuration, expired signing key, lost administrative credential or account lockout can propagate across otherwise independent services. Break-glass accounts must not depend on the failed broker. Customers need a documented way to reclaim vendor accounts directly, and Cloud LLC needs a separate path to authenticate its own responders.
The fifth is billing and provider contract failure. A card, bank, intermediary or foreign vendor can reject a renewal. An upstream host can suspend an account after a dispute or automated abuse alert. These are commercial events with infrastructure effects: servers or subscriptions can disappear before engineers diagnose anything. Preventive controls include multiple notification contacts, invoice monitoring, grace periods, ownership of vendor accounts by the correct legal entity and an escalation route that does not begin and end with a generic ticket.
The sixth is support capacity. A severe incident arriving outside staffed hours can extend downtime even when recovery steps are known. Simultaneous problems across payment, login and hosting can overwhelm a small team. Customers need to know which services receive urgent coverage, how severity is declared, when an executive or supplier is paged, and how status updates will be delivered if the main site and email domain are unavailable.
The seventh is migration failure. A service may be technically reachable but operationally inescapable because exports omit attachments, review history, permissions, billing records or identity mappings. The migration may also exceed the available egress window. Cloud LLC’s marketplace describes integrators who help move customers between cloud services, which shows an awareness of switching work. That capability should be applied to Cloud LLC’s own services as well: exports must be complete, documented, repeatable and restorable.
These paths do not carry equal consequences. A Startpack search outage delays product research. A corrupted recommendation can influence a purchase. A Startpack Apps identity outage can lock employees out of several applications. A Ruscribe payment failure can end a subscription at an external vendor. Severity depends on which Cloud LLC service a customer uses and whether it has become the sole route to a third party.
Recovery begins with exports, identities and contracts
Recovery for a catalogue begins with data, but recovery for an access broker begins with authority. Cloud LLC needs recoverable copies of service records, reviews, accounts, permissions, payment state and audit logs. Customers need copies of the data they contributed and a list of external services tied to their account. Both sides need to know who can act when ordinary credentials fail.
The first control is a documented export. It should use open, machine-readable formats, include stable identifiers and timestamps, and carry the metadata required to reconstruct relationships. An export that produces a spreadsheet of service names but omits account roles or transaction references is not a full exit path. Attachments and logs should have checksums; encrypted archives should have a key-recovery method independent of the production account.
This is not a niche concern. NIST’s cloud interoperability use cases include copying data entities between providers, migrating applications and transferring ownership of cloud data. The US government’s cloud technology roadmap explains that portability depends on preserving metadata and using standard formats, while billing and usage reporting also need comparable forms. The NIST cloud reference architecture assigns providers a role in supporting data portability and service interoperability. These are general design principles, not certifications of Cloud LLC.
The second control is a restoration exercise. Backups prove little until a separate environment can ingest them, rebuild indexes, reconcile identities and pass application checks. The exercise should measure both recovery time and data loss. It should also test a scenario in which the primary hosting account is unavailable, because provider suspension and credential compromise are among the failures a backup inside that same account cannot solve.
The third control is customer-side identity independence. Administrators should retain direct ownership or emergency access for critical third-party SaaS accounts. Federated login should have documented bypass procedures. Signing keys, DNS credentials and recovery codes should be held under dual control, with a trail of use. If Cloud LLC is only an intermediary, its contract should say which rights survive termination and how the customer assumes direct control.
The fourth is a supplier exit clause. It should set notice periods, export availability, deletion timing, assistance rates, invoice resolution and the treatment of disputed or sanctioned payments. It should prevent a routine billing problem from silently destroying the only copy of customer data. NIST’s public-cloud guidance notes that portability relies on standard interfaces and formats; in practice, contracts determine whether a technically possible transfer can happen in time.
The fifth is regular evidence. Cloud LLC could publish an availability history, incident notices, backup-test date and a plain-language dependency statement without exposing sensitive topology. Customers could then distinguish a tested recovery promise from an assertion. The goal is not to demand hyperscale theatre from a compact software company. It is to make the real recovery boundary legible: which parts Cloud LLC can restore, which require a host, which require a foreign SaaS vendor, and which remain the customer’s responsibility.
Local company, global services, unresolved data location
Cloud LLC is clearly Russian in legal and administrative terms. Its office, tax identifiers, bank details and software accreditation are Russian. Startpack’s main interface is Russian-language and oriented toward services used by Russian businesses. At the same time, its catalogue covers products from many jurisdictions, its corporate site has an English version, and Ruscribe explicitly addresses payment for foreign cloud subscriptions. “Global” therefore describes the service-selection and vendor surface better than it describes a proven global infrastructure footprint.
That distinction matters for data sovereignty. A Russian company can host domestically, abroad or across both, subject to the data and law involved. A foreign SaaS product selected through Startpack can have its own subprocessors and regions. A payment intermediary can generate records in more than one institution. A single-sign-on layer can expose identity attributes to multiple vendors. None of those locations can be inferred from Cloud LLC’s Kazan address.
Russia’s current legal framework places particular weight on personal-data handling and localisation. The government’s consolidated personal-data legislation page records the 2014 localisation amendment and later revisions, while the broader information-law text shows how frequently the regulatory environment has evolved. A Russian cloud-data processing standard further demonstrates that categories of data and cloud handling are an explicit compliance concern. These materials establish a diligence context; they do not reveal where Cloud LLC stores any particular dataset or settle a customer’s legal obligations.
For that, the company needs a data map. It should separate public catalogue content from account identifiers, reviews, support messages, authentication events, payment records and telemetry. For each class, customers should know the controller and processor roles, primary country, backup country, retention period, subprocessor, encryption boundary and deletion method. A statement such as “servers are in Russia” would still be incomplete if logs, mail, analytics or disaster-recovery copies cross a border.
Data locality also intersects with recovery. Keeping primary and backup data in one jurisdiction may simplify compliance but concentrate exposure to regional connectivity, legal orders or supplier constraints. Splitting data across jurisdictions may improve some failure tolerance while complicating transfer rules and incident response. There is no universally correct answer; there is a requirement to disclose the design and match it to the data.
Cloud LLC’s product role makes this especially important. It helps users compare services and, through its other products, reach or pay for them. It is positioned at the moment when a business chooses where operational data will go. The platform can turn that position into an advantage by making provider region, export format, subprocessor disclosure and recovery terms first-class comparison fields. That would convert sovereignty from a vague country badge into information customers can use.
Until the company publishes its own hosting and data-location statement, customers should not assume either domestic confinement or international replication. The appropriate conclusion is unresolved locality within a globally oriented service surface.
Who absorbs the outage and the switching cost
Cloud LLC’s immediate users are business owners, software buyers, administrators and employees seeking access to web applications. Its indirect users include vendors listed in the catalogue and integrators whose leads or reputations depend on the platform. A failure therefore spreads through different mechanisms rather than one dramatic loss of compute.
If Startpack search is unavailable, buyers lose a discovery and comparison service; vendors lose visibility; reviews and editorial context become temporarily inaccessible. Most customers can wait or search elsewhere, so the direct availability impact may be modest. If listing data is stale or corrupted, however, the damage can be subtler: a business may choose the wrong product, misunderstand a price or rely on an integration that no longer works.
If a desktop-style wrapper fails, users may still reach the underlying web applications directly—provided they know the URLs and retain credentials. If Startpack Apps is the only identity and entitlement path, the same failure can lock a team out of multiple services. If Ruscribe cannot complete a renewal, a foreign provider may downgrade or suspend the customer. In each case, the downstream application can be healthy while the Cloud LLC layer creates an outage from the customer’s perspective.
Switching cost falls hardest where information is concentrated. Reviews, comparison history and catalogue curation may be difficult to reproduce. Identity mappings and payment records can be operationally sensitive. Integrator relationships depend on context held by people as well as databases. Customers should rank these assets before an incident and decide which can be rebuilt, which must be exported and which require a contractual handover.
Cloud LLC also bears concentration risk. If a major hosting or identity supplier fails, several products could be affected together. If a payment channel closes, Ruscribe customers may all need alternatives at once. If support knowledge sits with one person, a technically recoverable incident can become a long outage. None of these conditions is proven by the public record, but they are the failure domains a supplier questionnaire should test.
The practical objective is graceful degradation. Startpack should preserve a read-only catalogue if accounts fail. Direct links and recovery instructions should remain available if the desktop layer is down. Identity customers should have break-glass access. Payment customers should receive early warnings and enough information to approach the vendor directly. A status channel should sit outside the primary domain and hosting account. Resilience is not only keeping every feature alive; it is ensuring that one failed intermediary does not strand the customer.
The proof Cloud LLC still needs to publish
Cloud LLC has already published enough to establish who it is and what software it develops. Its corporate pages disclose the legal entity, address, contacts, director and product registrations. The live products show a continuing business surface. Its network registration and historical route add a rare view into an earlier operating layer. The missing proof concerns the present physical and contractual system.
The first useful disclosure would be a short infrastructure statement. It need not reveal rack coordinates or security-sensitive diagrams. It should name the hosting and DNS operators, identify production and recovery countries or metropolitan regions, state whether the sites share an operator, and describe how traffic moves after a site loss. If Cloud LLC still intends to use AS199067, it should explain the planned role; if not, it should avoid presenting the assignment as live capacity.
The second would be measurable service commitments. For each product, publish the availability target, support hours, maintenance notice, recovery-time objective, recovery-point objective and most recent restore-test month. State whether the target covers the whole product or excludes upstream SaaS vendors and payment partners. Report incidents consistently enough that customers can see performance over time.
The third would be a customer exit specification. List export formats, included fields, maximum delivery time, retention after closure and the method for transferring third-party accounts. Provide an emergency route for customers who cannot use the ordinary login. IEEE’s cloud portability guide offers a useful frame for describing portability profiles, but the decisive evidence would be a Cloud LLC export that a customer has actually restored.
The fourth would be a current data-location and subprocessor page. It should distinguish Cloud LLC’s own systems from the third-party services in its catalogue, and Startpack’s informational role from Apps or Ruscribe transaction roles. It should explain where primary data, backups, logs and support systems reside, and how customers are notified before a material location or supplier change.
Finally, Cloud LLC should reconcile its public product names and network record. The English corporate page says Deepwork while the Russian page points to Firework; a dated explanation would prevent buyers from inferring an unsupported product relationship. The registry still describes two routing policies while observational systems see no neighbours. A simple statement that the ASN is dormant, retired or reserved would turn ambiguity into useful history.
None of this requires Cloud LLC to own a data centre. In fact, the evidence points toward a software company whose value lies above the rack: helping businesses discover, access and pay for cloud services. That can be a durable position. But the higher a company sits in the abstraction stack, the easier it is for physical and contractual dependencies to disappear from view. AS199067 is valuable precisely because it breaks that illusion. The route went away; the business did not. Customers now need proof of what replaced it, who can repair it, and how they can leave when repair is not enough.