02 Emre Erim trading as Medyabim Datacenter has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• RIPE's public records give Medyabim a coherent legal and network identity. The RIPE RDAP record for AS44922 names MEDYABIM-AS, lists Emre Erim as administrative and technical contact, and includes ORG-MIH2-RIPE with the name "Emre Erim trading as Medyabim Datacenter"; the RIPE organisation record gives country TR, LIR status, a Bursa address and contact details.
• The current routed surface is real but narrow. RIPEstat's AS overview marked AS44922 as announced, while routing status showed one IPv4 prefix, no IPv6 prefixes, 256 IPv4 addresses and one observed neighbour at the checked snapshot. The announced-prefixes view listed only 37.247.116.0/24 as current.
• The strongest positive control is route-origin security for that current /24. RIPEstat's RPKI validation for 37.247.116.0/24 via AS44922 returned valid, with a ROA authorizing AS44922 and maximum length /24.
• Medyabim's own pages market a broader operating footprint than the current AS44922 route surface proves. The datacenter page claims ready dedicated hardware in Medyabim cabinets, long DirectAdmin/Linux server experience, Turkish and overseas server options, a 50 Gbit/s total exit-capacity claim, named provider paths such as Turk Telekom and Superonline, and customer traffic monitoring. The colocation page claims 99% service continuity with bandwidth, 24/7 support, firewall placement, a free reboot port and five IP addresses.
• Public assurance remains incomplete. The official pages do not publish dual utility feeds, generator runtime, cooling topology, fire suppression, carrier meet-me rooms, maintenance windows, measured failover results, facility certification or a current PeeringDB interconnection profile. Medyabim's own domain resolves to 185.7.83.213, while RIPEstat shows 185.7.83.0/24 currently originated by DATAFOREST rather than AS44922, so customer-facing dependency maps must separate Medyabim's brand, its AS44922 edge, assigned address space and third-party-originated service surfaces.

The useful question is not whether Medyabim exists

There is a class of regional hosting profiles where the first duty is to prove that the company is more than a directory line. Medyabim is not that weak. The public record contains a named natural person, a trading name, a RIPE organisation record, an autonomous system, assigned address resources, official service pages, a Bursa contact address and working product offers. The problem is different: the public record proves identity and a limited route edge, while the company's marketing language asks customers to believe in a broader data-centre capacity story.

The strongest identity source is RIPE. The RDAP record for AS44922 names the autonomous system MEDYABIM-AS and lists the organisation "Emre Erim trading as Medyabim Datacenter." It also lists Emre Erim as both administrative and technical contact, with a Bursa address and voice number. The RIPE REST organisation record for ORG-MIH2-RIPE carries the same trading name, country TR, LIR type, Bursa address, phone, fax, Medyabim maintainer references, and creation date in March 2008. That is much stronger than a scraped hosting directory entry.

Medyabim's own contact page independently anchors the public operating address. It describes "Medyabim Datacenter ve Internet Hizmetleri" and gives Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa, with phone numbers and the public [email protected] email address. That address lines up closely with the RIPE address. This matters because the entity is not presented as a faceless offshore cloud label. Its public evidence points to a Bursa-based operator whose network-resource records and commercial site are at least mutually consistent.

The company history page adds the self-description. Medyabim's about page says the business has operated since 2000 around internet services, software products and Linux-based turnkey systems; says it later focused on domain registration, web hosting, dedicated servers, server management and consulting; and says that from 2006 it built in Bursa, with its own resources, a data centre with 500-plus server capacity for its own servers and those of web-hosting companies. That is not independent proof of installed racks or power capacity, but it is a specific, testable operating claim.

The question is therefore not "is there a Medyabim?" The question is "which parts of Medyabim's marketed capacity can a customer rely on when power, cooling, routing, support or upstream dependency fails?" For a data-centre or colocation buyer, identity is only the first gate. The harder test is recoverable capacity: the hardware, rack power, cooling, fibre, routing and human process that remain available during a fault.

AS44922 is visible, but its current public route surface is small

RIPEstat confirms that AS44922 is announced. The AS overview endpoint labels the holder "MEDYABIM-AS Emre Erim trading as Medyabim Datacenter" and marks the resource as announced at the checked snapshot. That is the positive network finding. Medyabim has a public autonomous-system edge that the routing system can see.

The scale of that edge is modest. RIPEstat's routing-status endpoint showed one IPv4 prefix, 256 IPv4 addresses, zero IPv6 prefixes and one observed neighbour. The announced-prefixes endpoint listed 37.247.116.0/24 as the current AS44922 announcement. The ASN-neighbours endpoint showed a single observed left-side neighbour, AS16276. RIPEstat's AS overview for AS16276 identifies that neighbour as OVH SAS.

That does not mean Medyabim has only 256 customers, only one rack, or only one service. Public BGP does not see private VLANs, reseller stock, provider-addressed hosting, server inventory, customer cross-connects or outsourced web surfaces. But it does mean the visible AS44922 edge is not a broad multi-prefix, multi-neighbour public backbone at the checked time. If a buyer is evaluating Medyabim as a data-centre dependency, the public BGP map does not by itself prove multi-carrier resilience.

RIPEstat's AS routing consistency view makes the gap sharper. It listed 37.247.116.0/24 as present in both BGP and RIPE whois/IRR. It also listed 37.247.117.0/24 and 2a03:400::/32 as present in whois/IRR but not in BGP at the checked time. The same consistency view showed older whois import/export peers AS9121 and AS53667 not seen in BGP, while AS16276 was seen in BGP but not in the whois import/export policy. That is a normal kind of drift in older routing records, but it is exactly why a customer should ask for current diagrams instead of relying on historic registry policy text.

The positive control is RPKI. The current AS44922 route, 37.247.116.0/24, passed RIPEstat's RPKI validation check as valid. That matters because route-origin authorization is one of the few public controls a hosting buyer can check without seeing private facility documents. A valid ROA does not prove power, cooling or failover. It does show that the visible current AS44922 origin is not left as an unknown route-origin claim in the public validation layer.

The route conclusion is therefore narrow and useful. AS44922 is real. Its current visible IPv4 route is valid under RPKI. Its observed upstream surface is thin. Its IPv6 evidence is not currently announced. Its public routing policy records are not enough to prove carrier diversity or failover. A customer should not treat this as a ghost network, and should not treat it as a proved resilient data-centre network either.

The IPv6 and dormant-prefix evidence requires a downgrade

Medyabim has IPv6 registry evidence. The RIPE search record for 2a03:400::/32 shows an allocated 2a03:400::/29 under TR-MEDYABIM-20110107 and a route6 entry for 2a03:400::/32 with origin AS44922. That sounds strong until it is compared with current routing visibility.

RIPEstat's prefix-overview endpoint for 2a03:400::/32 marked the prefix as not announced at the checked time. The routing-status view reported no current origins, zero RIS peers seeing it, and a last-seen event for AS44922 on April 1, 2026. That is not a failure finding by itself. Some customers may not buy IPv6 service; some operators may have dormant IPv6 plans; some address blocks are held for later use. But it changes what can be proven publicly. A data-centre provider whose current official pages market hosting and server services but whose visible AS edge has no current IPv6 announcement should be asked whether IPv6 is supported, unavailable, selectively available, or delivered through another provider.

The IPv4 dormant-prefix picture is also mixed. RIPE's search result for 37.247.117.0/24 shows NET-MEDYABIM-DC5 and a RIPE route entry with origin AS44922 created in June 2025. Yet the RIPEstat consistency check did not see it in current BGP. That could represent reserved capacity, a planned migration, a recently withdrawn route, a backup range or simply unused address space. Public evidence cannot choose among those explanations.

The important distinction is between assigned capacity and operating capacity. A RIPE allocation, route entry or address assignment can show administrative control or preparation. It does not prove that the address range is serving customers today, that it is reachable through multiple carriers, or that it can be activated during a failure. A buyer who needs recoverable capacity should ask Medyabim which prefixes are production, which are reserved, which are migrated to other origins, which are customer-facing, which are only for management, and which are covered by tested DDoS, firewall and RPKI processes.

Medyabim's own service pages are concrete, but they do not publish facility resilience

Medyabim's datacenter page is more detailed than a generic hosting splash page. It says dedicated-server models are delivered after payment approval and that hardware is ready in Medyabim cabinets. It says Medyabim has more than 15 years of experience with Linux dedicated servers and has used DirectAdmin actively since 2003. It says the company serves with its own server hardware based in Turkey, while dedicated-server services can be selected as Turkey or overseas depending on demand. It also describes "high line capacity" and high uptime as the reason for offering real server hardware quickly.

The same page makes a large connectivity claim. It says the data centre's main internet connections were selected to provide fast access from Turkey and the world, names Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent Communications, AMS-IX and ECIX Duesseldorf, and states total line exit capacity of 50,000 Mbit, or 50 Gbit/s. It says dedicated-server customers can enter a network management panel to monitor their own traffic 24/7 and says the data centre uses Foundry Networks and HP Procurve network hardware.

That is useful evidence, but it has to be read as company-published marketing and operations text, not as a live carrier audit. The page does not disclose which of the named providers are current physical carriers, which are upstreams, which are exchange or route relationships, which are historic transit options, which support Turkish services, and which support overseas placement. It does not show a facility meet-me room, diverse fibre entrance, cross-connect map or live port inventory. Public BGP at the checked time showed one observed AS44922 neighbour, not a visible public map of all the provider names on the page.

The page is even thinner on facility engineering. It does not publish dual utility feeds, UPS capacity, battery runtime, generator fuel autonomy, cooling redundancy, fire suppression class, floor loading, cabinet density, physical security layers, maintenance-window rules or disaster-recovery drills. Those omissions are not proof that the controls do not exist. Many small providers do not publish such detail. But a customer evaluating data-centre resilience should not assume those controls from the word "datacenter."

Medyabim's colocation page adds customer-facing operational claims. It says Medyabim gives a 99% uptime or service-continuity guarantee with bandwidth for its colocation service; says companies with servers in Medyabim DataCenter can receive corporate support 24/7; says traffic statistics can be observed online; says servers are behind a firewall; says a free reboot port will be allocated; says the assigned connection is dedicated and not limited; and says five IP addresses are assigned free for servers in the data centre.

Those are real service claims, and they sharpen the questions buyers should ask before relying on the service. A 99% service-continuity promise is not the same as a modern high-availability SLA, and 99% can still allow a material amount of downtime over a year. A reboot port is helpful only if power distribution, remote access, console credentials and support procedures survive the incident. Firewall placement can protect customers, but it can also become a shared choke point. Five IP addresses may be sufficient for simple hosting, but it says nothing about routed subnet portability or failover.

The page gives customers things to ask about, not a full resilience proof.

The official site proves breadth of offer, not recoverable capacity

The breadth of the public offer is broad. Medyabim's web-hosting package page advertises hosting packages with web space, traffic, FTP, MySQL, webmail, DirectAdmin, optional SSL, mail backup products, a server extra-IP service, a 300 GB server-backup service, 24/7 unlimited FTP transfer, weekly and monthly automatic backups, advanced statistics, spam filtering and transfer reporting. Its reseller page offers reseller packages with web space, POP3 mail counts, monthly traffic, MySQL database counts, Turkish control panel, webmail, optional DNS control, SSL options, anti-spam filters and traffic reporting.

The VDS page explains virtual dedicated servers as logically separated servers on physical hardware and lists VDS package features. The control-panel information page says DirectAdmin is installed on servers when the server is in Medyabim DC, describes proactive server management, security configuration and spam blacklist follow-up, and says PHP, MySQL, Linux, ionCube and DirectAdmin are installed and configured on all servers.

Taken together, these pages show that Medyabim sells a classic small-provider stack: domains, shared hosting, reseller hosting, VDS, dedicated servers, colocation, email storage, SSL, backup and managed Linux/DirectAdmin support. That mix creates two kinds of dependency. One is physical: racks, power, cooling, uplinks, firewalls, reboot ports, spare servers and technician access. The other is administrative: customer portal, billing, account status, support ticketing, domain controls, DNS, mail and backup processes.

The public offer does not tell the buyer which dependencies are in the same failure domain. A customer could buy a web-hosting package whose website, mail, backups, DNS and ticket access all depend on the same provider systems. A reseller could depend on Medyabim's control panel and mail systems even if end customers see only the reseller brand. A dedicated-server buyer could have remote reboot but still need a technician if the machine fails to POST, a disk controller breaks, or the firewall policy blocks recovery access.

A colocation customer could own the server but still depend on Medyabim's building, power, upstream, firewall and support response.

This is why installed capacity is not enough. The about page's 500-plus-server capacity claim and the datacenter page's 50 Gbit/s exit-capacity claim describe possible scale. Recoverable capacity asks what happens after one utility feed, one UPS path, one switch, one firewall, one upstream, one authentication path or one support channel is gone. The public pages do not answer that.

Medyabim's own DNS surface points outside AS44922

One of the most revealing checks is Medyabim's own domain. A public DNS lookup for medyabim.com.tr showed the apex and www name resolving to 185.7.83.213, mail.medyabim.com.tr also resolving to 185.7.83.213, nameservers at ns1.medyabim.com and ns2.medyabim.com, and an SPF record that referenced 37.247.112.0/24 and 185.7.83.0/24. Those DNS facts should be treated as operational-adjacent evidence because they show how Medyabim presents its own service surface to the internet.

RIPEstat then changes the interpretation. Its prefix overview for 185.7.83.0/24 showed the prefix announced by AS58212, and the routing-status endpoint for 185.7.83.0/24 listed current origin AS58212, while noting that the prefix had first been seen from AS44922 in 2012 and was last seen at the checked time from AS58212. RIPEstat's AS overview for AS58212 identifies that origin as DATAFOREST dataforest GmbH. Similarly, RIPEstat's prefix overview for 37.247.112.0/24 showed current origin AS29141, and its AS29141 overview identifies Bradler & Krantz GmbH & Co. KG.

This does not mean Medyabim is misrepresenting its service. Address space can be assigned, leased, migrated, routed by upstreams, hosted abroad, or used for legacy services. The RIPE search results for Medyabim show multiple Medyabim-labelled address blocks, including 37.247.115.0/24, 37.247.118.0/24, 185.7.82.0/24 and 185.7.83.0/24, some of which public routing currently attributes to other origin ASNs. The correct conclusion is not scandal; it is dependency mapping.

If Medyabim's own web, mail or DNS surfaces depend on prefixes currently originated by other networks, then customers need to know which parts of their service are on AS44922, which parts are on external-origin address space, and which parts are overseas. That matters for outage analysis. If AS44922 has a problem, Medyabim's public website or support mail might still be reachable through another provider. If the external-origin path has a problem, the Medyabim brand surface might fail even if the Bursa AS44922 route remains up.

If a customer buys "Turkey" placement but support, backup, DNS or mail dependency sits elsewhere, the customer needs that drawn in the service design.

The broader point is that DNS and BGP tell different stories. The brand domain can be online while the AS edge is narrow. A RIPE holder can have assigned address ranges that are not currently originated by its own ASN. A provider can sell hosting while depending on third-party route origins for parts of its own stack. None of those facts is disqualifying. All of them mean that a failure review must be precise.

PeeringDB silence matters because the site names many paths

PeeringDB is a voluntary directory, so the absence of a network object is not proof that a network lacks interconnection. Still, it matters for Medyabim because the official datacenter page names many connectivity relationships and a 50 Gbit/s total exit-capacity claim. A public PeeringDB API query for ASN 44922 returned no network object at the time of research. That removes one public source that could otherwise show exchange presence, facility presence, peering policy, traffic ratios, informational prefixes, and self-reported interconnection locations.

Without a PeeringDB profile, a buyer is left with RIPE/RDAP records, RIPEstat BGP observations, Medyabim's own pages, DNS and contract language. That is workable, but it is not enough to prove diverse carrier meet-me access. Public BGP showed AS16276 as the observed current neighbour. Medyabim's datacenter page names Turk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX and ECIX Duesseldorf. The article cannot reconcile those layers into a current physical topology from public evidence alone.

The right procurement question is not whether every named provider is false. It is whether the current production service has more than one independently provisioned path and whether those paths are diverse in the ways that matter. Are there multiple paid transit providers active for the customer service, or only one visible upstream? Are some listed names historic? Are some routes delivered through an upstream, reseller or remote interconnect? Does the Bursa facility have diverse fibre entrances? Are Turkish and European paths physically separated? How much traffic can the surviving path carry during a failure?

Is the firewall path redundant, and is the reboot-port path independent of customer production routing?

Public evidence cannot answer those questions. It can identify the need for them. A 50 Gbit/s claim is a capacity hypothesis until there is evidence of current ports, contracts, utilization headroom and failover. Named provider logos or text are not equivalent to route diversity. A single observed AS neighbour is not proof of single-homing, but it is enough to require direct confirmation.

The service agreement shifts risk back to the customer

Medyabim's service agreement is important because it shows how public technical promises meet contract risk. The agreement says Medyabim will provide ordered services after payment and acceptance, but it also places responsibility on customers for account credentials, hosted content, legal compliance, taxes and use of services. More importantly for resilience, it says customer data backup and storage obligations belong to the customer unless the agreement text states otherwise, while also saying Medyabim backs up and maintains customer data regularly but is not responsible for errors, losses or damages arising from service interruptions or data loss.

That combination is common in hosting contracts, but it is consequential. Public hosting pages can advertise automatic weekly and monthly backups, optional backup services, traffic reporting and managed support. The service agreement can still limit the provider's responsibility if the customer has not bought or configured the right backup and restore process. A customer should therefore ask for exact backup scope, retention, restore testing, restore time, backup isolation and whether backups are inside the same facility, same provider network, same account-control plane or same failure domain.

The same agreement gives Medyabim suspension rights for payment problems, illegal content, spam and other contract breaches. That is expected for a hosting provider protecting its network. It also means service continuity depends on administrative state as well as physical systems. A customer can lose service through non-payment, abuse handling, spam incident, account lock, credential loss or support dispute even when racks and routes are healthy. For critical workloads, billing, abuse contacts and escalation procedures are operational controls, not back-office details.

Medyabim's support-system help page and online-help page show a ticket-driven support posture. The datacenter page says phone support is available during business hours, from 09:00 to 18:00, and outside those hours customers can reach the provider through a 24/7 support system by ticket and mail. The colocation page says companies with servers in Medyabim DataCenter can receive 24/7 corporate support. Those statements should be converted into incident procedures before a customer trusts the service: who can call, who can open emergency tickets, whether phone escalation exists out of hours, and how the provider distinguishes reboot, network, hardware, firewall, DNS and abuse incidents.

Power and cooling are the largest public blind spots

The assignment for this company is a data-centre infrastructure review, and the main physical dependency is power, cooling, fibre meet-me access, facility operations and local permitting. Medyabim's public pages give some facility-like claims but not enough engineering detail to support a high confidence resilience grade. The about page says the company built a 500-plus-server-capacity Bursa data centre with its own resources. The datacenter page says hardware is ready in Medyabim cabinets and that the company uses its own server hardware.

The colocation page says servers are behind a firewall, have traffic statistics and receive a free reboot port.

Those statements still leave the physical plant almost unobserved. There is no public dual-utility-feed claim. There is no published UPS topology or battery runtime. There is no generator count, fuel capacity or refuelling contract. There is no cooling redundancy design. There is no smoke, fire-suppression or water-leak detection detail. There is no floor plan or facility certification. There is no statement of diverse fibre entrances or meet-me-room design. There is no maintenance-window policy that distinguishes planned, emergency and customer-requested work. There is no public incident history showing measured recovery.

For a small Bursa provider, some of that silence is understandable. Publishing too much facility detail can create security risk. Smaller operators may also rely on upstream facilities, leased rooms, office-building power arrangements, or mixed local and foreign server placements. But the customer risk remains the same. A "500-plus server capacity" claim is not equivalent to usable power capacity after one distribution path fails. A "high uptime" claim is not equivalent to a tested generator runtime.

A "reboot port" is not a substitute for remote console access, spare disks, hot-swap procedures or technician availability.

The practical test is to separate four capacities. Installed capacity is what the provider has built or says it can host. Sold capacity is what customers are already using. Usable capacity is what remains after normal load, thermal limits, power reservations, maintenance and oversubscription. Recoverable capacity is what remains after a component fails. Public pages usually describe installed capacity. Customers need usable and recoverable capacity.

Medyabim's current public evidence cannot settle that question. It can only define the evidence request: utility diagrams, UPS and generator runtime, cooling design, rack-density policy, fire and water controls, carrier entrance diversity, maintenance history, remote-hands procedure, spare-parts policy and at least one documented failover or restore exercise.

Who is affected when Medyabim fails

The affected users are not only Medyabim's direct account holders. A provider that sells domains, hosting, reseller packages, VDS, dedicated servers, colocation, email storage and backup can sit under many downstream services. A reseller package can support dozens or hundreds of small websites whose owners may not know Medyabim exists. A dedicated server can carry a business application, database, agency portfolio, mail service or e-commerce storefront. A colocation customer may own the hardware but depend on Medyabim for power, rack access, firewall path, traffic monitoring and reboot control.

The failure path is also not one-dimensional. A power event can take down servers even if upstream routes are healthy. A cooling event can force a shutdown or reduce allowable rack density. A firewall fault can isolate many customers at once. A single upstream outage can affect AS44922 if no alternative path is active for the relevant prefix. A support or ticketing outage can slow recovery even if the facility is intact. A DNS or mail failure on external-origin address space can make Medyabim harder to contact while production traffic elsewhere still works. A contract or abuse suspension can remove service without a physical outage.

This is why the DNS finding matters. If the public brand domain and mail service use 185.7.83.213 under a prefix currently originated by DATAFOREST, and if SPF references a 37.247.112.0/24 prefix currently originated by Bradler & Krantz, then customers should not assume that "Medyabim network" means one AS, one city, one facility or one jurisdiction. The service may be more resilient because some components sit outside AS44922. It may also be more complex because incident ownership crosses provider boundaries.

The people who need answers are procurement teams, web agencies, reseller operators, small-business owners, systems administrators, compliance officers and incident responders. They need to know whether a Medyabim-hosted service has a second path, a recent restore test, an out-of-band support channel, current backups, domain-transfer access, DNS export, mail continuity and route-origin authorization. Those questions are not hostile. They are the minimum work required to turn a hosting relationship into an infrastructure dependency that can survive a bad day.

What customers should ask Medyabim to prove

First, ask for a current network map. It should identify AS44922, 37.247.116.0/24, any reserved or dormant AS44922 prefixes such as 37.247.117.0/24, any IPv6 plans for 2a03:400::/32 or the larger allocation, and any customer services routed under AS29141, AS58212 or other origins. It should identify whether AS16276 is the only active upstream for the AS44922 route, whether other providers are active through private or non-observed arrangements, and whether the provider names on the datacenter page are current, historic, indirect or product-specific.

Second, ask for facility resilience. The answer should include power feeds, UPS design, battery runtime, generator runtime, cooling redundancy, rack-density limits, physical security, fire and water controls, maintenance windows, remote-hands availability, spare-parts policy and what the 99% colocation continuity claim actually covers. If the service is in Bursa, ask what building and utility dependencies apply. If the service is overseas, ask which country, facility, provider and legal terms apply.

Third, ask for customer-level failover evidence. Medyabim should be able to show what happens when an upstream fails, a firewall fails, a server loses power, a disk fails, the customer cannot reach the portal, the support queue is busy, the account is flagged for abuse, or the customer needs an emergency migration. The public pages mention traffic monitoring, backups, reboot ports and tickets. The buyer needs to know how those tools behave during failure.

Fourth, ask for data and exit controls. The hosting page mentions weekly and monthly automatic backups, optional backup, mail backup products and a server-backup service. The service agreement limits Medyabim's responsibility for service interruption and data loss unless the agreement says otherwise. Customers should require restore tests, backup scope, retention, offsite status, encryption, access control, export process, domain transfer process, DNS export and mail continuity.

Fifth, ask for evidence that support can be reached when the ordinary website or mail route is unavailable. The contact page gives phone numbers and email. The datacenter page describes business-hours phone support and out-of-hours ticket/mail support. Critical customers should require named emergency escalation, authenticated contacts, out-of-band phone procedure and a way to authorize remote hands without relying only on the normal portal.

A reasonable proof pack would not have to reveal sensitive floor plans. Medyabim could provide a customer-specific annex that says which facility serves the workload, which prefixes and origin ASNs are used, which DNS and mail services are in scope, which upstreams are active, which components are single points of failure, and which services are outside Turkey. It could provide a redacted one-line diagram that separates customer servers, shared firewall, reboot controller, backup target, support portal, authoritative DNS and public website.

It could also provide recent dates for generator tests, UPS maintenance, cooling maintenance, upstream failover tests, backup restore tests and route-origin changes. Those artifacts would answer the operational question without exposing customer names or sensitive security layouts.

The same annex should distinguish standard hosting from colocation and dedicated servers. In shared hosting, the buyer depends on Medyabim's platform choices and backup policy. In reseller hosting, downstream customers may depend on Medyabim even when they buy from another brand. In dedicated servers, the buyer may control the operating system but not the rack, router, power path or replacement parts. In colocation, the buyer may own the server but still relies on Medyabim for the building, power, support access and network edge. Those differences decide who acts first during failure.

The evidence grade

Medyabim earns a Medium public network evidence grade, with a downgrade for facility and resilience evidence. The identity layer is strong for a small provider: RIPE RDAP and RIPE organisation records tie AS44922 and ORG-MIH2-RIPE to Emre Erim trading as Medyabim Datacenter, and the Bursa address aligns with Medyabim's contact page. The current AS44922 route layer is also real: RIPEstat marks the AS as announced, lists 37.247.116.0/24 as current, shows full IPv4 RIS visibility at the checked snapshot, and validates the route under RPKI.

The grade cannot be Strong because the operating proof thins out immediately after that. RIPEstat showed only one current IPv4 /24, no current IPv6 announcement and one observed AS44922 neighbour. PeeringDB returned no network object for AS44922. RIPEstat's consistency view showed an IPv4 route entry and an IPv6 route6 entry that were not current in BGP. Medyabim's own DNS surface points to address space currently originated by other networks. Medyabim's official pages publish useful service claims but do not publish the power, cooling, carrier-meet, maintenance and failover evidence needed to trust marketed data-centre capacity under stress.

The practical conclusion is not to dismiss Medyabim. The evidence supports a real Bursa-based hosting and data-centre operator with long-running RIPE records, a visible AS edge, official service pages and a concrete customer offer. The conclusion is also not to accept the 500-plus-server and 50 Gbit/s claims as resilience proof. Customers should treat those claims as hypotheses to be validated through current carrier diagrams, facility evidence, prefix mapping, RPKI checks, restore tests and contract-specific support procedures.

Medyabim's public footprint is strongest where it names identity, services and one current route. It is weakest where a customer most needs proof during failure: utility power, cooling, physical fibre diversity, active carrier redundancy, current IPv6, support escalation, backups, exit and tested recovery. That is exactly where due diligence should concentrate before critical workloads are placed behind the brand.