tsbg_hosting TSBG Hosting Ltd. sells hosted capacity that still depends on racks, transit and repair windows

Summary

• TSBG Hosting Ltd. presents itself as a Bulgarian infrastructure operator founded in 2006, with colocation, cloud server, dedicated server, shared hosting, streaming and managed-service offers on its own site.
• The strongest company-specific operating claims are physical rather than purely virtual: several carrier-neutral Bulgarian data-centre facilities, four data centres, TIA-942-oriented design, A/B power, monitoring, remote hands, fire detection, cooling and escorted access.
• The current public network signal is weak. RIPE RDAP identifies AS43112 as tsbg_hosting and records TSBG Hosting Ltd. as a registrant, but RIPEstat routing status showed zero visible IPv4 or IPv6 announced space for AS43112 on 2026-07-12.
• TSBG's 193.3.63.0/24 resource remains relevant because RIPE RDAP for the prefix identifies BG-TSBGHOSTING-20200902, and RIPEstat RPKI validation validated AS43112 as authorized for that prefix. Authorization is not the same as live reachability.
• PeeringDB's TSBG Hosting facility record adds a Haskovo/Svilengrad physical clue, while PeeringDB net-facility data ties the listed attachment to AS47288/FixNET rather than AS43112. That supports the need to verify operator boundaries before relying on any resilience claim.
• The evidence grade is Weak. The official site supplies rich service claims, but current public routing evidence does not independently prove live AS43112 customer traffic, multi-site failover, transit diversity, spare capacity or data portability.

A cloud invoice still lands in a Bulgarian machine room

TSBG Hosting Ltd. is not a name that can be assessed by brand recognition. It has to be assessed by tracing the service down to the equipment and people that would keep a customer online. The company sells services that sound elastic: cloud servers, VPS plans, dedicated servers, shared hosting, streaming, colocation and managed support. But every one of those services has a physical inventory behind it. A virtual server needs host capacity, storage, switching, power and cooling. A dedicated server needs a specific chassis and a replacement plan. Colocation needs a rack, a power budget, cable routes, access control and remote hands.

Streaming needs ingress, transcoding or handoff capacity and enough outbound bandwidth to carry the audience when demand rises.

The useful fact about TSBG is that the company does not describe itself only in vague cloud language. The official homepage markets colocation, dedicated servers, virtual servers, streaming and satellite antenna colocation. The same page describes four carrier-neutral data centres and sixteen years of experience, and says TSBG can support private cloud, disaster-recovery sites, dedicated Internet access, IPv4 addresses, DC power supply and satellite downlink. Those claims give a buyer a concrete list to test: buildings, racks, power domains, fibres, upstreams, servers, address resources and support arrangements.

The risk is that public marketing detail can still run ahead of verifiable operating evidence. A provider can own racks but outsource some network paths. It can have a valid ASN but not currently announce it. It can publish a service menu while individual plans depend on available stock, supplier support or a third-party facility. It can offer a recovery site while the customer contract leaves recovery objectives vague.

For TSBG, the public record contains exactly that mix: a specific service story, a specific Bulgarian identity, a specific AS number, and a gap between number-resource registration and visible route origination on the publication date.

That gap does not make TSBG unreliable. It changes the burden of proof. A customer should not treat the web price list or the ASN as an assurance report. The customer should ask which facility houses the workload, which network edge announces the service, which supplier has default-capable transit, how much power and spare hardware are reserved, and how data leaves the platform if the service has to be moved.

What can be identified with confidence

The company identity is stronger than the initial directory snapshot alone suggested. TSBG's site says the company was founded in 2006, is incorporated under Bulgarian law, lists EU VAT number BG175059953, names Ivan Shishkov as managing director, and gives a Sofia office address at 8 Racho Dimchev Street. The contact page repeats the Sofia address, phone number and sales email. RIPE RDAP for AS43112 identifies the entity name as tsbg_hosting and includes TSBG Hosting Ltd. as an organization entity with a Sofia address. RIPEstat whois data records aut-num 43112, as-name tsbg_hosting, organization ORG-THL32-RIPE, status ASSIGNED and maintainer mnt-bg-tsbghosting-1.

Those records are enough to avoid a common mistake in hosting research: treating a service name as a free-floating label with no accountable holder. Here, the holder can be tied to a Bulgarian company identity, a contact surface, a number-resource record and a visible service site. That is more useful than a reseller page with no address and no routing record.

The service scope is also specific. TSBG's colocation page advertises single-rack-unit, quarter-rack, half-rack and full-rack packages, with stated power amounts rising from 35 W for a rack unit to 1500 W for a full rack. The page also says the company can provide Internet connectivity, IPv4 addresses and LIR services. The cloud servers page lists VPS plans, SSD storage, RAID10 protection, 1 Gbit/s shared Internet and optional backups. The dedicated servers page describes redundant power supplies, RAID 1 or RAID 10, two network controllers and top-of-rack switch redundancy. The hosting page covers shared hosting and VPS hosting, including migration help.

That mix indicates a provider selling infrastructure at several abstraction layers. Customers can rent a slice of a shared platform, a virtual machine, a physical server, rack space, connectivity or support. The economic issue is that higher-level products inherit the lower-level constraints. If the rack loses power, the dedicated server and VPS plans attached to that site are affected. If the network edge loses a provider or a route object is withdrawn, an apparently separate hosting plan can still fail at the same time as colocation service.

If support is handled by the same small team that performs hardware replacement, a busy incident can turn a "free remote hands" promise into a queue.

The number-resource record is active, but the public edge was quiet

The most important network fact is not flattering, but it is precise. RIPEstat's AS overview for AS43112 identified the holder as tsbg_hosting TSBG Hosting Ltd., but marked the ASN as not announced for the 2026-07-12 query. RIPEstat routing status reported that the first seen route was 77.246.240.0/20 on 2007-06-14 and the last seen route was 193.3.63.0/24 on 2025-08-15, while current visibility was zero of 325 IPv4 peers and zero of 322 IPv6 peers. RIPEstat announced prefixes returned no current prefixes for AS43112 for the 2026-06-28 to 2026-07-12 window.

That does not erase TSBG's service claims. It says something narrower: public route collectors did not see AS43112 carrying live announced space on the publication date. A customer cannot use AS43112 alone as proof of current Internet service, transit diversity or customer traffic. If current services are delivered through a different ASN, a carrier-assigned address block, a provider network, a private interconnect or a managed upstream arrangement, that needs to be stated and tested directly.

The inactive public edge also changes how to read older evidence. RIPEstat routing history shows long historical activity for 77.246.240.0/20, 77.246.240.0/21 and 193.3.63.0/24, with the 193.3.63.0/24 route widely visible through much of 2022 to 2025 before falling to minimal visibility after mid-August 2025. History is useful for identity and continuity. It is not current capacity. If the same customers are still served, they may now be served through another network design. If the prefix was withdrawn because services moved, the migration path matters. If it was withdrawn because the service paused, a buyer needs to know before ordering capacity.

RPKI adds one more nuance. RIPEstat RPKI validation for 193.3.63.0/24 and AS43112 returned valid. That is positive administrative evidence: AS43112 is authorized to originate the prefix. But valid route-origin authorization is not the same as announcement. A smoke detector can be installed in a room that is currently empty; a ROA can exist for a route that is not visible in BGP. The control-plane right exists, while the operating path still needs live confirmation.

The site claims strong facilities, but the map is incomplete

TSBG's strongest public story is its physical facility story. The data-centre history page says the company was founded in 2006, completed its first data centre by September 2006, completed a second colocation project by July 2007, completed a third data centre as a disaster-recovery site with first equipment installed in July 2008, and completed a fourth data centre by October 2008. It also says that since 2014 TSBG has focused on colocation, hosting, server rental and managed services.

The data-centres page expands the facility claim. It says TSBG's sites are designed according to TIA-942, that locations are carefully selected, that the company guarantees 100% power availability, that power is designed in a fully diverse A/B configuration, that cooling is redundant by nominal capacity, and that physical security includes guarded sites, video surveillance and escorted access. It says monitoring covers server load, memory, disks, port traffic, equipment health, temperature, humidity, electric current, power consumption, air conditioning and optical-network performance.

Those are serious claims. They also require a buyer to ask for facility-specific evidence. "Four data centres" is a useful starting point only if the customer can identify which of the four will host its workload, whether the recovery site is active or standby, whether the sites share the same upstream, whether backup storage sits in a separate failure domain, and what contractual recovery target applies when a site is isolated. The public pages describe principles and capabilities. They do not name every building, power feed, fuel contract, carrier meet, spare inventory or tested recovery result.

The geography claim also needs careful handling. TSBG says its buildings are in Bulgaria and are geographically spread, more than 150 km apart, in zones selected to reduce flood, fire, traffic, industrial and human-activity risks. Its 2023 blog post on Bulgaria as a data-centre location says Bulgaria sits on important routes between Europe, Turkey and the Middle East, and says TSBG can provide protected Layer 2 and IP links via diverse routes to Istanbul, Sofia, Bucharest and European networks. That is a valuable regional thesis, especially for customers with Balkan, Turkey-facing or Europe-Middle East latency needs. But location advantage is not a substitute for live path evidence. A good corridor still needs contracted carriers, diverse ducts, working cross-connects and enough capacity after one link fails.

PeeringDB adds a Haskovo clue and an operator-boundary warning

PeeringDB gives the facility story a separate public clue. The PeeringDB facility API for facility 13672 lists "TSBG Hosting" in Haskovo, Bulgaria, with address1 "Byalo More 3 Kapitan Andreevo," state Svilengrad, country BG, a tsbg.eu website field, sales and technical phone/email, and available voltage service 480 VAC. The record was created on 2023-05-19 and updated on 2025-09-26. That is useful because it is outside TSBG's own site and points to a specific named facility surface in southern Bulgaria near the Turkey-Greece border context emphasized by TSBG's site.

But the same PeeringDB data creates a boundary problem. PeeringDB netfac data for facility 13672 shows one attached network entry named TSBG Hosting in Haskovo with local ASN 47288. PeeringDB network 26850 identifies that network as FIXNET TELEKOM LTD. STI., ASN 47288, with traffic scope Europe, open peering policy, seven facilities and three exchange attachments. RIPEstat's AS overview for AS47288 identifies the holder as FIXNET Telekomunikasyon Limited Sirketi and marks the ASN announced. RIPEstat routing status for AS47288 saw active IPv4 and IPv6 visibility on 2026-07-12, with 18 IPv4 prefixes and one IPv6 prefix in announced space at the routing-status layer.

This does not prove that FixNET operates TSBG's customer services. It does prove that the public PeeringDB facility attachment should not be casually read as AS43112 presence. For a buyer, that distinction is central. If TSBG sells colocation in a facility where another operator's ASN is the visible network attachment, the contract should explain whether TSBG, FixNET, another carrier or the customer provides default Internet service.

If TSBG sells VPS or dedicated servers using upstream connectivity rather than its own visible AS43112 route, the customer should know who can change routing, who opens upstream tickets, and whose maintenance calendar affects reachability.

The operator-boundary question is not academic. During an incident, the first responder may be TSBG support, the facility owner, a carrier, a remote-hands supplier or the network provider. The customer needs the escalation chain before the failure. A facility record that names TSBG and a network record that names AS47288 can both be true, while still leaving the customer exposed if the service contract does not map roles clearly.

Rack economics decide how much of the service is real

TSBG publishes unusually granular colocation prices and rack packages. The colocation service page lists a single rack unit, quarter rack, half rack and full rack, with power allowances and optional rack features. The page also says TSBG can provide 48 VDC as a standard option, A/B power from separate power rooms and UPS systems, power meters and ATS switches on request, monitoring, 24/7 support and Internet access. That gives customers a visible shopping cart for a facility service that usually hides behind sales calls.

The danger is that visible rack price is not the same as usable resilient capacity. A single rack unit with 35 W is a very different dependency from a full rack with 1500 W. A customer running telecom equipment may need DC power, dual PDUs and remote-hands access; a customer running compute may need more power, cooling and hardware replacement. A price list cannot show whether spare power is reserved, whether cross-connect work is fast, whether remote hands can swap a device during a regional storm, or whether the remaining network path can carry traffic when one supplier is out.

The small-provider economics matter here. TSBG says openly on its site that it is not the biggest data-centre operator and does not have megawatts of power or terabits per second of Internet capacity. That honesty is useful. It tells buyers to look for fit, not scale theater. A small site can be exactly right for a local business, border-route telecom project, disaster-recovery cabinet or low-latency Balkan service. It can also be wrong for a workload that assumes hyperscale spare pools, global cloud APIs or instant hardware replacement.

The buyer therefore has to translate package labels into failure math. If one cabinet power feed fails, does the customer equipment have dual supplies and dual PDUs? If one top-of-rack switch fails, are both server NICs cabled to independent switches? If one upstream is down, does the other path have enough paid commit? If one data centre is lost, are backups usable without the lost site? If a support person must travel to a remote site, what is the actual repair clock? Rack economics become risk economics once a failure starts.

VPS and dedicated servers inherit every lower layer

TSBG's VPS and dedicated-server pages are detailed enough to show where customer value comes from. The cloud servers page says VPS plans are based on Proxmox, use redundant hardware, RAID10 storage, redundant network and power supply server hosts, 1 Gbit/s shared Internet and optional backups. It lists plans from a small 512 MB RAM plan to larger multi-core plans. The dedicated servers page says servers have redundant power supplies, RAID 1 or RAID 10, hardware RAID controllers, two network controllers and different top-of-rack switches. It also mentions free OS installation, monitoring, 24/7 helpdesk and remote hands.

Those features are meaningful. They also create a verification agenda. A customer renting VPS capacity should ask whether RAID10 is local to a host, shared across a storage cluster, replicated to another site or backed up out-of-band. It should ask whether the optional backup is stored in the same facility, whether restore speed is measured, and whether backups include system images, file-level data, metadata and control-panel state. It should ask what happens when the host machine fails and whether live migration is available. It should ask whether resource contention can throttle recovery when many customers are affected at once.

A dedicated-server customer has a different problem. Redundant power supplies help only if each supply reaches an independent power path. Two network controllers help only if they are cabled to independent switches and routed through independent upstream capacity. RAID protects against a disk failure but not against a controller bug, a mistaken rebuild, ransomware or a full-site event. Free remote hands is useful only if parts are stocked and staff can enter the facility quickly.

The public route gap makes these questions more important. If AS43112 is not currently visible, TSBG's customer-facing Internet service may depend on provider-assigned routes, a transit partner, another ASN or a private design not visible in public collectors. That arrangement can be perfectly legitimate. It just has to be disclosed to the customer who is buying "Internet access" as part of a server plan. The customer needs to know which edge fails when the carrier fails.

Power, cooling and monitoring claims need tested evidence

The facility pages lean heavily on power and monitoring. TSBG says data-centre power is designed in fully diverse A/B configuration, starting from separate power rooms, distribution boards, UPS systems and cabling to racks. It says each rack has two or more PDUs, one for circuit A and one for circuit B. It says air conditioning uses redundant 1+1 or n+1 configuration, and that equipment rooms are held around 22 degrees C with relative humidity between 40% and 60%. It says fire detection uses an air-sampling system and gas suppression. It says monitoring covers a broad set of environmental, server, port and optical-network parameters.

Those are exactly the right domains to publish. The question is whether the claims are tested at the same level at which customers depend on them. A/B power is not proven by two cords if both circuits depend on one upstream panel, one fuel arrangement or one maintenance vendor. Cooling redundancy is not proven by nominal capacity if a hot aisle, sensor failure or air-flow change can remove headroom. Monitoring is not proven by having sensors if alert ownership, thresholds and emergency permissions are unclear.

TSBG's blog content gives useful hints about operational seriousness. The diesel generator maintenance post discusses generator oil, filters, coolant, batteries and winter readiness. The temperature monitoring post discusses SNMP, Zabbix, one-wire sensors, distributed monitoring and alarm design. The data-centre building-location post discusses site selection, disaster risks, concrete construction, roof design and telecom access. These posts are not certifications, but they show domain familiarity that is more specific than generic hosting copy.

The customer's next step should be evidence, not admiration. Ask for the last generator test date, the tested load, fuel runtime, UPS maintenance evidence, fire-system maintenance evidence, cooling-failure response plan, monitoring escalation sample and after-action notes from any real incident. Ask whether all four sites have the same maturity. Ask which site houses the specific customer service. Ask what fails together. That is how broad facility language becomes operational assurance.

Network resilience depends on upstream contracts, not only an ASN

TSBG's own pages say the company runs its own autonomous system and has BGP sessions with carefully selected providers. RIPE records identify AS43112, and RIPE whois remarks mention upstreams and data centre, with an import from AS47964 and an export to AS47964. RIPEstat AS routing consistency showed 193.3.63.0/24 in RIPE whois but not in BGP on 2026-07-12, and showed the AS47964 import/export in whois but not in BGP. RIPEstat ASN neighbours for AS43112 showed no observed neighbours on the publication date.

That combination tells a buyer to separate three things. The first is registry intent: the ASN, route object, ROA and whois relationships show what the operator is prepared or authorized to do. The second is live routing: public collectors show whether the route is currently visible and through whom. The third is service routing: a customer workload may use a different upstream or address plan not obvious from the TSBG ASN alone. Resilience depends on the third, but the public record mostly illuminates the first two.

The PeeringDB AS47288 evidence is also useful without being overread. FixNET, the AS47288 network attached to the TSBG Hosting facility record, was active in RIPEstat routing status and had PeeringDB exchange attachments at NetIX, TurkIX Sofia and RegPEX. That shows a live nearby network surface tied to the facility record. It does not prove that TSBG customer traffic uses that surface, that TSBG controls it, or that it is diverse enough for any given customer.

The customer test is straightforward. Ask TSBG to identify the ASNs, prefixes and upstreams that will carry the ordered service. Ask whether those paths are default-capable, whether they use separate physical entrances, whether they terminate in the same router pair, whether route filters are current, and whether Route Origin Validation is configured. Compare the answer against public tools such as BGP.tools for AS43112, Hurricane Electric for AS43112, Cloudflare Radar routing for AS43112 and RIPEstat. If the public ASN is intentionally quiet, that is acceptable only if the live service path is documented.

Support is part of the asset, not a help page

TSBG repeatedly highlights support. The site mentions 24/7 helpdesk support, remote hands, email, Viber and WhatsApp messaging, monitoring and free hardware replacement assistance. In a hosting or colocation service, support is not a soft extra. It is the channel through which invisible dependencies become repair actions. A router can be redundant, but somebody still has to identify which path is broken. A disk array can be protected, but somebody has to decide whether to rebuild, restore or fail over. A customer can own the server, but remote hands may be the only way to press a button, reseat a card or read a console.

The support question is particularly important for a smaller provider with several geographically spread sites. TSBG's own pages say the team is small but efficient, and that selected partners help with needed work and maintenance. That can be a strength when the customer needs flexible direct attention. It can become a weakness if an incident hits several customers, a site requires physical access, and the same people handle monitoring, communication, hardware and supplier escalation.

Customers should therefore contract support as infrastructure. They should ask what counts as an emergency, who can declare one, what response channel works if the portal is down, whether telephone or messaging escalation is guaranteed, whether remote hands has time limits, and whether parts are stocked on site. They should ask whether a colocation customer can authorize work in advance. They should ask whether a VPS customer gets restore help during a platform incident or only best-effort support. They should ask whether the support record names the affected site, upstream, rack or service layer, rather than only describing a generic outage.

Billing belongs in the same category. A service can fail through a disabled account, expired service term, blocked control panel or unclear responsibility for additional traffic. A customer using TSBG for a small disaster-recovery site should ensure that contact, invoicing, renewal and out-of-band access remain available during the exact event that makes the recovery site necessary.

Data locality is not solved by a Bulgarian label

The assignment region is BG, and TSBG's own story is strongly Bulgarian. The company is incorporated in Bulgaria, lists a Sofia office, describes Bulgarian sites, and markets Bulgaria as a strategic telecommunications transit location. For customers with European, Balkan, Turkey-facing or Middle East connectivity needs, that is a meaningful positioning claim. It can reduce latency, keep equipment under a Bulgarian provider relationship, and provide an alternative to larger Western European cloud regions.

But data sovereignty is not only a country code. A customer must identify where primary data, backups, logs, control-panel records, support tickets, monitoring data and billing records reside. A VPS plan might place the virtual disk in one Bulgarian facility and the backup in another. A shared hosting plan might use cPanel tools, third-party certificate services and external DNS. A streaming service might ingest signal from satellite or terrestrial paths and deliver it over a mixture of local and international transit. A colocation customer might own the hardware but rely on TSBG for remote access and IP service.

TSBG's public pages do not publish a full placement matrix. They do say the company runs several data centres in Bulgaria, that sites are geographically spread, and that it can provide protected links to Istanbul, Sofia, Bucharest and European networks. Those are good starting facts. They do not answer whether a specific backup crosses borders, whether a support supplier can access customer systems, whether logs are retained in a separate system, or how a customer receives a usable copy of data during a dispute or outage.

Data portability is therefore part of the resilience review. A buyer should test how to leave. For shared hosting, can the customer retrieve files, mailboxes, DNS records, databases and TLS records cleanly? For VPS, can it export an image or only files? For dedicated servers, is remote console access available if the network is unstable? For colocation, who controls IP renumbering, cross-connect release and hardware removal? The best time to test portability is before the service becomes critical.

Unofficial signals can suggest leads, not conclusions

Thin infrastructure subjects often leave traces in commercial aggregators, old BGP pages, pricing pages, search results, forum posts, social profiles and facility directories. TSBG is no exception. Public routing aggregators such as IPinfo's AS43112 page, BGP.tools, Hurricane Electric and Cloudflare Radar are useful for quick cross-checking. PeeringDB is useful for facility and interconnection clues. The official site is useful for service claims and contact information.

Those signals should not be treated equally. RIPE RDAP and RIPEstat are strong for number-resource identity and public route observation. PeeringDB is valuable but self-maintained and may lag reality. The official site is authoritative for what TSBG says it sells, but not independent proof that a given rack, fibre path or backup exists today. Aggregator pages are good for triangulation but can lag or represent data differently. Blog posts show technical thinking, not a live operating certificate.

The distinction matters most when public evidence conflicts. TSBG's official service pages repeatedly say the company runs its own AS with BGP sessions. RIPE records identify AS43112 and a valid ROA exists for 193.3.63.0/24. Yet RIPEstat did not see AS43112 announced on the publication date. That is not something to smooth over. It is the main finding. Either the public ASN is currently dormant, or current services are delivered through another network path, or the public collectors missed a limited announcement. Each possibility has different customer consequences.

What would settle it? A current looking-glass view from TSBG, a route table showing customer prefixes, an upstream list, a test IP for the ordered service, a traceroute and path-diversity result, a current status page, a facility-specific service description, and contract language naming responsible parties. Until those are available, the right editorial posture is caution.

How a buyer should test TSBG before placing a critical workload

The first test is identity and service fit. Ask TSBG to confirm which legal entity signs the contract, which site will host the service, which product layer applies, and whether the service uses AS43112, AS47288, a transit provider address block or another routing arrangement. Compare the answer to RIPE RDAP for AS43112, RIPE RDAP for 193.3.63.0/24, and public BGP observations. If the answer is that the public ASN is not currently used, ask why and what replaces it.

The second test is facility proof. For colocation, ask for the site name, rack position, power feed design, maximum draw, cross-connect options, remote-hands terms, access procedure and maintenance notification rules. For VPS or dedicated servers, ask which facility hosts the hardware, whether the recovery site is active, whether backups are off the failed host, and whether capacity is reserved for failover. Ask for a recent power, cooling or generator test result. TSBG's data-centres page gives a strong list of facility domains; the customer needs the site-specific version.

The third test is network independence. Ask for current upstreams, route filters, RPKI status, physical entrance diversity, interface speed, paid commit, DDoS exposure, and failover behavior. Ask whether the 99.999% Internet-connectivity claim applies to the customer product and how credits are calculated. Use public tools to check whether the ASN and prefix state match the answer, but do not rely on public tools alone if the service uses a private or partner path.

The fourth test is recovery. Run a small restore. Export a VPS image or rebuild from backup. Ask remote hands to perform a non-disruptive console or inventory task. Test out-of-band contact. Confirm who can authorize emergency changes. Confirm whether an account lock, unpaid invoice, domain issue or support entitlement dispute can stop recovery work. The public material describes a capable small operator; the customer's job is to prove that capability under its own failure scenario.

Who is affected when the system fails

The affected population depends on which TSBG product a customer buys. A shared-hosting customer is exposed to platform-level failures: cPanel, DNS, mail, storage and the provider's support path. A VPS customer is exposed to host, storage, network and backup domains. A dedicated-server customer is exposed to hardware stock, network edge, power feeds, remote hands and any managed-service layer. A colocation customer owns more of the stack, but still depends on TSBG for power, cooling, physical security, remote access and sometimes Internet transit.

For a local business, failure may mean website or email downtime. For a telecom or IT operator using rack space, failure can affect downstream customers, monitoring, backhaul, an antenna system or a disaster-recovery plan. For a media or streaming customer, failure can interrupt audience delivery. For a company using a Bulgarian site as an alternative to a larger Western European cloud region, failure can remove the very geographic redundancy the customer intended to buy.

The support surface also creates second-order effects. If the same contact handles sales, support and technical escalation, customers may receive personal attention during normal operations and slow response during a broad event. If a supplier path is involved, TSBG may be dependent on another carrier's repair clock. If the service uses a route not visible under AS43112, customers may monitor the wrong public edge and miss the real fault domain.

That is why the article's conclusion is not "avoid TSBG." It is "do not buy the abstraction without mapping the dependencies." TSBG's public material is unusually operational for a small provider. The missing proof is present reachability and tested failover for the specific customer path.

The evidence grade

TSBG Hosting Ltd. earns a Weak network evidence grade for this article. The grade is not a judgment of customer satisfaction or engineering skill. It is a judgment of what public evidence can prove on 2026-07-12. The official site gives strong company-specific service claims: four data centres, colocation, VPS, dedicated servers, shared hosting, A/B power, monitoring, remote hands, security, fire detection, cooling and Bulgarian transit positioning. RIPE records give a real TSBG number-resource identity: AS43112, ORG-THL32-RIPE and 193.3.63.0/24. RPKI validates the 193.3.63.0/24 origin authorization for AS43112.

The downgrade comes from the current edge. RIPEstat did not see AS43112 announced, did not see current AS43112 prefixes, and did not see current AS43112 neighbours. PeeringDB's TSBG Hosting facility entry adds a physical clue, but its visible network attachment points to AS47288/FixNET rather than AS43112. That may represent a valid partner or upstream arrangement; it does not independently prove TSBG's live customer routing.

The practical conclusion is narrow. TSBG appears to be a real Bulgarian hosting and colocation operator with detailed physical-infrastructure claims. A buyer should treat those claims as testable, not settled. Before placing critical workloads, it should obtain current route evidence, site-specific facility evidence, upstream and support boundaries, tested backup or migration evidence, and a written map of who restores service when rack, upstream, hardware-stock, support, billing, migration or provider-contract failure occurs.