02 Emre Erim trading as Medyabim Datacenter must prove whether the marketed data centre capacity can survive power and connectivity constraints

Summary

• Public RIPE records give Medyabim a consistent legal and network identity. TheRIPE RDAP registry for AS44922names MEDYABIM-AS, lists Emre Erim as administrative and technical contact, and includes ORG-MIH2-RIPE with the name “Emre Erim trading as Medyabim Datacenter”; theRIPE organisation registryshows country TR, LIR status, an address in Bursa and contact details.
• The current routed surface is real but narrow. TheRIPEstat AS overviewmarked AS44922 as announced, while therouting statusshowed one IPv4 prefix, no IPv6 prefixes, 256 IPv4 addresses and one observed neighbour at the verified snapshot. Theannounced prefixes viewlisted only 37.247.116.0/24 as current.
• The strongest positive control is route origin security for the current /24. TheRIPEstat RPKI validation for 37.247.116.0/24 via AS44922returned valid, with a ROA authorising AS44922 and a maximum length /24.
• Medyabim’s own pages market a broader operational footprint than the current AS44922 route surface proves. Thedata centre pageclaims dedicated hardware ready in Medyabim racks, long experience with Linux DirectAdmin servers, server options in Turkey and abroad, a total 50 Gbit/s egress capacity, named provider paths such as Turk Telekom and Superonline, and customer traffic monitoring. Thecolocation pageclaims 99% service continuity with bandwidth, 24/7 support, placement behind a firewall, a free reboot port and five IP addresses.
• Public assurances remain incomplete. The official pages do not publish dual power 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 that 185.7.83.0/24 is currently announced by DATAFOREST rather than AS44922, so client-side dependency maps must separate the Medyabim brand, its AS44922 edge, allocated address space and service surfaces announced by third parties.

The useful question is not whether Medyabim exists

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

The strongest identity source is RIPE. TheRDAP record for AS44922names the autonomous system MEDYABIM-AS and lists the organisation “Emre Erim trading as Medyabim Datacenter”. It also lists Emre Erim as administrative and technical contact, with an address in Bursa and a telephone number. TheRIPE organisation REST record for ORG-MIH2-RIPEcarries the same trading name, country TR, LIR type, Bursa address, telephone, fax, Medyabim maintainer references, and creation date in March 2008. This is much stronger than a web-scraped hosting directory entry.

Medyabim’s owncontact pageindependently anchors the public operational 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 telephone numbers and the public email address[email protected]. This address matches closely 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 website are at least mutually consistent.

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

The question therefore is not “is there a Medyabim?”. The question is “which parts of the capacity marketed by Medyabim can a customer rely on when power, cooling, routing, support or upstream dependency fail?”. For a data centre or colocation buyer, identity is only the first door. The hardest test is recoverable capacity: the hardware, rack power, cooling, fibre, routing and human processes that remain available during an outage.

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

RIPEstat confirms that AS44922 is announced. TheAS overview endpointlabels the holder “MEDYABIM-AS Emre Erim trading as Medyabim Datacenter” and marks the resource as announced at the verified snapshot. That is the positive network conclusion. Medyabim has a public autonomous system edge that the routing system can see.

The scale of that edge is modest. Therouting status endpointfrom RIPEstat showed one IPv4 prefix, 256 IPv4 addresses, zero IPv6 prefixes and one observed neighbour. Theannounced prefixes endpointlisted 37.247.116.0/24 as AS44922’s current announcement. TheASN neighbours endpointshowed a single observed left neighbour, AS16276. TheRIPEstat AS overview for AS16276identifies that neighbour as OVH SAS.

This does not mean Medyabim has only 256 customers, a single rack or a single service. Public BGP does not see private VLANs, reseller stock, provider-addressed hosting, server inventory, customer interconnects or outsourced web surfaces. But it does mean that the visible AS44922 edge is not a wide, multi-prefix, multi-neighbour public backbone at the time of verification. If a buyer evaluates Medyabim as a data centre dependency, the public BGP map alone does not prove multi-operator resilience.

TheRIPEstat AS routing consistency viewmakes the gap sharper. It listed 37.247.116.0/24 as present in both BGP and the RIPE whois/IRR. It also listed 37.247.117.0/24 and 2a03:400::/32 as present in the whois/IRR but not in BGP at the verification moment. The same consistency view showed old 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. This is a normal sort of drift in older routing records, but it is exactly why a customer should ask for current diagrams instead of relying on historical registry policy text.

The positive check is RPKI. AS44922’s current route, 37.247.116.0/24, passed theRIPEstat RPKI validation checkas valid. This matters because route origin authorisation is one of the few public checks a hosting buyer can verify without seeing private facility documents. A valid ROA does not prove power, cooling or failover. It shows that the current visible 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 RPKI valid. Its observed upstream surface is thin. Its IPv6 evidence is not currently announced. Its public routing policy records are limited public evidence to prove carrier diversity or failover. A customer should not treat this as a ghost network, nor as a proven resilient data centre network.

IPv6 and dormant prefix evidence require a downgrade

Medyabim has IPv6 registry evidence. The RIPE search record for2a03:400::/32shows an allocation 2a03:400::/29 under TR-MEDYABIM-20110107 and a route6 entry for 2a03:400::/32 with origin AS44922. This looks solid until compared with current routing visibility.

TheRIPEstat prefix overview endpoint for 2a03:400::/32marked the prefix as not announced at the verification moment. Therouting status viewreported no current origin, zero RIS peers seeing it, and a last-seen event for AS44922 on 1 April 2026. This is not a failure conclusion in 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 proved 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 about IPv6 support, its unavailability, selective availability, or provision via another provider.

The IPv4 dormant prefix picture is also mixed. The RIPE search result for37.247.117.0/24shows 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. This 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 allocated capacity and operational capacity. A RIPE allocation, a route entry or an address assignment can show administrative control or preparation. It does not prove that the address range serves customers today, is reachable through multiple operators, or can be activated during an outage. A buyer who needs recoverable capacity should ask Medyabim which prefixes are in production, which are reserved, which are migrated to other origins, which are customer-facing, which are management-only, 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’sdata centre pageis more detailed than a generic hosting landing page. It says that dedicated server models are delivered after payment validation and that hardware is ready in Medyabim racks. It says Medyabim has more than 15 years of experience with Linux dedicated servers and actively uses DirectAdmin since 2003. It says the company serves with its own server hardware based in Turkey, while dedicated server services can be chosen in Turkey or abroad according to demand. It also describes “high line capacity” and high availability as a reason for quickly offering real server hardware.

The same page makes a large connectivity claim. It says the data centre’s main internet connections were chosen 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 a total line egress capacity of 50,000 Mbit, i.e. 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.

This is useful evidence, but it must be read as marketing and operating text published by the company, not as a live carrier audit. The page does not disclose which of the named providers are current physical carriers, which are transit providers, which are peering or route relationships, which are historical transit options, which support Turkish services, and which support overseas placement. It does not show a facility meet-me room, diverse fibre entry, interconnection map or live port inventory. Public BGP at the verification moment showed one observed AS44922 neighbour, not a publicly visible map of every provider name on the page.

The page is even thinner on facility engineering. It does not publish dual power feeds, UPS capacity, battery runtime, generator fuel runtime, cooling redundancy, fire suppression class, floor loading, rack density, physical security layers, maintenance window rules or disaster recovery drills. These omissions do not prove that the controls do not exist. Many smaller providers do not publish such details. But a customer evaluating data centre resilience should not assume these controls from the word “data centre”.

Medyabim’scolocation pageadds customer-facing operational claims. It says Medyabim offers a 99% service availability or continuity guarantee with bandwidth for its colocation service; says businesses with servers in the Medyabim data centre can receive 24/7 enterprise support; says traffic statistics can be observed online; says servers are behind a firewall; says a free reboot port will be assigned; says the assigned connection is dedicated and not limited; and says five IP addresses are assigned free of charge for servers in the data centre.

These are real service claims, and they specify 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 significant amount of downtime over a year. A reboot port is useful only if the power distribution, remote access, console credentials and support procedures survive the incident. Firewall placement can protect customers, but it can also become a shared bottleneck. Five IP addresses may be enough for simple hosting, but it says nothing about routed subnet portability or failover.

The page gives customers items to ask about, not a complete proof of resilience.

The official site proves the offering breadth, not recoverable capacity

The public offering breadth is wide. Medyabim’sweb hosting packs pageadvertises hosting packs with web space, traffic, FTP, MySQL, webmail, DirectAdmin, optional SSL, email backup products, an additional IP service per server, a 300 GB server backup service, unlimited 24/7 FTP transfer, automatic weekly and monthly backups, advanced statistics, anti-spam filtering and a transfer report. Itsreseller pageoffers reseller packs with web space, POP3 email quotas, monthly traffic, MySQL databases, Turkish control panel, webmail, optional DNS control, SSL options, anti-spam filters and traffic reports.

TheVDS pageexplains virtual dedicated servers as logically separated servers on physical hardware and lists VDS pack features. Thecontrol panel information pagesays DirectAdmin is installed on servers when the server is in the Medyabim DC, describes proactive server management, security configuration and spam blacklist monitoring, 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. This mix creates two types of dependencies. One is physical: racks, power, cooling, uplinks, firewall, reboot ports, spare servers and technician access. The other is administrative: customer portal, billing, account status, support tickets, domain controls, DNS, email and backup processes.

The public offering does not tell the buyer which dependencies are in the same failure domain. A customer could buy a web hosting pack whose website, email, backups, DNS and ticket access all depend on the same provider systems. A reseller could depend on Medyabim’s control panel and email systems even though 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 fails, or the firewall policy blocks recovery access.

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

This is why installed capacity is not enough. The about page’s claim of over 500 servers and the data centre page’s claim of 50 Gbit/s egress capacity describe a possible scale. Recoverable capacity asks what happens after a power feed, UPS path, switch, firewall, uplink, auth path or support channel goes away. 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 that the apex and the www name resolve to 185.7.83.213, that mail.medyabim.com.tr also resolves to 185.7.83.213, that the nameservers are ns1.medyabim.com and ns2.medyabim.com, and that an SPF record references 37.247.112.0/24 and 185.7.83.0/24. These DNS facts must be treated as operation-adjacent evidence because they show how Medyabim presents its own service surface to the internet.

RIPEstat then changes the interpretation. Theprefix overview for 185.7.83.0/24showed the prefix announced by AS58212, and therouting status endpoint for 185.7.83.0/24listed the current origin AS58212, while noting that the prefix had first been seen from AS44922 in 2012 and had last been seen at the verification snapshot from AS58212. TheRIPEstat AS overview for AS58212identifies that origin as DATAFOREST dataforest GmbH. Similarly, theprefix overview for 37.247.112.0/24showed the current origin AS29141, and itsAS overview for AS29141identifies Bradler & Krantz GmbH & Co. KG.

This does not mean Medyabim misrepresents its service. Address space may be assigned, leased, migrated, routed by transit providers, hosted abroad or used for legacy services. RIPE search results for Medyabim show several 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 are currently attributed by public routing to other origin ASNs. The correct conclusion is not scandal; it is dependency mapping.

If Medyabim’s web, email or DNS surfaces depend on prefixes currently announced by other networks, then customers need to know which parts of their service are on AS44922, which parts are on externally originated address space, and which parts are abroad. This matters for outage analysis. If AS44922 has a problem, Medyabim’s public website or support email might still be reachable via another provider. If the external origin path has a problem, the Medyabim brand surface could fail even if the Bursa AS44922 route stays up.

If a customer buys a “Turkey” placement but the support, backup, DNS or email dependency lies elsewhere, the customer needs that marked 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 allocated address ranges not currently announced by its own ASN. A provider can sell hosting while depending on third-party route origins for parts of its own stack. None of these facts are disqualifying. All mean that failure analysis must be precise.

The silence on PeeringDB matters because the site names many paths

PeeringDB is a voluntary directory, so the absence of a network entity is not proof that a network lacks interconnection. Yet it matters for Medyabim because the official data centre page names many connectivity relationships and a 50 Gbit/s total egress capacity claim. APeeringDB API query for ASN 44922returned no network entity at the time of search. This removes a public source that could otherwise show exchange presence, facility presence, peering policy, traffic ratios, informational prefixes and self-declared interconnection locations.

Without a PeeringDB profile, a buyer is left with RIPE/RDAP records, RIPEstat BGP observations, Medyabim’s own pages, DNS and contractual language. That is workable, but it is not enough to prove diverse access to carrier meet-me rooms. Public BGP showed AS16276 as the current observed neighbour. Medyabim’s data centre page names Turk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX and ECIX Duesseldorf. This 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 meaningfully diverse. Are there multiple paying transit providers active for customer service, or a single visible upstream? Are some named names historical? Are some routes delivered via an upstream provider, a reseller or a remote interconnect? Does the Bursa facility have diverse fibre entries? Are Turkish and European paths physically separated? How much traffic can the surviving path carry during an outage?

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

Public evidence cannot answer these questions. It can identify the need to ask them. A 50 Gbit/s claim is a capacity assumption until there is evidence of current ports, contracts, utilisation 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 demand direct confirmation.

The service contract shifts risk to the customer

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

This combination is common in hosting contracts, but it is heavy with consequences. The public hosting pages may advertise automatic weekly and monthly backups, optional backup services, traffic reports and managed support. The service contract can still limit the provider’s liability if the customer did not buy or configure the right backup and restore process. A customer should therefore ask for the exact backup scope, retention, restore testing, restore time, backup isolation and whether backups sit in the same facility, provider network, account control plane or failure domain.

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

Medyabim’ssupport system help pageandonline help pageshow a ticket-oriented support posture. The data centre page says phone support is available during office hours, from 09:00 to 18:00, and outside those hours customers can reach the provider via a 24/7 ticket and email support system. The colocation page says businesses with servers in the Medyabim data centre can receive 24/7 enterprise support. These statements should be converted into incident procedures before a customer trusts the service: who can call, who can open emergency tickets, whether there is out-of-hours phone escalation, and how the provider distinguishes reboot, network, hardware, firewall, DNS and abuse incidents.

Power and cooling are the biggest public blind spots

The mission for this outreach is a data centre infrastructure review, and the main physical dependency is power, cooling, fibre meet-me room access, facility operations and local permits. Medyabim’s public pages give some facility-type claims but not enough engineering detail to support a high resilience confidence rating. The about page says the company built a data centre in Bursa with a capacity of more than 500 servers with its own resources. The data centre page says hardware is ready in Medyabim racks and 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.

These statements still leave the physical facility almost unobserved. There is no public claim of dual power feeds. 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 detail on smoke, fire suppression or water leak detection. There is no floor plan or facility certification. There is no statement on diverse fibre entries or meet-me room design. There is no maintenance window policy distinguishing planned, emergency and customer-requested work. There is no public incident history showing measured recovery.

For a small Bursa provider, some of this silence is understandable. Publishing too much facility detail can create a security risk. Smaller operators may also rely on upstream facilities, leased rooms, office-grade power arrangements, or mixed local and overseas server placements. But the risk for the customer remains the same. A “capacity of more than 500 servers” claim is not equivalent to usable power capacity after a distribution path fails. A “high availability” claim is not equivalent to tested generator runtime. A “reboot port” does not 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 built or says it can host. Sold capacity is what customers already use. Usable capacity is what remains after normal load, thermal limits, power reservations, maintenance and oversubscription. Recoverable capacity is what remains after a component failure. The public pages usually describe installed capacity. Customers need usable and recoverable capacity.

Medyabim’s current public evidence cannot settle this question. It can only set the evidence demand: power diagrams, UPS and generator runtime, cooling design, rack density policy, fire and water controls, carrier entry diversity, maintenance history, remote-hands procedure, spare parts policy and at least one documented failover or restoration 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 packs, VDS, dedicated servers, colocation, email storage and backups can find itself under many downstream services. A reseller pack can support tens or hundreds of small websites whose owners may not know Medyabim exists. A dedicated server can carry an enterprise application, a database, an agency portfolio, an email service or an online shop. A colocation customer can 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 stop servers even if upstream routes are healthy. A cooling event can force a shutdown or reduce allowed rack density. A single firewall failure can isolate many customers at once. A single upstream provider failure can affect AS44922 if no alternative path is active for the relevant prefix. A support or ticket failure can slow recovery even if the facility is intact. A DNS or email failure on externally originated address space can make Medyabim harder to contact while production traffic elsewhere still works.

A contractual or abuse suspension can remove service without a physical fault.

This is why the DNS discovery matters. If the public brand domain and email service use 185.7.83.213 under a prefix currently announced by DATAFOREST, and if the SPF references a 37.247.112.0/24 prefix currently announced 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, system 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, email continuity and a route origin authorisation. These questions are not hostile. They are the minimum work needed 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 wider allocation, and any customer services routed under AS29141, AS58212 or other origins. It should identify whether AS16276 is the only active upstream provider for the AS44922 route, whether other providers are active via private or unobserved agreements, and whether the provider names on the data centre page are current, historical, 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-hand 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 exist. If the service is abroad, ask which country, which facility, which provider and which legal conditions apply.

Third, ask for failover evidence at the customer level. Medyabim should be able to show what happens when an upstream provider 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 these tools behave during an outage.

Fourth, ask for data and exit controls. The hosting page mentions automatic weekly and monthly backups, optional backup, email backup products and a server backup service. The service contract limits Medyabim’s liability for service interruptions and data loss unless otherwise stated in the contract. Customers should demand restore tests, backup scope, retention, off-site status, encryption, access control, export process, domain transfer process, DNS export and email continuity.

Fifth, ask for proof that support can be reached when the usual website or email is unavailable. The contact page gives phone numbers and emails. The data centre page describes phone support during office hours and ticket/email support out of hours. Critical customers should demand named emergency escalation, authenticated contacts, an out-of-band phone procedure and a way to authorise remote hands without relying solely on the normal portal.

A reasonable evidence pack would not have to reveal sensitive floor plans. Medyabim could provide a customer-specific annex stating which facility serves the workload, which prefixes and origin ASN are used, which DNS and email services are in play, which upstream providers 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 testing, UPS maintenance, cooling maintenance, upstream failover testing, backup restore testing and route origin changes. These artefacts would answer the operational question without exposing customer names or sensitive security configurations.

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 can depend on Medyabim even when they buy from another brand. For dedicated servers, the buyer can control the operating system but not the rack, router, power path or spare parts. In colocation, the buyer can own the server but still depend on Medyabim for the building, power, support access and network edge. These differences determine who acts first during an outage.

The evidence rating

Medyabim earns a Medium public network evidence rating, with a downgrade for facility and resilience evidence. The identity layer is solid for a small provider: the RIPE RDAP and RIPE organisation records tie AS44922 and ORG-MIH2-RIPE to Emre Erim trading as Medyabim Datacenter, and the Bursa address matches 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 verified snapshot, and validates the route under RPKI.

The rating cannot be High because the operational evidence thins immediately after that. RIPEstat showed only one current IPv4 /24, no current IPv6 announcement and one observed AS44922 neighbour. PeeringDB returned no network entity for AS44922. The RIPEstat 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 announced by other networks.

Medyabim’s official pages publish helpful service claims but do not publish the power, cooling, carrier meet-me, maintenance and failover evidence needed to trust the marketed data centre capacity under stress.

The practical conclusion is not to reject Medyabim. The evidence supports a genuine Bursa-based hosting and data centre operator with long-standing RIPE records, a visible AS edge, official service pages and a concrete customer offering. Nor is the conclusion to accept the more-than-500-server and 50 Gbit/s claims as proof of resilience. Customers should treat these 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 a current route. It is weakest where a customer most needs evidence during an outage: power feeds, 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.