Hosting-27 Hosting-27 LTD sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Hosting-27 Hosting-27 LTD is not a company visible only in routing records. The live Hosting27.com homepage advertises Bulgarian hosting and cloud services, the contact page gives a Sofia address, phone and support email addresses, the client area exposes a customer login and invoice portal, and the support-ticket page describes a support department working every day. That public sales surface is real, but it does not by itself prove where the servers sit or how outages are repaired.
• The network identity is concrete and compact. The RIPE Database AS42347 entity names Hosting-27, links the AS to ORG-HA629-RIPE, lists Hosting-27 LTD as the organisation, gives country BG, registration number 204354361 and a Sofia address, and records imports and exports with AS57344 and AS31083. The RIPE 217.174.144.0 - 217.174.144.255 inetnum and 217.174.144.0/24 route object tie the visible IPv4 block to Hosting-27 and AS42347.
• The live route view is narrower than the marketing menu. RIPEstat's AS overview showed AS42347 announced on 12 July 2026, and its routing-status view showed one visible IPv4 prefix, 256 IPv4 addresses, no visible IPv6 and one observed neighbour. RIPEstat's ASN-neighbours view identified that neighbour as AS57344, and RIPEstat's AS57344 overview identifies AS57344 as Telehouse EAD. A second peer, AS31083 Telepoint, appears in the AS42347 registry policy but not in the current BGP consistency view.
• The operating grade is a qualified medium, not strong. Product pages for shared hosting, Cloud VPS, managed Cloud VPS, private cloud and Kubernetes show a broad hosted-capacity offer. The public evidence does not show a named data-centre hall, cabinet count, power design, hardware stock, customer backup-retention terms, active dual transit, IPv6 service or a written portability path.

The service surface is visible, but it needs to be read from the rack outward

Hosting-27 Hosting-27 LTD should not be mistaken for an empty internet-number record. The public Hosting27.com site is live, dated by its own header metadata and visible pages, and built as an operating hosting storefront. The homepage presents the brand as a provider of hosting and cloud services. It points buyers toward WordPress hosting, Kubernetes clusters, private cloud, Cloud VPS, managed Cloud VPS, reseller hosting, domains, a client area, invoices and support tickets. The navigation is not an abandoned one-page placeholder; it is a hosting retail surface with product tiers, order buttons, a WHMCS-style account area and a support portal.

That makes the inquiry more demanding, not less. When a company sells web hosting or cloud servers, the customer's dependency is not the web page. The dependency is the hidden stack under the invoice: a host node, a storage back end, switching, routers, IPv4 stock, upstream transit, power, cooling, remote hands, billing state, abuse handling and a support team with authority to act. Hosting27's public material describes several customer-facing products, but it does not identify the facility or facilities behind them.

It does not say whether Hosting-27 operates its own racks, leases cabinet space, depends on another Bulgarian data-centre operator, or resells capacity assembled by a related provider.

The product menu matters because it tells customers what kind of physical system would have to exist. The shared-hosting page advertises three plan sizes with 20 GB, 50 GB and 165 GB of space, cPanel, unlimited sites, unlimited mailboxes, free SSL certificates, CDN, migration help, multiple PHP versions and one-month backups. The WordPress-hosting page advertises similar 20 GB, 50 GB and 165 GB tiers, adds WordPress management and promises help moving WordPress sites. The reseller-hosting page offers 40 GB, 75 GB and 130 GB plans with WHM access, unlimited traffic and unlimited accounts. Those are not abstract cloud slogans. They are claims that shared physical or virtual hosts exist, that accounts can be created on them, and that migrations and backups are part of the service promise.

The cloud menu raises the stakes. The Cloud VPS page advertises instances from one to four virtual CPUs, 1 GB to 6 GB RAM, 30 GB to 85 GB all-SSD storage, daily backups, a management panel, OpenStack, KVM and Ceph. It also sells additional IP addresses, additional system backups and thirty-minute system-administration blocks. The managed Cloud VPS page advertises managed servers with a control panel, technical support, daily backups, round-the-clock monitoring and free migration. The private-cloud page goes further, describing an OpenStack-based virtual data-centre offer with software-defined storage, a 99.99 percent service-level claim, a doubly secured network and API services such as Cinder, Nova, Heat, Glance, Magnum, Neutron and Keystone. The Kubernetes page describes help installing, configuring and maintaining a highly available Kubernetes environment and says the service covers infrastructure, networking and load balancers as one of its layers.

Those pages give Hosting27 a stronger public sales surface than many small hosting networks. They also create a larger evidence gap. A one-node VPS seller can fail quietly. A seller of OpenStack, Ceph, private cloud and Kubernetes has to answer more: how many physical nodes are available, how storage replication is isolated, whether control-plane components have independent failure domains, where backups sit, which address pool serves customers, which router carries the route, and who can repair the system when the physical layer fails.

The safest starting point is therefore neither dismissal nor blind trust. Hosting-27 has a visible website and a visible AS. The public record supports the existence of a Bulgarian hosting operation. It does not support a strong conclusion about installed cloud capacity, multi-site recovery or provider independence.

The RIPE record gives Hosting-27 a small but real network edge

The clearest infrastructure evidence is in the RIPE Database and RIPEstat. The RIPE aut-num record for AS42347 names the AS "Hosting-27", lists Hosting-27 LTD through ORG-HA629-RIPE, records ASSIGNED status, gives creation on 24 August 2017 and last modification on 7 April 2021, and records import and export policy for AS57344 and AS31083. The linked organisation record names Hosting-27 LTD, country BG, registration number 204354361, organisation type OTHER, a Sofia address at Todor Aleksandrov 133, and an abuse contact at GLAC2-RIPE. It was created in August 2017 and last modified in May 2026.

The IPv4 assignment is equally explicit. RIPE's inetnum for 217.174.144.0 - 217.174.144.255 uses netname Hosting-27, country BG, organisation ORG-HA629-RIPE and status ASSIGNED PA. RIPE's route object for 217.174.144.0/24 describes Hosting27 and authorizes origin AS42347. RIPEstat's announced-prefixes view showed 217.174.144.0/24 visible in the two-week window ending 12 July 2026. Its routing-status view showed one IPv4 prefix, 256 IPv4 addresses and full IPv4 visibility across 326 of 326 RIPE RIS peers at the checked time.

That /24 is not just a passive record. The Hosting27.com domain itself resolves into the same block. RIPEstat's DNS-chain view for hosting27.com resolved hosting27.com to 217.174.144.181, reverse-associated that address with shared-11.cpaneler.com, and listed authoritative nameservers including ns1-pns.hosting27.com and ns2-pns.hosting27.com. The domain RDAP record for hosting27.com shows the domain registered on 12 July 2013, expiring on 12 July 2027, with PublicDomainRegistry.com as registrar and nameservers under hosting27.com. The visible website, DNS and routed prefix therefore line up around the same public network footprint.

The address pool is small. A /24 contains 256 IPv4 addresses before router interfaces, infrastructure hosts, nameservers, shared-hosting IPs, customer assignments, spare addresses and reserved capacity are counted. That is enough for a real hosting business, especially if many shared-hosting customers sit behind name-based virtual hosts and if small VPS plans can share hosts without each receiving multiple public addresses. It is not enough to infer large installed capacity.

A private-cloud offer, a Kubernetes offer, reseller accounts, managed VPS and shared hosting can all be sold from a compact public address pool if internal addressing, NAT, virtual hosting and careful assignment are used. They can also be oversold if planning is loose. The public route does not distinguish those cases.

There is also a second route object that should be handled carefully. RIPEstat's AS-routing-consistency view lists 45.151.89.0/24 as present in whois but not in BGP for AS42347 at the queried time. A RIPE search for 45.151.89.0/24 shows a route object for AS42347, but the inetnum belongs to Geytit OOD, not Hosting-27 LTD, and the route was not part of the current visible announced set. That means it is possible route policy was prepared for another pool, or that the route was inactive, reserved, historical or not visible at the query time. It should not be counted as customer-available Hosting-27 capacity unless current BGP and commercial evidence support it.

The network edge is therefore real but tightly scoped: one visible AS, one visible IPv4 /24, a valid route object, a live website inside the block and no visible IPv6 prefix for AS42347 in the RIPEstat route view.

The office, the website and the contracting name are not the same as a verified data hall

The public address trail is useful, but it does not identify a data centre. Hosting27's contact page gives Sofia, Todor Aleksandrov Boulevard 133, floor 2, plus a phone number and support and sales email addresses. The RIPE organisation record for Hosting-27 LTD gives a matching Todor Aleksandrov 133 address. The Geytit OOD RIPE organisation record also uses Todor Aleksandrov 133 and appears as the sponsoring organisation on the AS42347 record. These records are meaningful for contact and registry administration. They do not prove that customer servers sit in that building, that Hosting-27 owns racks there, or that the company has direct access to power and cross-connect infrastructure.

The public legal terms add another boundary. The Hosting27 general-terms page embeds a PDF, and the PDF terms state that the service terms regulate shared hosting, SSL certificates, domain registration, virtual servers and managed virtual servers through the Hosting27.com site. The PDF names Cloud Systems OOD as the provider in the Bulgarian terms and gives a different company registration number. This article does not treat that as a corporate relationship finding. It treats it as a buyer diligence issue: the brand, RIPE organisation, sponsoring LIR, web terms and invoice issuer need to align before a customer treats the service as a dependable infrastructure contract.

This boundary matters during failure, not only during procurement. If a VM fails at 02:00, the customer needs to know which entity controls the support queue, which entity owns or leases the hardware, who can authorize remote hands, who can replace a drive, who controls the router session, who invoices for the service and who can preserve data if billing is disputed. A mismatch among brand, AS holder and contract provider is not inherently bad; many hosting groups use separate legal vehicles for address resources, customer contracts, facilities and operations. But the public materials reviewed here do not explain that structure.

Customers should ask directly.

The terms also make clear that hosted service is a bounded offering, not a guarantee that every customer receives a fully independent environment. The PDF says shared hosting involves customers sharing common server resources such as speed, RAM and network connectivity with other users. Its managed-virtual-server section describes administration of a virtually separated server with a control panel, round-the-clock support, guaranteed resources not shared with other client applications, monitoring, reaction to problems and regular backups. That is useful language for understanding the intended service classes.

It still leaves restore time, backup location, snapshot retention, offsite replication, customer export format and outage credits unclear in the public view.

The private-cloud page's "virtual data centre" framing is especially important to qualify. A customer reading that phrase may imagine a dedicated data-centre zone. The page itself is describing an OpenStack abstraction: customer-created networks, routers, load balancers and storage services. Those are virtual control-plane features. They still sit on physical nodes, disks, network cards, top-of-rack switches, power feeds and transit links. Without a named facility or architecture statement, the claim should be treated as a cloud-control-plane offer, not as proof of a separate physical site.

The visible upstream dependency is Telehouse, while Telepoint is a policy possibility

The route picture is straightforward at the current observation point. RIPEstat's ASN-neighbours view for AS42347 reported one unique neighbour at the latest time available: AS57344. RIPEstat's AS overview for AS57344 identifies AS57344 as TELEHOUSE-AS Telehouse EAD. The RIPE AS57344 aut-num shows Telehouse with a broad upstream and exchange policy, including Arelion, Cogent, GTT, Level 3, Liberty Global, NTT, Orange, PCCW, RETN, Seabone, Tata, Telxius and several exchange fabrics. PeeringDB's AS57344 record describes Telehouse as having global scope, IPv6 support, many exchange presences and facility entries.

That Telehouse breadth helps explain how Hosting-27's /24 can be visible from global collectors. It does not automatically make Hosting-27 multi-homed. The immediate dependency observed for AS42347 is still one neighbour. If the AS42347 route is carried only through Telehouse at the active edge, then a Telehouse-side issue, session issue, route filter, facility incident, cross-connect problem, commercial hold or maintenance window can affect all customers using the visible Hosting-27 prefix. Public route collectors can miss private backup paths, temporarily idle sessions or arrangements that become active only during failure.

But the burden is on the provider to show such redundancy, because the current public BGP view does not.

AS31083 is the second name to handle with precision. The AS42347 RIPE aut-num lists import and export policy with AS31083, and RIPEstat's AS31083 overview identifies AS31083 as Telepoint Ltd. The RIPE AS31083 aut-num shows Telepoint connected to several upstreams, and PeeringDB's Telepoint record reports a smaller European-scope profile. But RIPEstat's AS-routing-consistency view shows AS31083 as present in whois policy and not present in BGP for AS42347 at the queried time. That means the registry policy alone should not be described as active diversity.

PeeringDB absence for Hosting-27 reinforces the need for caution. A PeeringDB query for AS42347 returned no public network entity. Many small networks operate without a PeeringDB profile, so absence there is not a fault. It does mean there is no public Hosting-27 facility list, exchange list, looking-glass page, traffic estimate, peering policy or NOC profile in that directory. The only public interconnection trail is the RIPE policy, route collectors and the identities of the observed or registered upstreams.

The route-origin security result is positive. RIPEstat's RPKI validation for 217.174.144.0/24 reports a valid ROA for AS42347 originating the exact /24 with max length /24. That helps networks that enforce route-origin validation accept the route as authorized. It does not protect against host failure, storage failure, router misconfiguration, unpaid upstream bills, control-panel compromise or a customer account lockout. RPKI answers who may originate the prefix, not whether the hosting service can recover.

For buyers, the transit diligence question is practical: is Telehouse the active upstream for all Hosting27 services, is AS31083 a standby or historical policy entry, can either path carry the customer's workload during maintenance, and are routes announced from physically separate handoffs or from the same room and dependency chain?

Advertised cloud features do not equal installed, usable or recoverable capacity

Hosting economics rewards efficient sharing. Shared hosting sells disk, mail and site management by pooling many customer accounts on one or more servers. VPS hosting sells virtual CPU, RAM and storage slices from larger hosts. Managed VPS adds support labour, monitoring and administration. Private cloud adds an orchestration layer and a stronger promise of customer control. Kubernetes adds another orchestration layer above that. Each layer can be real while still depending on a small number of physical nodes.

Hosting27's pages make broad claims that are plausible for a small Bulgarian provider but impossible to size from the outside. The shared-hosting plans advertise unlimited sites, mailboxes and traffic, but those are plan rules, not infinite capacity. The service still depends on CPU, RAM, storage I/O, inode limits, fair-use rules, spam control and abuse handling. The reseller plans advertise unlimited traffic and accounts, but the storage caps are 40 GB, 75 GB and 130 GB; the actual constraint may be I/O, outgoing mail reputation, account density or shared-host performance before raw disk is exhausted.

The VPS pages are more concrete because they list virtual CPU, RAM and SSD values. A one-vCPU, 1 GB RAM, 30 GB SSD Cloud VPS plan and a four-vCPU, 6 GB RAM, 85 GB SSD plan can be provisioned from a modest OpenStack cluster. But a plan table does not show how many instances can be sold without contention, how many nodes exist, whether CPU is oversubscribed, how storage replication is tuned, whether Ceph spans independent power domains, or whether backups are stored on the same physical system they are meant to protect.

The page says Ceph keeps data replicated in several places; a customer still needs to know whether those places are separate disks, separate chassis, separate racks or separate facilities.

The private-cloud page's 99.99 percent service-level language should be treated as a claim to verify, not as proof of the achieved operating state. Four nines of availability allows only a small amount of downtime over a year, and it requires both architecture and operations discipline: redundant power, redundant network paths, carefully managed storage, tested control-plane recovery, change management, monitoring and a support team able to act quickly.

The public site does not publish the SLA document, credit schedule, measurement method, exclusions, planned-maintenance treatment or incident history that would allow a buyer to evaluate that promise.

The address stock limits some use cases. A customer who needs many public IPv4 addresses, mail-service separation, IP-based SSL legacy compatibility, anti-abuse isolation or VPN endpoints should ask how much IPv4 is actually available. The RIPEstat routing-status count of 256 IPv4 addresses is not the same as 256 sellable customer IPs. Some are consumed by infrastructure, DNS, shared hosting, management, reserves and customer allocations. Additional IPs are sold on the Cloud VPS page, which makes the pool operationally important. If abuse or blacklist problems affect a portion of the /24, the small address pool can make recovery harder.

IPv6 is another gap. Hosting27's public product pages reviewed here do not make a strong IPv6 promise, and RIPEstat shows no visible IPv6 announced space for AS42347 at the checked time. A customer needing IPv6-enabled hosting should not infer it from the word cloud. They should ask for an IPv6 test address, SLA coverage, firewall handling, reverse DNS, routing evidence and whether IPv6 support is available on shared hosting, VPS, private cloud and Kubernetes in the same way as IPv4.

The article's capacity conclusion is therefore conservative: Hosting27 sells a real set of hosting and cloud products, and AS42347 gives those products a real public network edge. But there is no public evidence that translates the plan menu into installed nodes, available spare capacity, multi-site design or customer-recoverable images.

Support and backup claims are useful, but repair authority is the core question

Support evidence is better than silence. Hosting27's contact page lists support addresses, including support and devops mailboxes, and a separate sales address. The support-ticket page says customers who cannot solve a problem in documentation can send a request to the appropriate department. It describes support as working every day without interruption and sales inquiries as processed Monday through Friday from 09:00 to 18:00. The knowledgebase has categories for cPanel, Virtualmin, VPS servers, WordPress, domains and shared hosting. The announcement page contains an older 2018 website announcement, which at least shows that the customer portal has been part of the service surface for years.

Those are helpful operating signs. They are not enough to answer repair-window risk. The most important distinction is between a support channel that receives tickets and an operations team with authority over the failing component. If the fault is a cPanel setting, the provider's helpdesk may fix it quickly. If the fault is a dead disk, a failed switch, a power-feed issue, a storage-cluster quorum problem, an upstream route filter or a locked billing account, the repair depends on who controls hardware, facility access, route sessions and contractual permissions.

The general terms are also useful but incomplete for incident planning. The PDF says managed virtual servers include round-the-clock technical support, monitoring and reaction to problems, regular backups and the ability to host customer applications. It says shared hosting includes technical support and makes clear that shared users share resources. The public pages additionally advertise daily backups on Cloud VPS and managed Cloud VPS, one-month backups on shared hosting and free migration for some plans. That is valuable.

It still leaves the practical questions open: are backups on the same cluster or offsite, how many generations exist, can a customer restore self-service, can a VM image be exported, what happens after account suspension, and what is the target restoration time?

The migration promise is also narrower than it looks. Hosting27 says it can move a hosting account or WordPress site for free. That helps during onboarding. It does not necessarily create an exit path. A customer that later leaves may need a full cPanel backup, a database dump, DNS zone files, mailboxes, VM disk image, block-storage snapshot, entity data, Kubernetes manifests, container images, secrets and IP renumbering. The public site does not describe export formats, retention windows, migration fees after cancellation or whether customers can take images out of OpenStack.

Abuse handling matters because hosting providers live and die by shared reputation. The RIPE organisation record for Hosting-27 points abuse to GLAC2-RIPE, a GateIT abuse contact. That is a registry abuse path, not necessarily the same as a retail support desk. A customer running mail, ecommerce or public APIs should ask who manages reverse DNS, who handles blacklist remediation, who decides whether one compromised account causes wider suspension, and whether IP reputation issues can be isolated inside the /24.

The public support posture is therefore credible enough to count, but not detailed enough to remove operational risk. Buyers should test the ticket desk before moving important workloads, ask for an incident contact path, and request written backup and export terms rather than relying on plan-page shorthand.

Data locality is not settled by a Bulgarian address or a Bulgarian IP

Hosting27's Bulgarian surface is relevant. The website is Bulgarian-language, the contact page gives Sofia details, the RIPE organisation and address are Bulgarian, the ASN is in the RIPE region, and the visible IPv4 block is registered with country BG. For customers with Bulgarian users, a Bulgarian invoice, local language support and latency to Sofia or regional networks may be reasons to consider the service. For customers with regulatory or contractual data-locality requirements, those signs are only the beginning.

The EU and Bulgarian context makes the distinction important. The European Commission's overview of the EU data protection legal framework explains the EU-wide data-protection regime. Its page on controllers and processors explains the distinction between the party deciding how personal data is processed and a party processing it on behalf of another. The Commission's standard contractual clauses page covers data-transfer tools for situations outside the European Economic Area. Bulgaria's Commission for Personal Data Protection is the national supervisory authority. This article is not legal advice, but those public references show why infrastructure location, support access and backup geography are not cosmetic details.

A Bulgarian IP address does not prove that all data stays in Bulgaria. Shared-hosting backups could be stored in another facility. Monitoring could be performed from elsewhere. A support ticket could include personal data. A control panel could depend on third-party software or external authentication. A CDN feature could intentionally place static content in other countries. A domain-registration service necessarily interacts with registries and registrars outside the hosting node. A private-cloud customer may create networks and volumes in a Bulgarian-looking console while some management or backup components sit elsewhere.

The right diligence questions are therefore concrete. Where is the primary compute node? Where are snapshots and backups stored? Are support staff and remote administrators inside the EU? Does the provider offer a data-processing agreement? Which legal entity is the processor for hosting services? Does the contract name the same party that invoices the customer? If data leaves Bulgaria or the EEA, which transfer mechanism applies? What happens if the customer requests deletion or export? Which logs are kept, and for how long?

These questions are not special suspicion toward Hosting-27. They are normal for any small cloud or hosting provider that markets locality. The public evidence here supports a Bulgarian service area and a Bulgarian routed edge. It does not prove a complete Bulgarian data-residency architecture.

The failure paths to test are rack, upstream, hardware stock, support, billing and migration

The first failure path is the rack. If a shared-hosting server or VPS host fails, who touches the machine? A customer should ask where the rack is, who owns the host hardware, how power is protected, whether there are spare nodes, whether storage is local or distributed, and whether a failed node can be evacuated without changing the customer IP. The public website claims backups and cloud features, but it does not name the physical facility, cabinet, remote-hands provider or spare-hardware plan.

The second path is upstream transit. RIPEstat currently sees AS42347 through AS57344. The provider should be able to say whether the route has a second active upstream, whether Telepoint is active, standby or historical, whether the backup route is tested, whether route-origin validation is monitored, and whether customers receive notice before network maintenance. A valid RPKI result is good. It is not the same as a second path.

The third path is hardware and storage stock. VPS and private-cloud offers depend on the ratio between sold plans and available compute, RAM, disk I/O and storage replication. A customer should ask whether advertised resources are guaranteed, whether CPU is oversubscribed, whether Ceph spans separate hosts or separate racks, how many failures can be tolerated, and whether there is enough spare capacity to restore a host during a busy period. The public page names OpenStack, KVM and Ceph, but those names can describe anything from a small cluster to a larger multi-rack environment.

The fourth path is support escalation. Hosting27 exposes support, sales, knowledgebase and ticket pages. The buyer should still test response quality, ask who is on call, identify the emergency path for a down VM, and ask whether support can reach the network and facility operators directly. A sales response is not the same as incident authority.

The fifth path is billing and legal continuity. The website's PDF terms name Cloud Systems OOD as provider, while RIPE names Hosting-27 LTD as the network organisation. Customers should ask which party signs the contract, which party invoices, which party controls service suspension, and which party is responsible for export and deletion after cancellation. If the account is suspended for billing or abuse, the customer should know how long data remains recoverable.

The sixth path is migration. For shared hosting, the exit path should include cPanel backup, DNS, mailboxes and databases. For WordPress, it should include files, database, redirects and DNS timing. For VPS, it should include disk-image export, snapshot format, IP renumbering and firewall updates. For private cloud and Kubernetes, it should include volumes, networks, load balancers, manifests, secrets and image registries. Hosting27 markets free inbound migration, but the public material does not publish a full outbound portability promise.

The seventh path is address reputation. A compact /24 can be efficient, but it gives less room to isolate compromised customers. Mail, proxy, scanning and abuse problems can lead to blocklists, upstream filtering or internal suspensions. Customers with mail or transactional workloads should ask for reverse-DNS control, abuse response procedure, blacklist cleanup policy and whether additional IP addresses come from the same 217.174.144.0/24 pool.

These are not theoretical concerns. They are the ordinary failure modes hidden under low-cost hosting: a rack that cannot be reached, an upstream session that disappears, a storage cluster that loses quorum, a backup that exists but cannot be restored quickly, a ticket queue that cannot reach the facility, and a customer who discovers too late that moving out means rebuilding around new IP addresses.

What would make the evidence strong

Hosting-27 Hosting-27 LTD has enough public evidence for a real operating profile: the website is live, the customer portal is live, the product pages are specific, the route is visible, the domain resolves inside the company's visible IPv4 block, the RIPE organisation is current, and the route-origin authorization is valid. That is materially stronger than a company whose only trace is a stale AS record.

The public evidence is not strong enough for high-trust infrastructure reliance without direct diligence.

A stronger profile would include a current legal page that aligns the brand, RIPE organisation and contracting provider; a facility statement naming the data-centre operator or explaining the hosting arrangement; an SLA with measurement and credit terms; a status page or incident archive; explicit backup retention and restore objectives; IPv6 availability if offered; an active second upstream or a written explanation of the Telepoint route policy; export formats for VPS and private-cloud data; and a clear abuse and IP-reputation procedure.

The likely customer set should be tiered by risk. A small Bulgarian website, staging server, non-critical WordPress site or experimental VPS can evaluate Hosting27 through ordinary service testing: order a small plan, test support, check latency, restore a backup and verify cancellation. A business-critical system should not rely on the plan table alone. It should obtain written answers on facility, backups, transit diversity, legal contracting and data portability before moving production.

The final reading is balanced. Hosting-27 Hosting-27 LTD is visible as a Bulgarian hosted-capacity seller with AS42347 and a live Hosting27.com platform. Its public operating story is not empty. But the decisive infrastructure facts remain behind the sales layer. Until those facts are disclosed or verified in a customer contract, Hosting27 should be understood as a compact, Bulgarian hosting and cloud-service provider whose customer promise still depends on unseen racks, Telehouse-visible transit, finite IPv4 stock, support labour, provider contracts and repair windows.