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 hosting names: APNIC/IDNIC records tie it to AS140449, 103.152.240.0/23, and 2406:38c0::/32, while RIPEstat saw 103.152.240.0/24, 103.152.241.0/24, and 2406:38c0::/32 originated by AS140449 during the July 2026 check window.
• The company sells a broad customer-facing bundle under the Media Cloud brand: domains, WordPress and Sitejet hosting, Indonesian VPS, SSL, professional email, website services, game-hosting promotion, and a local-loop offer on mci.net.id that advertises 1 Gbps, 2 Gbps, and 3 Gbps dedicated-bandwidth packages.
• The resilience caveat is equally concrete. PeeringDB lists one OpenIXP/NiCE exchange attachment and no facility record for the network; RIPEstat neighbour data is dominated by AS138840, and RADB's IPv6 route object describes a proxy-registered HSP Global customer route. That is visible interconnection evidence, not proof of independent multi-site capacity.
• Media Cloud's own terms and refund language make the physical failure path visible: services may become inaccessible because of equipment malfunction, maintenance, repair or replacement, interruption of telecom links, hostile attacks, congestion or other failures; internet-service refunds are framed around more than seven continuous days of cut-off or inability to continue service.
• The evidence grade is Medium. Identity, product surface, routed address space and current reachability are well supported; public evidence for facility location, spare capacity, transit diversity, tested restoration and data-portability limits remains incomplete.

The company is visible, but the dependency is still physical

PT Media Cloud Indonesia deserves a more careful reading than a simple "small host" label. The company presents two related public surfaces. One is the corporate and connectivity-facing site at mci.net.id, which advertises local-loop and FTTH connectivity solutions and points users toward the Cloud Services storefront. The other is mediacloud.id, which is the customer-facing commerce surface for domains, hosting, VPS, SSL, email and website services. Those two surfaces are not merely branding trivia. They show that the business asks customers to trust it both with commodity internet presence and with infrastructure-shaped services.

That trust still resolves to real constraints. A VPS is a virtual machine, but it runs on physical compute, storage, power and cooling. "Unlimited bandwidth" is a product phrase, but packets still cross ports, routers, filters, optics, transit contracts and exchange fabrics. A "24/7 support" promise is only useful if a customer can reach the team when the affected service, ticket system, DNS or billing state is also impaired. A local-loop claim is even more direct: it depends on last-mile access, a handoff point, an upstream path, on-call technicians and a commercial rule for what happens when the circuit stays down.

The public evidence begins with the number-resource layer. APNIC/IDNIC's RDAP record for AS140449 lists MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, "Internet Service Provider," and a South Jakarta administrative address. APNIC/IDNIC also shows the IPv4 network 103.152.240.0/23 and the IPv6 network 2406:38c0::/32 under the MEDIACLOUD-ID name. Those records do not prove where each server is installed, but they are much stronger than an anonymous reseller page. They show a company with directly visible internet-number resources.

The company also serves its public sites from inside that footprint. A DNS check during this research resolved both mci.net.id and mediacloud.id to 103.152.240.97, inside the 103.152.240.0/23 allocation. That is a small but important signal: the public website is not merely hosted behind a global front door with no apparent connection to the network record. The brand, the ASN and the routed address space align enough to make the infrastructure claim testable.

The hard part is not proving that Media Cloud has a public edge. The hard part is deciding how much customer resilience that edge implies. Public routing evidence can tell us which prefixes are seen, which ASNs sit next to the network, whether route-origin data is covered, and whether a voluntary exchange directory lists a port. It cannot show the spare server in the cabinet, the facility contract, the customer backup process, or the person with access to replace hardware after midnight. That gap is the centre of the article.

The advertised product mix is broader than one VPS page

Media Cloud's own product pages show a business that wants to be a one-stop provider for Indonesian customers building a web presence. The Media Cloud storefront says it provides domains, hosting, website builder, email hosting, SSL and VPS services. It promotes .id and .com domains, domain reseller and bulk-domain services, and a "Best Cloud VPS Hosting" tile that points to the VPS product. This matters because a broad product mix creates multiple dependency paths. A customer may buy a domain, DNS, SSL certificate, mailbox, website builder and VPS from the same supplier, then discover during an incident that the technical dependency and the account dependency are intertwined.

The VPS page is the clearest hosted-capacity claim. It markets "VPS Indonesia," describes the service as "Fast & Stable VPS Indonesia at Affordable Prices," and lists 100 percent dedicated resources, NVMe storage, unlimited bandwidth and DDoS protection. It also says customers can choose operating systems and pre-configured applications. That is exactly the language that turns a small network into a business dependency: customers do not just buy address space; they expect compute, storage, software installation, security controls and enough network headroom to keep applications reachable.

The hosting pages add another layer. Sitejet Hosting presents hosting bundled with a website builder and highlights DDoS protection, cPanel, Softaculous and one-click installs. WordPress Hosting uses the same reliability and feature language even though the package table was unavailable for the detected currency at the time of viewing. This is useful because it reveals the platform assumptions beneath the customer experience. cPanel, Softaculous, website builders and WordPress hosting all depend on control panels, license status, storage and backup practices. They are operational systems, not just static product names.

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

The SSL page and domain pages round out the picture. Media Cloud sells trust layers as well as servers: domain registration, transfer, .id identity, certificates, website production and mailbox identity. A customer who concentrates these services may receive convenience, but also creates a recovery problem. If billing, identity verification, support or the control panel stalls, several independent business functions can stall at once.

Local-loop pricing makes the rack and route question explicit

The mci.net.id homepage is unusually useful 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 Communication." The page lists local-loop packages at Rp 10,000,000 per month for 1 Gbps, Rp 20,000,000 per month for 2 Gbps, and Rp 30,000,000 per month for 3 Gbps, with "Get a Quote" links. It also says Media Cloud delivers secure, high-performance dedicated connectivity, low latency, scalable integration and 24/7 local support.

Those claims are not the same as a public facility disclosure. They do, however, move the analysis from ordinary web hosting into physical infrastructure. A local-loop service needs an access path to the customer, a handoff, a backhaul path, a router, a support model and a repair process. The failure path is no longer just "the VPS is down." It can be a last-mile fibre issue, an upstream provider issue, an access-router problem, a data-centre cross-connect problem, a support dispatch problem, a billing lock, or a customer-side CPE problem that the provider may or may not control.

The public address story should also be treated cautiously. APNIC/IDNIC's number-resource records give a Prudential Center address in South Jakarta. Media Cloud's current public footers point 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, one may be a current office or support location, and neither necessarily identifies where customer workloads or routers are housed. The distinction matters because customers often confuse a corporate contact address with a facility address. They should not.

The local-loop page does not name the data centre, exchange building, fibre route, upstream transit providers, service boundary, or recovery site. That is normal for a public sales page, but it means the buyer has to ask. If the quoted local loop terminates in the same building as the hosted workload, the failure model differs from a loop that hands off into a separate carrier 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 route diversity, it has to know whether the two circuits share ducts, building entrances, patch panels or a single upstream gateway.

The point is not that Media Cloud's local-loop offer is weak. The point is that it makes the physical dependency unavoidable. Hosted capacity looks elastic until the last mile or the upstream path fails. A customer buying cloud and local connectivity from the same provider should ask whether that bundling increases control or merely concentrates the outage.

AS140449 currently originates a small, coherent prefix set

The route evidence is cleaner than the corporate-web evidence. RIPEstat's AS overview for AS140449 identified the holder as "MEDIACLOUD-AS-ID - PT Media Cloud Indonesia" and showed the AS as announced during the July 2026 check. RIPEstat's announced-prefixes view listed 103.152.240.0/24, 103.152.241.0/24 and 2406:38c0::/32 as visible over the 2026-06-27 to 2026-07-11 window. That means the registered /23 is operationally split into two visible /24 IPv4 announcements, while the IPv6 allocation is originated as a /32.

This shape is consistent with a small operator rather than a hyperscale cloud. Two /24s provide a visible public edge, enough for websites, shared hosting, VPS addresses, control systems or local services, but not a huge retail cloud footprint. The IPv6 /32 is much larger in address terms, but IPv6 address volume should not be mistaken for installed compute. The useful capacity question is not how many addresses exist, but how many workloads can be hosted, moved, restored and supported when something fails.

RIPEstat routing history adds continuity. The two IPv4 /24s appear in history from September 2020, while the IPv6 /32 appears from March 2021. By the latest observed interval, the IPv4 prefixes were still visible through 2026-07-11, and the IPv6 route was also visible through 2026-07-11. That is stronger than a newly created dormant ASN. It suggests a public routing surface that has persisted over years.

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

Current BGP state is also instructive. RIPEstat's BGP state response showed many global collector paths to the Media Cloud prefixes, with most paths reaching AS140449 through AS138840. Other paths in the sample included large global transit names farther upstream, but the repeated immediate adjacency to AS138840 is the dependency that matters. A customer does not need every route collector detail; it needs to know whether the Media Cloud edge can survive loss or congestion of the immediate upstream path.

The visible upstream story points toward HSPnet and OpenIXP/NiCE

RIPEstat's ASN neighbours view recorded three adjacent ASNs during the 2026-07-11 check: AS138840 as the dominant left-side neighbour, AS7717 as another left-side neighbour, and AS149004 as a right-side neighbour. APNIC identifies AS138840 as an Indonesian NAP record associated with PT Parsaoran Global Datatrans / HSPnet. APNIC identifies AS7717 as OpenIXP-AS-ID-AP. APNIC identifies AS149004 as Morapido Net in Timor-Leste. Those labels do not prove contracts, but they help explain the routing neighbourhood.

PeeringDB adds a voluntary interconnection view. Its network API query for AS140449 lists "PT Media Cloud Indonesia," aka "Mediacloud," website https://mci.net.id, info type "Enterprise," IPv6 support, an open general policy, one IX count, and zero facility count. The related netixlan query lists OpenIXP / NiCE, a 1 Gbps port, IPv4 address 43.252.146.141, IPv6 address 2001:7fa:f::457, and operational status. The netfac query returns no facility entries.

The strongest reading is practical: Media Cloud has a visible exchange attachment at OpenIXP/NiCE and a public routing neighbourhood in which AS138840 is the main path seen by collectors. The weaker reading would be to infer a complete resilience architecture from those fields. PeeringDB is operator-maintained and voluntary. A 1 Gbps exchange port does not prove that all customer traffic can drain across the exchange during a transit problem. A zero facility count does not prove the company has no racks; it only means PeeringDB does not list 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.

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.

That language makes the provider-contract question central: if the IPv6 route depends on HSP's route-object maintenance or upstream arrangement, customers should know who can fix the object, who can change filters, and what happens if the upstream contract or support channel fails.

Route-origin assurance is still incomplete

Route-origin validation is not a complete resilience test, but it is a meaningful control. It asks whether a published Route Origin Authorization supports a given prefix and origin AS. In the July 2026 RIPEstat checks, 103.152.240.0/24, 103.152.241.0/24, and 2406:38c0::/32 returned "unknown" with no validating ROAs in the checked view. RADB similarly showed RPKI origin-validation state as "not_found" for the route objects.

Unknown is not the same as invalid. It means the checked route-origin validation data did not find an authorizing 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 is harder to distinguish 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 originated prefixes, and can it demonstrate that route objects and ROAs are maintained by the party with operational responsibility?

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

The broader customer lesson is that hosted-capacity resilience has several layers. RPKI protects origin authorization. IRR objects influence filters. BGP neighbours influence reachability. Exchange and transit arrangements influence path choices. Facility, power, spares and support influence repair. Backups and export paths influence recovery. Media Cloud's public evidence is strongest in the middle of that chain and weaker at the endpoints: 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 engineering diagrams, but they are operationally revealing. The mediacloud.id terms of service define services broadly to include domain name registration, hosting, website-making services and internet services. The terms say hosting stores and serves website content, and internet services may include TV, email, connectivity and related services. They also state that Media Cloud will use commercially reasonable efforts to provide the site and services 24 hours a day, seven days a week.

The same availability section is more important than the uptime phrase. It says 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 says Media Cloud has no control over availability on a continuous or uninterrupted basis. That language is not unusual; many providers use similar disclaimers.

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

The refund policy is equally specific. It says domain registration fees are generally non-refundable once registered or renewed; hosting services and website-making services are not refunded once purchased; and internet broadband or dedicated services may be eligible for refund if service is cut off more than seven days times 24 hours continuously, or if Media Cloud cannot continue to provide service due to technical difficulties or prohibition by the local neighbourhood chairman. That 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 cut-off does not restore an application, migrate a mailbox, recover a database, or keep a storefront online during the failure. It merely frames one commercial remedy. A customer with critical workloads should ask for service-level objectives, incident escalation, proactive notice, maintenance windows, data export obligations and measured recovery targets that are separate from refund policy.

This is why the article title points to racks, transit and repair windows. Media Cloud's own legal terms identify the same categories: equipment, maintenance, telecom links, congestion and attack. Public routing data then shows where one major transit dependency appears. The buyer's job is to turn those public clues into contract and test evidence.

Data locality is not solved by an Indonesian brand

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

But data sovereignty and locality require more than a country label. A hosted website may sit on Media Cloud's addresses while email is handled through 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. Each layer can place data, metadata or access rights in a different operational location.

The company's privacy policy says it collects contact information, billing information, account credentials, user-created or uploaded content, log data, device information and cookies or similar technologies. It says personal information may be shared with service providers, third-party partners for marketing or advertising, in business transactions, or when required by law. It also says personal information may be transferred to and processed in countries other than the user's own, and that no internet transmission or electronic storage method is completely secure. That is generic privacy language, but in a hosting context it matters: the provider is acknowledging cross-border and third-party processing possibilities.

Indonesian legal context also raises the bar for clear data handling. Government Regulation No. 71 of 2019 on electronic systems and transactions is published by JDIH Kemkomdigi at this 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 at JDIH 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 placement answer: where is the primary host, where are backups, where is control-plane identity, where are logs, and which third-party services handle email, DNS, DDoS filtering, support or billing? Without that matrix, "local" remains a useful marketing signal but not a full sovereignty assurance.

Installed capacity and usable capacity are different

Media Cloud's public network footprint supports a modest but real installed-capacity story. 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 offer, and VPS/hosting/email products. That is more concrete than a pure reseller with no identifiable edge. It is enough to justify customer interest.

Usable capacity is the harder question. A VPS product can advertise dedicated resources and NVMe storage, but 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 operate if the production network is impaired. A local-loop product can advertise 1 Gbps, 2 Gbps or 3 Gbps, but public pages do not disclose fibre routes, cross-connect diversity, carrier diversity or congestion policy during a fault.

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

Media Cloud's visible upstream pattern makes that distinction more urgent. If most global collector paths reach AS140449 through AS138840, then the customer should 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 1 Gbps, the customer should ask whether it is used for settlement-free peering, route-server reachability, backup, or customer-critical traffic. If PeeringDB lists no facility records, the customer should ask where production equipment sits and how physical access is handled.

None of these questions imply misconduct. They are normal infrastructure-diligence questions. A small provider can be excellent if it is honest about limits, tests recovery and gives customers workable exit paths. A larger provider can be fragile if it hides a shared failure point. Public evidence for Media Cloud is strong enough to map the first questions, but not strong enough to close them.

Support and billing are part of the infrastructure

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

Support is infrastructure because it turns detection into repair. If a VPS drops, the customer needs more than a generic ticket acknowledgement. It needs a qualified owner, a diagnosis, an estimated restoration path, and a way to retrieve data if restoration will miss the customer's deadline. If a local loop fails, the customer needs to 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 route that can separate commercial state from emergency data access.

The terms of service make account and payment state operationally relevant. Prices can change; failure to pay may result in suspension or termination; customers are responsible for maintaining account security; Media Cloud may suspend or terminate access for violations. Those clauses are standard, but they show that the control plane is not purely technical. A domain, hosting package, mailbox or VPS can fail from an administrative condition as well as a hardware condition.

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

For Media Cloud, the buyer should ask for a support runbook before moving critical workloads. Who receives urgent calls? Is there a phone escalation for local-loop or VPS outage? Are support staff empowered to move workloads or only to file tickets? Are account, billing and abuse queues separated from incident response? How quickly can the company provide a full export of a VPS disk, website files, mailbox contents, DNS zone and domain authorization code if the customer decides to leave?

The strongest customer risk is concentration

Media Cloud's convenience is also its risk. A customer can plausibly buy the domain, website, hosting, VPS, SSL certificate, professional email and dedicated connectivity from the same brand family. That can reduce vendor management for a small business. It can also turn one provider incident into a compound outage: DNS renewal, certificate issuance, web hosting, VPS reachability, email access and local connectivity may all need the same support team or 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 one undisclosed facility, and if the support path is tied to the same network, then a single operational problem can affect several layers. Public evidence does not prove that all of those single points exist, but it does not disprove them either. The visible records are enough to require an answer.

Customers should test concentration in four ways. First, separate identity and DNS from hosting. Can the domain be transferred quickly? Can DNS be exported? Are zone records accessible during a hosting outage? Second, separate compute from storage backup. Can the customer recover a VPS or website on 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 over another access provider? Fourth, separate support from the affected platform.

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

The local-loop refund threshold should focus minds. A service cut off for more than seven continuous days is far beyond the tolerance of many commercial workloads. A customer that cannot operate for a week should not rely on refund policy as its continuity plan. It should require failover, tested backups, alternative access and written escalation terms before buying.

This is the most practical conclusion from the public record. Media Cloud looks like a real operating provider with an identifiable network. That makes it worth evaluating. The same evidence shows why evaluation must move beyond the product page: a customer needs proof of diversity, restoration and exit.

What a serious buyer should ask next

A serious buyer should begin with the route 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 IRR route objects. Ask whether AS138840 is primary transit, backup transit, route-server adjacency or another relationship, and whether there is a second independent transit path with enough paid capacity to carry customer traffic during a failure.

Then ask for the facility model. Which data centre or centres host the VPS and hosting products? Are racks owned, leased or resold? Are there separate power feeds, separate routers, separate firewalls and separate fibre entrances? Is OpenIXP/NiCE used for customer-critical traffic, and does the 1 Gbps exchange port have congestion monitoring? If PeeringDB lists no facility, is that because the company chooses not to disclose it, because the network is delivered through a partner, or because customer workloads are not placed in a public interconnection facility?

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

Fourth, ask for support boundaries. 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 legal and privacy statements map to actual data placement. The privacy policy allows cross-border processing, and the DNS/MX evidence shows reliance 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 kept inside Indonesia by contract.

Those 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 evidence grade

PT Media Cloud Indonesia earns a Medium public evidence grade. The grade is not a quality score for the company; it is a score for what 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 originated prefixes in July 2026. The public websites resolve into the company's IPv4 block. Media Cloud advertises a specific set of products: domains, hosting, VPS, SSL, email, website services and local-loop connectivity.

PeeringDB lists the network and one OpenIXP/NiCE attachment.

The downgrade is about resilience proof. 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 cut-off rather than short operational downtime.

That combination supports a clear conclusion: Media Cloud is a real Indonesian hosted-services and connectivity provider with a visible network, but customers should not treat the visible network as proof of multi-site cloud resilience. The appropriate 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 those checks are satisfactory, the public evidence gives customers something firm to monitor. If those checks are missing, the convenience of a bundled local provider can become a concentrated dependency.