CV. RUMAH CLOUD INDONESIA sells hosted capacity that still depends on racks, transit and repair windows

Summary

• CV. RUMAH CLOUD INDONESIA is visible in Indonesian internet-number records, not just in a brand search. The public anchor is AS138868, registered as IDNIC-RUMAHCLOUD-AS-ID and described by APNIC-derived records as CV. RUMAH CLOUD INDONESIA in Bandung, West Java.
• The current routing surface is small. RIPEstat showed AS138868 announced, with one current IPv4 aggregate, 103.140.54.0/23, representing 512 IPv4 addresses, and no IPv6 announced in the July 12, 2026 routing-status view.
• The main dependency signal is not abundance but concentration. RIPEstat observed one neighbour, AS147155, while the APNIC aut-num text still lists AS56258 in its older route policy fields. A buyer should treat that gap as a reason to verify the actual upstream and failover arrangement.
• The domain evidence is thin. APJII lists the brand RUMAH CLOUD INDONESIA and domain RUMAHCLOUD.COM, but the live domain currently presents an index page through Cloudflare and LiteSpeed rather than a service catalogue that explains products, support cover, facilities or data placement.
• The evidence grade is Medium. The ASN and prefix are live enough to matter, but public records do not prove multi-site capacity, rack location, spare-hardware depth, support escalation, route diversity or customer data portability.

The cloud name is real, but the footprint is narrow

The useful starting point for CV. RUMAH CLOUD INDONESIA is not whether the name sounds like a cloud provider. It is whether the public internet shows a real infrastructure edge that a customer might depend on. On that narrower question, the record is positive but modest. RIPEstat's AS overview for AS138868 identifies the holder as IDNIC-RUMAHCLOUD-AS-ID - CV. RUMAH CLOUD INDONESIA and marks the ASN as announced. APNIC RDAP gives the handle AS138868, country ID, the AS name IDNIC-RUMAHCLOUD-AS-ID and a registration date in June 2019. APNIC Whois text describes the organisation as a corporate or direct IDNIC member in Bandung, West Java.

That evidence makes Rumah Cloud more than a stray label in a hosting directory. It also sets a boundary around what can be asserted. A live ASN can identify routing responsibility without proving how many servers are powered, where customer storage sits, what support response is staffed, or whether the service has a second site. The difference matters because a hosted-capacity customer does not only buy a name. The customer depends on racks, power feeds, cross-connects, upstream contracts, spare parts, account controls and people who can repair the service at the hour it breaks.

The public footprint is especially narrow because the company's current web presence does not provide a detailed service description. APJII's Pengguna Nomor PI listing lists CV RUMAH CLOUD INDONESIA, registration number S1268, brand name RUMAH CLOUD INDONESIA, corporate membership, the domain RUMAHCLOUD.COM and a Bandung office address. Yet the live rumahcloud.com page currently returns an "Index of /" view served through LiteSpeed and Cloudflare rather than a public catalogue of cloud products. Host.io's domain page separately shows the domain hosted on Cloudflare addresses and lists Cloudflare name servers plus SpamExperts mail exchangers.

Those domain facts should be read carefully. They do not show that customer workloads run on Cloudflare. They do show that the public website is not direct evidence of the company's own routed infrastructure. The network record and the web record are related by identity, but they are not the same operational surface. The route table says one thing about AS138868. The website says another thing about how the company presents itself to the market. A customer needs both, and the gap between them is where the hard questions begin.

The Bandung record is a location clue, not a facility proof

The APJII and APNIC records both point to Bandung, West Java. The APJII listing gives the office as Gateway Apartemen SB-LG1-7, Jl. Jend. Ahmad Yani No. 669, Padasuka, Cibeunying Kidul, Bandung, West Java. The APNIC number-resource record uses a closely matching address for the organisation and its abuse contact. That is a useful identity check: the member listing, domain and number-resource record all point to the same public commercial identity.

It is not a data-centre proof. A registered office, an abuse contact address or a membership address can be where paperwork, support administration or legal correspondence is handled. It does not automatically identify where servers sit, where routers are mounted, where backups are kept or which building has the power and cross-connects that keep customers reachable. Treating a contact address as a rack address would overstate the public evidence.

This distinction is important for Indonesian hosting. A provider can be commercially local while using colocation space in another Indonesian city, a room in the same building, leased capacity from another carrier, a cloud platform, or some mixture of those. Public number-resource data does not publish the service layout. It names the accountable holder of resources and gives contact evidence. It does not show whether workloads are in Bandung, Jakarta, another Indonesian metro or a supplier facility disclosed only in contract papers.

For a buyer, the location question should therefore be written as a test. Which customer-facing services use AS138868? Is the 103.140.54.0/23 block assigned to hosting customers, management services, DNS, mail, customer portals or some other function? Which facility or facilities hold the equipment that originates it? Are those sites owned, leased or rented by cabinet? Who has physical access after hours? Which power domains, upstream ports and cross-connects remain after a single failure?

The public answer is not enough for assurance. It is enough to make the site interview specific. The public record points to Bandung identity and Indonesian routing. The customer still needs facility names, rack responsibilities and recovery evidence before treating the word cloud as a resilience claim.

The route edge is one IPv4 aggregate

The current routing evidence is plain. RIPEstat routing status reported AS138868 with one announced IPv4 prefix, 512 IPv4 addresses and no IPv6 announced. The same view showed first-seen evidence for 103.140.55.0/24 on October 30, 2019 and a last-seen route for 103.140.54.0/23 on July 12, 2026. RIPEstat announced prefixes listed 103.140.54.0/23 as the current aggregate for the query window ending July 12, 2026.

That is enough to show an operating route surface. It is not enough to show broad capacity. A /23 gives 512 IPv4 addresses before allocation, network design, management, reserve and customer segmentation reduce what is actually usable. Some hosted services can run productively inside a small address pool, especially if they use name-based virtual hosting, NAT, private addressing behind public front ends or a limited customer base. But a /23 does constrain public-address inventory.

It limits how many customers can receive dedicated IPv4 addresses, how much spare space can be kept for migration and how gracefully the provider can isolate abuse, maintenance, DDoS response or customer-specific filtering.

The lack of visible IPv6 is also a business issue, not merely a technical footnote. IPv6 is not required for every small hosting use case, but its absence in the public routing view means a buyer cannot assume dual-stack reachability. If a customer has modern access networks, mobile users, cross-border partners or public services that should be reachable over IPv6, the buyer needs a direct answer. Is IPv6 available on another network? Is it planned? Is it absent from customer products? Does the support team monitor IPv6 separately if offered through a supplier?

Public routing services can confirm that AS138868 is not empty. RIPEstat prefix overview for 103.140.54.0/23 lists the prefix as announced and associates it with AS138868. Hurricane Electric's ASN page and IPinfo provide independent lookups for the same ASN. The important point is what those services cannot show: compute density, storage durability, customer count, spare equipment or a tested recovery path.

One visible neighbour is a dependency signal

The most important current route clue is the neighbour list. RIPEstat ASN neighbours showed one observed neighbour for AS138868: AS147155, marked on the left side of the observed path data. RIPEstat's AS overview for AS147155 identifies that ASN as IDNIC-GATEWAYNET-AS-ID - PT Gateway Internet Indonesia. APNIC Whois for AS147155 places Gateway Internet Indonesia in Bandung and lists its own upstream policy.

That is not automatically bad. Many small networks reasonably buy transit from a regional operator, and a single well-run upstream can be better than two badly managed ones. But it is a concentration signal. If the observed public path depends on one adjacent AS, a customer needs to know whether there is another usable route if that neighbour, building access, cross-connect, route policy or commercial account fails. Redundancy cannot be inferred from the fact that the ASN is announced.

There is also a stale-or-divergent record to examine. The APNIC aut-num text for AS138868 lists route policy fields involving AS56258, which RIPEstat identifies as PGAS-AS-ID - PT. PGAS TELEKOMUNIKASI NUSANTARA. Yet the current RIPEstat neighbour view sees AS147155. This may simply mean the registry route policy was not updated after a provider change, or that different public views expose different parts of the arrangement. It may also mean the service has changed suppliers over time.

The buyer should not guess. The provider should be able to state the current upstreams, the default route arrangement, the committed bandwidth, the overflow capacity, the physical cross-connect paths, the peering or transit role of AS147155 and whether AS56258 is still used for anything. A contract should distinguish logical route diversity from actual physical and commercial diversity. Two routes that leave through one supplier cabinet or one unpaid bill are not independent recovery paths.

The old route history shows continuity and interruption

History is useful here because it tempers both optimism and alarm. RIPEstat routing history shows AS138868 appearing with the 103.140.54.0/23 aggregate in 2019, then recurring across later periods with different visibility levels. That pattern supports the idea that the ASN has not been a one-day placeholder. It has had repeated public life.

But history is not the same as present resilience. The route-history view also shows earlier /24 specifics and periods where peer visibility changed. A visible history can reflect normal routing changes, provider migrations, maintenance, route aggregation, collector coverage or operational incidents. Without the operator's explanation, a public route collector cannot tell which reason applied at each date.

The lesson is to use history as a question generator. If the network moved from /24 announcements to a /23 aggregate, why? Was it a route-policy cleanup, a provider change, a capacity move or a temporary response to reachability? If public visibility dipped at points, was customer service affected? If AS56258 appears in the older aut-num fields and AS147155 appears in current observations, when did the current upstream arrangement begin and what failover did customers have during the change?

For hosting customers, those questions matter more than the historical label. A cloud service is not resilient because it has existed for several years. It is resilient if it can absorb change without trapping customer workloads. Route history can support confidence in continuity, but the recovery test must be current.

RPKI is not settled in the public view

Routing security adds another caveat. RIPEstat RPKI validation for origin AS138868 and prefix 103.140.54.0/23 returned an unknown status with no validating ROAs in the query used for this profile. That does not prove the route is invalid. It means the public validation view did not see a route-origin authorization that would let relying networks mark the origin as valid.

For a small hosting provider, that matters because route-origin validation is increasingly part of basic routing hygiene. RFC 6811 defines BGP prefix origin validation, and APNIC's resource-certification material explains the role of RPKI in authorizing origins. A valid origin state does not make a service redundant or fast, but it reduces one preventable class of routing trouble. An unknown state leaves more room for filtering differences and customer uncertainty.

The buyer should ask for current ROA status and a route-security statement. Does the holder maintain ROAs for the aggregate? If not, why not? If a supplier announces the route under a backup condition, is that origin authorized? Who can update route objects and ROAs during an incident? Does the company monitor invalid or unknown origin changes?

The same discipline applies to IRR data. RIPEstat prefix routing consistency showed RADB route objects around the 103.140.54.0/23 space, including entities that were not in live BGP. IRR records can help networks build filters, but they can also lag the live route plan. A buyer does not need every registry detail, but it should know whether the provider's route authorization records match the live service and the recovery design.

No PeeringDB profile narrows the public map

Interconnection evidence is thin. A PeeringDB API query for ASN 138868 returned no network profile in the checked public response. That absence should not be treated as failure. Plenty of small providers are not listed in PeeringDB, and a company can provide service without maintaining a public interconnection directory entry.

It does mean the public map is missing the details PeeringDB often supplies: facilities, exchange attachments, traffic levels, peering policy, contact roles, looking glass links and prefix counts maintained by the operator. Without that layer, the buyer has fewer public clues about where the company interconnects, whether it participates in an exchange, whether it peers regionally, or whether all public reachability rides through transit.

For Rumah Cloud, the result pushes more work into direct verification. Which facility hosts the AS138868 edge? Is there a second router and a second upstream? Does the company buy IP transit only, share a local network with Gateway Internet Indonesia, or place equipment behind another provider's aggregation? Does customer traffic ever use an internet exchange route server? Does any peering path carry traffic critical enough to affect customer service if an exchange switch or session fails?

PeeringDB absence also makes the image of "cloud" less self-evident. A provider can run a valid hosting service on a small private arrangement, but a customer should not infer neutral-facility diversity from silence. In this case, the visible interconnection story is a single current neighbour and no public PeeringDB profile. That can be enough for a narrow service. It is not enough for broad resilience claims.

The public domain does not explain the hosted product

The most human-facing record is the domain, and it raises rather than answers the service question. APJII lists RUMAHCLOUD.COM as the member domain. The live site currently presents an index page rather than a product page, and Host.io reports the domain as hosted on Cloudflare. The DNS and website presentation therefore do not explain whether Rumah Cloud currently sells VPS, shared hosting, bare metal, managed servers, colocation, DNS, web design, backup, reseller services or some combination.

That is why the article title's phrase "hosted capacity" should be understood broadly. The company's name, APJII listing and ASN suggest a cloud or hosting-oriented infrastructure subject. The public evidence does not define the product boundary with enough detail to say which capacity is sold, how it is packaged or how customers are supported. A responsible reading must hold those two ideas together: the network is real, while the customer offer is not fully visible.

For procurement, the missing catalogue is not merely inconvenient. Product pages often reveal service constraints: operating systems, storage tiers, bandwidth quotas, backup options, support hours, abuse rules, refund terms, migration help and data-retention policies. When those are not public, the buyer needs them in writing before moving anything important. The absence of public detail is not proof of weak service, but it reduces independent assurance.

The web-domain separation also matters during incidents. If a customer support portal, billing page or status page sits behind Cloudflare while the hosted workload sits on AS138868, then one can fail while the other remains reachable. That can help, because an externally hosted status channel may survive a network outage. It can also confuse customers if the public website remains alive while hosted services fail behind it. The provider should explain which systems are inside the service path and which are outside it.

A small address pool changes the economics

Hosting economics look different with a /23 than with a large multi-region platform. IPv4 addresses are scarce and valuable. A provider with 512 addresses has to decide how many are used for routers, servers, customer allocations, NAT pools, control systems, monitoring, quarantine, spare space and future growth. Every customer who requires dedicated public IPv4 consumes a resource that cannot also be used for isolation or expansion.

That does not make the service bad. It may be exactly the right scale for a local provider serving a bounded customer base. Smaller providers can offer personal support, local commercial relationships and practical regional knowledge that larger platforms do not. But the economics require honesty. If a customer expects one IP per workload, quick address changes during abuse response, dedicated management networks or large migration capacity, the address pool can become a constraint.

The route aggregate also affects recovery. In a fault, the provider may need spare public addresses for rebuilt hosts, replacement firewalls, temporary proxies, customer migration, test restores or DDoS mitigation. If every address is already assigned, restoration becomes a scheduling problem as much as a network problem. The customer should ask how much address inventory is reserved for incident work and whether private-address designs can be moved without changing public endpoints.

This is where hosted capacity becomes a physical and commercial promise. The invoice may show a monthly hosting plan, but the provider must pay for address resources, upstream bandwidth, facility space, electricity, hardware, licenses, staff and support systems. If the price is low, the customer should ask which part of the resilience stack is intentionally lean. A cheap service can be rational for low-risk workloads. It is dangerous only when the customer silently assumes enterprise-grade recovery that the price and footprint do not support.

Installed capacity is not usable capacity

The public route tells the reader what is announced, not what remains available after something breaks. Installed capacity is the amount a provider can describe during normal operation: address space, servers, bandwidth, storage, rack space, customer panels and support channels. Usable capacity is what still works after a router is down, a supplier link is degraded, a storage node is being rebuilt, a support engineer is busy on another incident or a customer needs to move quickly. The second number is the one that matters during a bad day.

For Rumah Cloud, the public record cannot measure that second number. One /23 may be plenty for a narrow service if the provider keeps spare public addresses, spare servers and a quiet support queue. The same /23 can become tight if many customers need dedicated addresses, if abuse handling consumes address space, if temporary rebuilds require parallel systems, or if a failed upstream forces traffic through a smaller backup path. Without a disclosed capacity policy, buyers should not convert the visible prefix into a service guarantee.

The same distinction applies to compute and storage. A server fleet can be installed but overcommitted. A backup system can exist but restore too slowly for a customer's deadline. A second path can be configured but under-sized. A support channel can be open but unable to authorize the actual fix. Public routing data will not expose those limits. Only tested recovery evidence can.

Customers should therefore ask for failure-state numbers rather than normal-state claims. How many workloads can be restored at once? How much public address space is held back for emergency moves? How much traffic can the remaining upstream carry if the main path fails? How long does it take to replace a failed host? How many customers can support staff handle during a regional incident? Those answers make the difference between a small provider that knows its limits and a small provider whose first serious outage reveals them.

Racks, power and repair access still decide recovery

The route table cannot show the rack. That is the central limitation in this profile. Public records can show AS138868 and 103.140.54.0/23; they cannot show whether the servers sit in one cabinet, one room, one facility or several sites. They cannot show whether there are dual power feeds, spare switches, hot servers, tested backups, replacement disks, out-of-band access or a remote-hands arrangement that works during a citywide disruption.

This is why customers should translate every cloud promise into physical questions. If a router fails, who can reach it? If a disk array fails, where are the spare parts? If the upstream session to AS147155 drops, what route remains? If the building loses power, which workloads keep running? If the control panel is unavailable, can support still access customer instances? If the billing system locks an account by mistake, who can override it during a service incident?

Support labour is part of the infrastructure. A small provider may know its customers well, but it may also have fewer engineers available during holidays, overnight maintenance or overlapping incidents. The public record does not disclose the team size or support hours. That means a customer should focus on measurable escalation. What qualifies as emergency support? Which channels are monitored after hours? Can the person who answers make a routing, server or account change? What happens if the phone, mail system or ticket system is affected by the same outage?

Repair windows are not abstract. They decide whether a customer misses an order window, a payroll deadline, a school registration period or a government filing. A provider with one visible route edge must be especially clear about which failures are recoverable within minutes, which require supplier action, and which require customer migration. The honest answer may be narrower than the brand name. That is acceptable if the customer understands it before relying on the service.

Data locality is a placement question

Rumah Cloud is an Indonesian company in public records, AS138868 is registered in Indonesia, and RIPEstat geolocation data for 103.140.54.0/23 places the prefix in ID. RIPEstat geolocation and MaxMind GeoLite via RIPEstat both returned Indonesia for the prefix in the checked view. That is useful locality evidence.

It is not a complete data-sovereignty answer. Country evidence for an IP prefix does not prove where every customer file, backup, log, snapshot, ticket attachment, billing record or administrative credential resides. A provider may store primary workloads in one place, backups in another, mail in a third-party service and support records in another system. The public domain's Cloudflare and SpamExperts records already show that at least some web and mail-adjacent functions involve external services. That does not mean customer workloads leave Indonesia; it means data placement cannot be inferred from the country code alone.

Customers with locality requirements should ask for a placement matrix. Where is the live workload? Where are backups? Where are snapshots? Where are logs? Where is the control panel? Where is customer identity stored? Which suppliers can access support records? Which jurisdiction governs the contract? Which data can be retrieved if the customer exits or if the service is degraded?

The answer should be matched to the workload. A brochure site, test server or low-risk community site may not need strict locality proof. A regulated customer, medical office, financial service, government supplier or company with confidential client records needs far more. For those buyers, the public evidence here is only the start: Indonesian identity, Indonesian registered resources and an Indonesian geolocation signal. The service contract has to fill in the rest.

Who is affected when the edge fails

The impact of a small hosting network can be larger than its prefix count suggests. A /23 could host websites, mail-related services, DNS, customer panels, APIs, remote management endpoints, reseller infrastructure or business applications. A short outage might be invisible to the general internet and still be painful for the specific customers that rely on it. Infrastructure risk is not measured only by address count. It is measured by what sits on the addresses and who has no fallback.

If AS138868 withdraws its route, the affected services may simply disappear from public reachability. If the route remains but the upstream path is congested or filtered, customers may see partial failure: reachable from one network, slow from another, broken from abroad, or accessible only through cached DNS and old sessions. If the web domain remains up through Cloudflare while hosted services behind AS138868 fail, the public face of the company may look alive while customers experience downtime.

There are also administrative failures. A billing dispute, expired domain, blocked mail route, abused IP, overloaded support channel or account lock can hurt customers without a BGP outage. These are not secondary issues. In hosted capacity, administrative continuity is part of service continuity. The customer depends on the provider's ability to keep accounts, records, support and recovery instructions usable during stress.

The people most affected may not be network engineers. They may be a small business owner whose online store is unreachable, a developer trying to deploy a fix, a reseller answering end-customer complaints, a school administrator waiting on a portal, or a local organisation that chose a nearby provider for language and support reasons. That is why thin public evidence deserves a serious, not dismissive, reading. Small providers carry real dependencies.

The AS147155 adjacency should be tested as a recovery path

Because the current public neighbour is AS147155, the relationship with Gateway Internet Indonesia deserves a direct question. The APNIC record for AS147155 lists Gateway Internet Indonesia in Bandung and shows a more detailed upstream set than Rumah Cloud's AS record. That may mean GatewayNet is the route provider for Rumah Cloud's public edge, or it may reflect a more limited relationship visible from route collectors. The public record does not settle the commercial boundary.

The difference is practical. If GatewayNet is the upstream, then Rumah Cloud's recovery depends partly on GatewayNet's power, upstreams, filters, route policies, billing relationship and support response. If both companies operate in or around the same address record, a buyer should understand whether that means shared location, shared office, shared facility access, a supplier relationship or only administrative proximity. Shared geography can improve coordination, but it can also create common-mode risk if power, building access or local connectivity fails.

The customer should ask for a path diagram in plain language. What is the first upstream from AS138868? Is there another? Are there separate cross-connects? Are those cross-connects in separate meet-me rooms or through one patch path? If AS147155 has an issue, does AS138868 have a tested alternate route? If the alternate exists, how much customer traffic can it carry? How often is failover tested?

The answer should include both technical and commercial authority. A provider may have a backup path on paper but lack automatic route failover, sufficient commit, or the authority to open an emergency ticket with the supplier. Recovery depends on the whole chain. The observed neighbour gives the customer a named place to begin that chain-of-responsibility review.

What evidence would raise confidence

The evidence grade could improve quickly with a few public or customer-facing disclosures. A current network page could name AS138868, current prefixes, upstreams, abuse contact, support hours and route-security status. A service page could define whether Rumah Cloud offers VPS, shared hosting, managed servers, storage, backup, reseller hosting or other services. A status page could list the public services it monitors without exposing sensitive details. A peering or facility summary could say whether service uses one site or more than one.

Customer-facing documents would matter even more. A buyer should ask for recent backup-restore evidence, measured recovery times, maintenance notice rules, incident-communication examples, a support escalation path, data retrieval terms and a clear statement about where customer data and backups reside. If the provider cannot share facility names publicly, it can still give customers enough contracted detail to understand risk.

Route-security evidence is also straightforward. Current ROAs for AS138868 and 103.140.54.0/23 would improve the public routing-security picture. Clean, current route objects that match the live announcement would reduce ambiguity. A statement explaining the difference between the AS56258 policy text and the currently observed AS147155 neighbour would reduce uncertainty about upstream changes.

The point is not to demand hyperscale disclosure from a regional provider. It is to match claims to evidence. If Rumah Cloud sells modest hosting for modest workloads, the buyer can accept a modest footprint. If it wants to support critical applications, it needs to show the tested recovery chain behind the name. Public records now support the first step of that conversation, not the final assurance.

How customers should monitor the dependency

A customer that relies on Rumah Cloud should monitor more than website uptime. It should watch whether AS138868 continues to announce 103.140.54.0/23, whether the observed neighbour changes, whether route-origin validation remains unknown or improves, whether DNS for customer domains points into the Rumah Cloud prefix or to external services, and whether support channels remain reachable during an incident. Those checks should come from more than one network.

Monitoring should separate layers. A route withdrawal is different from a server failure. A Cloudflare-served website remaining up does not prove the hosting service is healthy. A reachable IP does not prove a database, mail queue or backup job is working. A support phone line answering does not prove the person can restore a route. Each layer needs its own expected behaviour and escalation owner.

Customers should also rehearse exit. That does not mean abandoning the provider. It means knowing how to retrieve site files, application data, configurations, DNS records, logs and account information if the hosted environment becomes unsuitable or unavailable. For a small provider with a thin public footprint, this is the final resilience test. Can the customer rebuild elsewhere without waiting for a distressed support queue?

The rehearsal should be modest and real. Restore one representative workload. Move one domain through a planned DNS change. Retrieve a backup and verify it. Confirm who can unlock the account if billing or support access is impaired. The customer should know which steps are self-service and which require provider action. During a failure, that difference decides whether the customer has a plan or only a hope.

Evidence grade

CV. RUMAH CLOUD INDONESIA earns a Medium network evidence grade. The positive evidence is concrete: APJII lists the company and domain, APNIC and RIPEstat tie AS138868 to CV. RUMAH CLOUD INDONESIA, the ASN is announced, 103.140.54.0/23 is currently visible, and public routing services can observe the network edge. Those facts are enough to treat the company as a real infrastructure dependency candidate.

The limits are equally concrete. The public record shows one current IPv4 aggregate, no visible IPv6, one observed neighbour, unknown RPKI state, no PeeringDB profile and a sparse public web presence. Public records do not prove product scope, facility location, multi-site capacity, spare hardware, support staffing, route failover, backup placement, customer data retrieval or recovery testing.

The practical conclusion is narrow: Rumah Cloud should be evaluated as a small Indonesian hosted-capacity provider whose visible network surface is live but concentrated. A customer does not need to reject that profile. It does need to buy it with eyes open. The right diligence question is not "is this a cloud?" The right question is "which rack, route, support channel and data path keep my service alive when the first dependency fails?"

That is where the company's public evidence currently leaves the reader. It identifies the subject, shows the active route, names the current public neighbour and highlights the missing resilience proof. The rest has to come from provider disclosures, customer contracts and tested recovery evidence before any important workload depends on the promise.