PT Media Cloud Indonesia sells hosted capacity that still depends on racks, transit and repair windows

Summary

• PT Media Cloud Indonesia has stronger public operating evidence than many small hosts: APNIC/IDNIC records link it to AS140449, 103.152.240.0/23 and 2406:38c0::/32, while RIPEstat observed 103.152.240.0/24, 103.152.241.0/24 and 2406:38c0::/32 announced by AS140449 during the July 2026 verification window.
• The company markets a broad bundle under the Media Cloud brand: domains, WordPress and Sitejet hosting, Indonesian VPS, SSL, professional email, web services, game hosting promotion, and a local loop offering on mci.net.id which displays dedicated bandwidth packages of 1 Gbit/s, 2 Gbit/s, and 3 Gbit/s.
• The concern about resilience is equally concrete. PeeringDB lists an exchange attachment at OpenIXP/NiCE and zero facility records for the network; RIPEstat neighbour data is dominated by AS138840, and the RADB IPv6 route object describes a proxy-registered HSP Global customer route. These are visible interconnection proofs, not proof of independent multi-site capacity.
• Media Cloud's own terms of use and refund policy make the physical failure path visible: services may become inaccessible due to equipment malfunction, maintenance, repair or replacement, telecom link interruption, hostile attacks, congestion or other failures; refund for internet services is conditional on more than seven continuous days of outage or inability to continue the service.
• The evidence level is Medium. The identity, product surface, routed address space and current reachability are well supported; public evidence on facility location, spare capacity, transit diversity, tested recovery, and data portability limits remain incomplete.

The company is visible, but the dependence remains physical

PT Media Cloud Indonesia deserves a closer reading than a simple 'small host' label. The company presents two linked public surfaces. One is the connectivity-oriented corporate site atmci.net.id, which promotes local loop and FTTH connectivity solutions and directs users to the Cloud services shop. The other ismediacloud.id, the customer-facing commercial surface for domains, hosting, VPS, SSL certificates, email and web services. These two surfaces are not mere brand anecdotes. They show that the company asks customers to entrust it with both their basic internet presence and structuring infrastructure services.

This trust collides with very real constraints. A VPS is a virtual machine, but it runs on physical compute, storage, power and cooling. 'Unlimited bandwidth' is a marketing phrase, but packets still traverse ports, routers, filters, fibre optics, transit contracts and exchange fabrics. A '24/7 support' promise is only useful if the customer can reach the team even when the affected service, ticketing system, DNS or billing status is itself failing.

The local loop offering is even more direct: it depends on last-mile access, a point of interconnection, an upstream path, on-call technicians and a business rule about what happens when the circuit stays down.

The public evidence starts at the number resource layer. The APNIC/IDNIC RDAP record forAS140449lists MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, 'Internet Service Provider' and an administrative address in South Jakarta. APNIC/IDNIC also shows the IPv4 network103.152.240.0/23and the IPv6 network2406:38c0::/32under the name MEDIACLOUD-ID. These records do not prove the location of each server, but they are far stronger than an anonymous reseller page. They show a company with directly visible Internet number resources.

The company also hosts its public websites inside this footprint. A DNS check during this research resolved both mci.net.id and mediacloud.id to address 103.152.240.97, inside the 103.152.240.0/23 allocation. This is a modest but important signal: the public website is not simply hosted behind a global gateway with no apparent link to the network registration. The brand, the ASN and the routed address space are sufficiently aligned to make the infrastructure claim verifiable.

The hard part is not proving that Media Cloud has a public presence. The hard part is determining the level of customer resilience this presence implies. Public routing evidence can show which prefixes are visible, which ASNs are adjacent to the network, whether route origin data are covered, and whether a voluntary exchange directory lists a port. It cannot show the spare server in the rack, the facility contract, the customer backup process or the person authorised to replace hardware after midnight. This gap is the core of the article.

The advertised product range goes beyond a simple VPS page

Media Cloud's product pages show a company that wants to be a one‑stop shop for Indonesian customers wanting to build a web presence. TheMedia Cloud shopstates it provides domains, hosting, a site builder, email, SSL certificates and VPS services. It promotes.id and.com domains, reseller and bulk services, and a 'Best VPS Cloud Hosting' tile pointing to the VPS product. This matters because a broad offering creates multiple dependency paths. A customer can buy a domain, DNS, SSL certificate, mailbox, site builder and VPS from the same provider and then discover during an incident that the technical dependency and the account dependency are tightly linked.

TheVPS pageis the clearest hosted capacity claim. It markets 'VPS Indonesia', describes the service as 'fast and stable Indonesian VPS at affordable prices', and lists 100% dedicated resources, NVMe storage, unlimited bandwidth and DDoS protection. It also states that customers can choose operating systems and preconfigured applications. This is exactly the language that turns a small network into a business dependency: customers are not only buying address space; they expect compute, storage, software installation, security controls and enough network headroom to keep applications reachable.

The hosting pages add a further layer.Sitejet Hostingpresents bundled hosting with a site builder and highlights DDoS protection, cPanel, Softaculous and one‑click installations.WordPress Hostinguses the same reliability and features language even though the plan table was unavailable for the currency detected at the time of consultation. This is useful because it reveals the platform assumptions underlying the customer experience. cPanel, Softaculous, site builders and WordPress hosting all depend on control panels, licence statuses, storage and backup practices. These are operational systems, not mere static product names.

Email further extends the dependency.Email Hostingadvertises professional email with a 99.9% availability guarantee, custom domains, security, monitoring, 24/7 support and assistance with setup, migration and troubleshooting.Professional Emaildescribes 8 GB per mailbox, webmail, anti‑spam, anti‑virus, DKIM signatures, automatic backups, mail‑trace features and audit logs. The MX records add nuance: mci.net.id uses Microsoft email protection, while mediacloud.id points to Google aspmx mail exchangers. This is not contradictory; it shows that some parts of the business rely on external email platforms even when the public websites sit in Media Cloud's own address space.

TheSSL pageand the domain pages complete the picture. Media Cloud sells trust layers on top of servers: domain registration, transfer,.id identity, certificates, site generation and mailbox identity. A customer who concentrates these services may gain convenience but also creates a recovery problem. If billing, identity verification, support or the control panel locks, several independent business functions can lock simultaneously.

Local loop pricing makes the rack and routing question explicit

The mci.net.id home page is unusually helpful because it does not only promote abstract cloud services. It advertises 'Local loop and FTTH connectivity solutions' and describes 'high‑speed dedicated bandwidth for reliable business communications'. The page lists local loop packages at Rp 10,000,000 per month for 1 Gbit/s, Rp 20,000,000 per month for 2 Gbit/s and Rp 30,000,000 per month for 3 Gbit/s, with 'Get a quote' links. It also states that Media Cloud provides secure, high‑performance dedicated connectivity, low latency, scalable integration and 24/7 local support.

These claims do not equal public facility disclosure. However, they shift the analysis from simple web hosting to physical infrastructure. A local loop service needs a customer access path, a point of interconnection, a backhaul path, a router, a support model and a repair process. The failure path is no longer simply 'the VPS is down'. It can be a last‑mile fibre problem, an upstream supplier problem, an access router problem, a data centre interconnect problem, a support dispatch problem, a billing block or a customer‑side equipment problem that the provider may or may not control.

The public address story also requires care. The APNIC/IDNIC number resource records give an address at Prudential Center in South Jakarta. Media Cloud's current public footers direct readers to Epicentrum Walk 3rd Floor Unit A306‑307, Jl. HR Rasuna Said, Kuningan, South Jakarta. Both can be true in different ways: one may be a registry address, the other a current office or support location, and neither necessarily identifies where customer workloads or routers are actually hosted. The distinction matters because customers often conflate a corporate contact address with a facility address. They should not.

The local loop page does not name the data centre, the exchange building, the fibre route, the upstream transit providers, the service boundary or the recovery site. This is normal for a public marketing page, but it means the buyer must ask the question. If the offered local loop terminates in the same building as the hosted workload, the failure model differs from a loop that lands in a separate telecom hotel. If the loop is delivered by a partner, the refund and escalation path may depend on the partner's ticket queue.

If the customer needs routing diversity, they need to know whether two circuits share ducts, building entries, patch panels or a single upstream gateway.

This is not to say Media Cloud's local loop offering is weak. It is to underline that it makes physical dependency unavoidable. Hosted capacity seems elastic until the last mile or the upstream path fails. A customer buying cloud and local connectivity from the same provider should ask whether this bundling increases control or simply concentrates failure.

AS140449 currently announces a small, consistent set of prefixes

The routing evidence is clearer than the corporate‑site evidence. TheRIPEstat AS140449 overviewidentified the holder as 'MEDIACLOUD‑AS‑ID – PT Media Cloud Indonesia' and showed that the AS was announced during the July 2026 check. TheRIPEstat announced prefixesview listed 103.152.240.0/24, 103.152.241.0/24 and 2406:38c0::/32 as visible on the 27/06/2026 to 11/07/2026 window. That means the registered /23 is operationally split into two visible IPv4 /24 announcements, while the IPv6 allocation is announced as a /32.

This configuration is consistent with a small operator rather than a hyperscale cloud. Two /24s provide a visible public presence, enough for websites, shared hosting, VPS addresses, control systems or local services, but not a massive retail cloud footprint. The IPv6 /32 is much larger in address terms, but IPv6 address volume must not be confused with installed compute capacity. The usable capacity question is not the number of addresses that exist, but the number of workloads that can be hosted, moved, restored and supported when something fails.

RIPEstat'srouting historyadds continuity. Both IPv4 /24s appear in the history since September 2020, while the IPv6 /32 appears since March 2021. On the last observed interval, the IPv4 prefixes were still visible up to 11/07/2026, and the IPv6 route was also visible up to 11/07/2026. This is stronger than a newly created dormant ASN. It suggests a public routing surface that has persisted for years.

But the history also includes periods of lower visibility. Public route collectors can show that visibility changed; they cannot explain why. A dip can reflect routing policy, collector coverage, an upstream issue, a maintenance period, route filtering, RPKI or IRR effects elsewhere, or a genuine service interruption. It would be irresponsible to convert the history into a claim of specific outage without operator or customer evidence. Its value is narrower: it shows the public route edge is sufficiently observable to be monitored and that customers can ask what changed when visibility changed.

The current BGP state is also instructive. RIPEstat'sBGP state responseshowed many global collector paths towards Media Cloud's prefixes, most paths reaching AS140449 via AS138840. Other paths in the sample included large global transit names further upstream, but the repeated immediate adjacency to AS138840 is the dependency that matters. A customer does not need every route‑collector detail; they need to know whether Media Cloud's edge can survive a loss or congestion of the immediate upstream path.

The visible upstream story points to HSPnet and OpenIXP/NiCE

RIPEstat'sASN neighbours viewrecorded three adjacent ASNs at the 11/07/2026 check: AS138840 as the dominant left neighbour, AS7717 as another left neighbour and AS149004 as a right neighbour. APNIC identifiesAS138840as an Indonesian NAP record associated with PT Parsaoran Global Datatrans / HSPnet. APNIC identifiesAS7717as OpenIXP‑AS‑ID‑AP. APNIC identifiesAS149004as Morapido Net in Timor‑Leste. These labels do not prove contracts, but they help explain the routing neighbourhood.

PeeringDB adds a voluntary interconnection view. Itsnetwork API query for AS140449lists 'PT Media Cloud Indonesia', alias 'Mediacloud', websitehttps://mci.net.id, info type 'Enterprise', IPv6 support, a generally open policy, an IX count of 1 and a facility count of 0. The associatednetixlan querylists OpenIXP / NiCE, a 1 Gbit/s port, IPv4 address 43.252.146.141, IPv6 address 2001:7fa:f::457 and an operational status. Thenetfac queryreturns no facility entries.

The strongest reading is practical: Media Cloud has a visible exchange attachment at OpenIXP/NiCE and a public routing neighbourhood where AS138840 is the primary path seen by collectors. The weaker reading would be to infer a full resilience architecture from these fields. PeeringDB is operator‑maintained and voluntary. A 1 Gbit/s exchange port does not prove that all customer traffic can flow via the exchange during a transit problem. A facility count of 0 does not prove the company has no racks; it simply means PeeringDB lists no facility entries for the network.

An observed upstream adjacency does not prove whether a link is transit, peering, backup or a route‑server path unless supported by operator documentation.

The RADB route objects reinforce the same caution. A RADB query for AS140449 returned route objects for 103.152.240.0/24 and 103.152.241.0/24 with origin AS140449 and descriptions naming PT Media Cloud Indonesia. The route6 object for 2406:38c0::/32 used origin AS140449, but the remarks described a proxy‑registered route object for an HSP Global customer route exported under the Media Cloud origin AS, maintained by MAINT‑AS138840.

This wording makes the supplier‑contract question central: if the IPv6 route depends on HSP maintaining the route object or the upstream arrangement, customers need to know who can fix the entity, who can change the filters and what happens when the upstream contract or support channel fails.

Route origin assurance remains incomplete

Route origin validation is not a full resilience test, but it is a significant check. It verifies whether a published Route Origin Authorisation (ROA) supports a given prefix and origin AS. During the RIPEstat checks of July 2026,103.152.240.0/24,103.152.241.0/24and2406:38c0::/32returned 'unknown' with no validating ROA in the checked view. RADB also showed an RPKI origin validation status of 'not_found' for the route objects.

Unknown is not the same as invalid. It means the checked route origin validation data found no authorising ROA. The practical risk is that networks applying strict routing policies may treat unknown routes differently from valid routes, or that a future route hijack or misconfiguration will be harder to filter by automated policy. For customers, this is not the only security question, but it is a good procurement question: does Media Cloud intend to publish ROAs for its announced prefixes, and can it demonstrate that the route objects and ROAs are maintained by the party with operational responsibility?

RPKI also cannot prove service quality. A valid route origin would not indicate how many servers are online, whether backups work, whether a local loop has path diversity, or whether a technician can swap hardware quickly. It only closes one category of routing risk. In this case, the absence of validating ROAs makes the public control plane less complete than the product catalogue. This gap is fixable, but it must be acknowledged.

The broader lesson for customers is that hosted capacity resilience has many layers. RPKI protects origin authorisation. IRR objects influence filters. BGP neighbours influence reachability. Exchange and transit arrangements influence path choices. The facility, power, spares and support influence repair. Backups and export paths influence recovery. Media Cloud's public evidence is strongest in the middle of this chain and weaker at the ends: route visibility is clear; data portability and tested restoration are not public.

Media Cloud's own terms describe the failure path

The company's legal pages are not polished technical schematics, but they are operationally revealing. Themediacloud.id terms of servicedefine services broadly to include domain name registration, hosting, website creation services and internet services. The terms state that hosting stores and serves website content, and that internet services may include television, email, connectivity and related services. They also state that Media Cloud will use commercially reasonable efforts to provide the site and services twenty‑four hours a day, seven days a week.

The same availability section is more important than the availability sentence. It states that services may be inaccessible or inoperable for reasons including equipment malfunctions, periodic maintenance, repairs or replacements, causes beyond reasonable control, interruption or failure of telecommunication or digital transmission links, hostile network attacks, network congestion and other failures. It also states that Media Cloud has no control over continuous or uninterrupted availability. This wording is not unusual; many providers use similar disclaimers.

Here, however, it gives customers a concise list of the exact dependency categories they should test.

Therefund policyis equally specific. It states that domain registration fees are generally non‑refundable once registered or renewed; hosting and website creation services are not refunded once purchased; and broadband or dedicated internet services may be eligible for a refund if the service is down for more than seven days multiplied by 24 hours continuously, or if Media Cloud cannot continue providing the service due to technical difficulties or a prohibition by the local neighbourhood chief. This is a striking operational threshold. It suggests that for internet connectivity, the refund trigger is measured in days, not minutes or hours.

Customers should not confuse refund eligibility with operational resilience. A refund after a week of continuous outage does not restore an application, migrate a mailbox, recover a database or keep an online shop running during the outage. It only defines a financial recourse. A customer with critical workloads should ask for service level objectives, incident escalation, proactive notification, maintenance windows, data export obligations and measured recovery targets that are distinct from the refund policy.

This is why the article title points to racks, transit and repair windows. Media Cloud's legal terms identify the same categories: equipment, maintenance, telecom links, congestion and attack. The public routing data then show where a major transit dependency appears. The buyer's job is to turn these public clues into contractual and testable evidence.

Data localisation is not resolved by an Indonesian brand

Media Cloud's positioning is strongly Indonesian. The domains page emphasises.id identity, the VPS page says 'VPS Indonesia', the footer gives a contact address in South Jakarta, and the APNIC/IDNIC records place the AS and address resources in Indonesia. For many customers, especially small businesses, this may be the main point: a local provider, a local language, local payment expectations and support that can be reached via Indonesian channels.

But data sovereignty and localisation demand more than a country label. A hosted website may sit on Media Cloud's addresses while email is handled via Google or Microsoft. A support ticket may contain personal information. A backup may be stored in a different system from the primary server. A domain registration may involve registrar and registry processes. A DDoS mitigation claim may rely on upstream filtering or a third‑party platform. Every layer can place data, metadata or access rights in a different operational location.

The company'sprivacy policystates that it collects contact information, billing information, account identifiers, user‑created or uploaded content, log data, device information and cookies or similar technologies. It states that personal information may be shared with service providers, third‑party partners for marketing or advertising purposes, as part of business transactions, or when required by law. It also states that personal information may be transferred to and processed in countries other than the user's, and that no method of internet transmission or electronic storage is completely secure. This is generic privacy language, but in a hosting context it matters: the provider acknowledges the possibility of cross‑border and third‑party processing.

The Indonesian legal context also raises the bar for clear data management. Government Regulation No. 71 of 2019 on Electronic Systems and Transactions is published by JDIH Kemkomdigi atthis official page. The page includes provisions on electronic system operator registration, reliability, security, risk management, service level agreements and personal data processing principles. Law No. 27 of 2022 on Personal Data Protection is published onJDIH Kemkomdigi. This article does not claim that Media Cloud falls into a specific regulatory category for every product, but the national framework explains why customers should ask where data, backups, logs, tickets and support access actually reside.

The practical test is simple. An Indonesian VPS should come with a location answer: where is the primary host, where are the backups, where is the control plane identity, where are the logs, and which third‑party services handle email, DNS, DDoS filtering, support or billing? Without this matrix, 'local' remains a helpful marketing signal but not full sovereignty assurance.

Installed capacity and usable capacity are different

Media Cloud's public network footprint supports a narrative of modest but real installed capacity. It has a registered AS, a routed IPv4 /23 split into two /24s, an IPv6 /32, public websites inside the same IPv4 block, a PeeringDB exchange listing, a local loop offering and VPS/hosting/email products. This is more concrete than a pure reseller without an identifiable edge. It is enough to justify customer interest.

Usable capacity is the harder question. A VPS product may advertise dedicated resources and NVMe storage, but the public pages do not disclose how many hypervisors exist, how storage is replicated, whether customer backups are off‑rack or off‑site, how many spare machines are stocked, what fraction of capacity is reserved for failover, or whether the control panel can work if the production network fails. A local loop product may advertise 1 Gbit/s, 2 Gbit/s or 3 Gbit/s, but the public pages do not disclose fibre paths, interconnection diversity, operator diversity or the congestion policy during an outage.

This distinction matters during a failure. Installed capacity is what a provider sells on a normal day. Usable capacity is what remains after a failure of a server, a router, a fibre path, an upstream supplier, an exchange port, a power supply, a support queue or a billing account. Recoverable capacity is what can be restored within the customer's downtime and data‑loss tolerance. Customers buy the second and third categories, whether or not the invoice names them.

Media Cloud's visible upstream pattern makes this distinction more urgent. If most global collector paths reach AS140449 via AS138840, then the customer must ask whether AS138840 is a single upstream dependency, a primary transit path, a route‑server path, or part of a broader transit mix that public collectors do not fully expose. If the OpenIXP/NiCE presence is at 1 Gbit/s, the customer must ask whether it is used for settlement‑free peering, route‑server reachability, backup or critical customer traffic. If PeeringDB lists no facility records, the customer must ask where production equipment is located and how physical access is managed.

None of these questions implies fault. They are normal infrastructure due‑diligence questions. A small provider can be excellent if it is honest about its limits, tests recovery and gives customers feasible exit paths. A large provider can be brittle if it hides a shared failure point. The public evidence for Media Cloud is strong enough to frame the initial questions, but not strong enough to close them.

Support and billing are part of the infrastructure

Media Cloud sells its products via a shop requiring login, contact links and WhatsApp buttons. The footer lists[email protected]on the shop and[email protected]on the corporate site, while mci.net.id exposes support.mci.net.id at 103.152.240.243. This gives customers several support entry points, but the resilience question is whether those entry points are sufficiently independent during an incident.

Support is infrastructure because it turns detection into repair. If a VPS goes down, the customer needs more than a generic acknowledgement. They need a qualified responsible person, a diagnosis, an estimated restoration path and a way to recover data if the restoration misses the customer's deadline. If a local loop fails, the customer must know whether Media Cloud can dispatch, whether a partner controls the last mile, and whether the same circuit carries the support portal. If billing locks an account, the customer needs an escalation path that can separate business status from emergency data access.

The terms of use make account and payment status operationally relevant. Prices can change; non‑payment can lead to suspension or termination; customers are responsible for maintaining account security; Media Cloud can suspend or terminate access for violations. These clauses are standard, but they show that the control plane is not purely technical. A domain, a hosting plan, a mailbox or a VPS can fail because of an administrative condition as much as a hardware condition.

The email products make this even more visible. The email pages describe migration assistance, troubleshooting, webmail, anti‑spam, anti‑virus, DKIM signatures, automatic backups, mail‑trace features and audit logs. If these are part of a customer's business process, then recovery must include mailbox export, DNS continuity, DKIM/SPF/DMARC continuity, archive access and support evidence. It is not enough to say 'email is hosted'. The customer must know what happens when the email product or its external platform dependency fails.

For Media Cloud, the buyer should ask for a support procedure manual before moving critical workloads. Who takes urgent calls? Is there a phone escalation for a local loop or VPS outage? Are support staff authorised to move workloads or only to create tickets? Are account, billing and abuse queues separate from incident response? How quickly can the company provide a full VPS disk export, website files, mailbox content, DNS zone and domain authorisation code if the customer decides to leave?

The main customer risk is concentration

Media Cloud's convenience is also its risk. A customer can plausibly purchase the domain, website, hosting, VPS, SSL certificate, professional email and dedicated connectivity from the same brand family. This can reduce vendor management for a small business. It can also turn a provider incident into a compound failure: DNS renewal, certificate issuance, web hosting, VPS reachability, email access and local connectivity can all require the same support team or the same account relationship.

The infrastructure version of concentration is similar. If the visible edge depends heavily on AS138840, if the exchange surface is a single OpenIXP/NiCE listing, if production sits in an undisclosed facility, and if the support path is tied to the same network, then a single operational problem can affect multiple layers. Public evidence does not prove that all these single points exist, but it does not disprove them either. The visible records are sufficient to demand an answer.

Customers should test concentration in four ways. First, separate identity and DNS from hosting. Can the domain be transferred quickly? Can DNS records be exported? Are zone records reachable during a hosting outage? Second, separate compute from storage backup. Can the customer recover a VPS or a website at another provider without waiting for Media Cloud to rebuild the original host? Third, separate connectivity from application hosting. If the local loop fails, can the customer reach the hosted service via another access provider? Fourth, separate support from the affected platform.

If the service portal is down, is there an independent escalation channel?

The local loop refund threshold should focus minds. A service down for more than seven continuous days is well beyond the tolerance of many business workloads. A customer who cannot operate for a week should not rely on the refund policy as a continuity plan. They should demand failover, tested backups, alternative access and written escalation terms before buying.

This is the most practical conclusion from the public file. Media Cloud looks like a genuine operational provider with an identifiable network. It is worth evaluating. The same evidence shows why the evaluation must go beyond the product page: a customer needs evidence of diversity, restoration and exit.

What a serious buyer should ask next

A serious buyer should start at the routing edge. Ask Media Cloud which services use AS140449, which prefixes are assigned to customer VPS or hosting pools, and whether any customer services sit behind other providers. Ask whether ROAs will be published for 103.152.240.0/24, 103.152.241.0/24 and 2406:38c0::/32, and who maintains the IRR route objects. Ask whether AS138840 is the primary transit, a backup transit, a route‑server adjacency or another relationship, and whether there is a second independent transit path with sufficient paid capacity to carry customer traffic during a failure.

Next, ask for the facility model. Which data centre(s) host the VPS and hosting products? Are the racks owned, leased or subleased? Are there separate power feeds, separate routers, separate firewalls and separate fibre entries? Is OpenIXP/NiCE used for critical customer traffic, and does the 1 Gbit/s exchange port have congestion monitoring? If PeeringDB lists no facilities, is it because the company chooses not to disclose, because the network is provided via a partner, or because customer workloads are not placed in a public interconnection facility?

Third, ask for recovery tests. When was the last VPS disk restore? How long did it take? Was it restored to the same host, to another host in the same facility, or to a different location? How are WordPress and Sitejet hosting backups stored? Can a customer test an export without cancelling the service? Is email backed up in a way that the customer can retrieve it? Are DKIM keys, DNS zones, certificates and mailbox archives included in an exit package?

Fourth, ask for support limits. What is the major incident path for VPS, hosting, domain, email, SSL and local loop services? Which contact method remains available if mci.net.id or mediacloud.id is unreachable? Does WhatsApp support create a formal ticket? Are there defined response and restoration times? Which events generate customer notifications before maintenance begins?

Finally, ask how the legal and privacy statements correspond to actual data placement. The privacy policy permits cross‑border processing, and the DNS/MX evidence shows dependence on global platforms for parts of the business. The customer should ask where personal data, logs, backups, tickets and billing records are processed, and whether any product can be contractually kept inside Indonesia.

These questions are not hostile. They are how a buyer turns Media Cloud's visible public network into a tested dependency. The company has enough public evidence to justify the conversation. It does not yet have enough public evidence to let customers skip it.

The level of evidence

PT Media Cloud Indonesia scores a Medium public evidence level. The level is not a quality score for the company; it is a score for what the public evidence can support. On the positive side, the identity and operating surface are unusually concrete for a regional hosting provider. APNIC/IDNIC ties the company to AS140449, 103.152.240.0/23 and 2406:38c0::/32. RIPEstat saw three active prefixes announced in July 2026. The public websites resolve inside the company's IPv4 block. Media Cloud advertises a specific set of products: domains, hosting, VPS, SSL, email, web services and local loop connectivity.

PeeringDB lists the network and an OpenIXP/NiCE attachment.

The downgrade concerns the resilience evidence. Public evidence does not name a production facility. PeeringDB lists no facility entries. Route origin validation returned 'unknown' for the checked prefixes. The visible BGP paths are heavily associated with AS138840, and the IPv6 route object describes a proxy‑registered HSP Global customer route. Media Cloud's own terms state that services can be interrupted by equipment malfunction, maintenance, repair, telecom link failure, hostile attacks, congestion and other causes.

The refund policy suggests that some internet service remedies are framed around prolonged continuous outage rather than short operational downtime.

This combination supports a clear conclusion: Media Cloud is a genuine Indonesian provider of hosted and connectivity services with a visible network, but customers should not treat the visible network as proof of multi‑site cloud resilience. The appropriate due diligence path is to verify facility placement, transit diversity, route origin controls, backup and restore tests, support escalation, billing continuity rules and data export rights. If these checks are satisfactory, the public evidence gives customers something solid to monitor.

If these checks are absent, the convenience of a bundled local provider can become concentrated dependency.