Summary

  • Logosys Cloud's own network looking glass names Hyderabad DC1, Mumbai DC1 and Chennai DC1, but it does not identify the buildings, rack ownership, circuits, power topology or service inventory behind those labels.
  • APNIC assigns Logosys Cloud AS150636 and the portable block 103.89.46.0/23. On 15 July 2026, RIPEstat showed only 103.89.46.0/24 actively originated, with no visible IPv6 space. That route was fully visible to RIPE RIS peers and had a valid RPKI authorization.
  • PeeringDB lists one operational 1 Gbps port at DE-CIX Mumbai and one interconnection facility, Web Werks Mumbai 1. APNIC identifies AS133296 as Web Werks India Pvt. Ltd.; current BGP observations make that ASN the dominant adjacent network, but neither fact proves that every Logosys service uses one site or one carrier.
  • Product pages advertise up to 100 Gbps ports, four points of presence, five Indian exchanges, global streaming servers and colocation in India and the United States. Public evidence does not disclose installed fleet size, customer allocations, site-by-site capacity, reserved power, usable failover capacity or a tested multi-site recovery design.

The most revealing page is the smallest one

The Logosys Cloud page that says most about its infrastructure is not the dedicated-server catalogue with its large bandwidth numbers. It is a compact diagnostic page on a hostname beginning lg-hyderabad. Across the top, the Logosys looking glass presents three labels: Hyderabad DC1, Mumbai DC1 and Chennai DC1. It offers ping, traceroute and test-file functions. The page is a useful sign that the operator wants customers to inspect network performance, but its city labels are not a map of owned data centres. They do not name a landlord, a street address, a room, a cage, a router, a power feed or the service SKUs available in each city.

That distinction matters because the rest of the Logosys catalogue invites a much larger mental picture. The dedicated-server page says customers have access to four points of presence and five internet exchanges across India. It describes standard 1 Gbps ports, 10 Gbps for higher-performance servers and up to 100 Gbps for an ultra-high-bandwidth tier. The live-streaming CDN page says there are 20 streaming servers worldwide. The colocation page says centres are located in India and the United States. The company's about page describes a self-service cloud offering virtual machines, dedicated compute, GPUs, object storage, load balancing, firewalls, VPCs, DBaaS, reserved IPv4 and backup.

Each statement may describe a part of the service portfolio. None, on its own, tells a buyer where a particular virtual machine will run, which company owns the server, whether two advertised locations share a building or carrier, how much capacity is installed, or whether spare capacity remains usable during a failure. Public network evidence gives a firmer but smaller answer. It establishes one autonomous system, one currently routed IPv4 /24, one named exchange connection and one named facility in Mumbai.

The responsible reading is neither "the website is the network" nor "anything not visible in BGP does not exist." It is that product coverage, logical reach and physical resilience are separate propositions requiring separate proof.

A 2022 cloud company with an older broadcast lineage

The legal identity begins on 8 April 2022. In a customer-portal incorporation announcement, the business said that Logosys India was henceforth Logosys Cloud Private Limited and supplied the corporate identification number U72900TG2022PTC161383. The notice named Ashwin Kumar as founder and managing director and gave an address in Kothapet, Hyderabad. APNIC's registration for AS150636 uses the same company name and Hyderabad address, which connects the legal entity to the public network number more directly than a brand name alone could.

The history before 2022 is more complicated. Logosys Cloud says on its about page that it began in 2013 as a contractless computing provider. A separate company, Logosys Software Solutions Private Limited, is identified in Tofler's corporate-data profile as incorporated on 22 March 2013 under CIN U72200TG2013PTC086572; the profile lists Ashwin Kumar and Moti Singh Purohit as directors and gives the Kothapet, Hyderabad registered address. The software company's own site markets television playout products. The cloud company's current terms of service name Logosys Cloud Private Limited as the service provider, but the payments clause instructs customers paying by bank transfer, cheque or demand draft to make payment in favour of Logosys Software Solutions Private Limited. The records therefore show a common address, Ashwin Kumar's appearance in both companies' records and a payment instruction. They do not establish present shareholding, parent-subsidiary status, asset ownership or an intercompany service agreement.

This is not clerical trivia. A customer buying a server should know which company signs the order, issues the tax invoice, receives funds, owns or leases the hardware, employs the support staff and owes any service credit. The 2022 announcement says products, services, website and contact numbers remained the same after the name change, yet the continued appearance of the older software company as a payment recipient leaves the contractual boundary worth confirming in writing. The public record reviewed here does not disclose a consolidated group structure or audited financial statements for the cloud operation.

Logosys Cloud's current ownership beyond the named directors is therefore unknown from the evidence available.

The older broadcast lineage does, however, explain why this catalogue is not a generic copy of a commodity host. Logosys sells streaming bandwidth, remote playout servers, FTP services for news channels, playout software licences and managed distribution alongside VPS and web hosting. Its remote playout listing combines a 32-core, 256 GB server, SSDs, 10 TB of transfer and an Nvidia Quadro GPU with Logosys playout software. This is a coherent operational niche: a regional broadcaster can buy software, compute, streaming and support from one commercial counterparty. It also concentrates several failure modes in the same counterparty.

What the company actually sells

Logosys Cloud spans four related markets. First is shared and reseller hosting, where many customers share a server and depend on a control panel, web stack and support team. Second is virtual infrastructure, including KVM VPS products and an on-demand interface. Third is physical capacity, with dedicated servers and rack-unit or full-rack colocation. Fourth is video infrastructure, including live streaming, CDN distribution and remote playout.

The breadth is visible in the customer portal. Its cloud-hosting interface advertises project grouping, on-demand virtual machines, cloud-init deployment, browser terminal access, rebuilds and a REST interface. These are meaningful control-plane functions. They let a customer create and destroy compute without waiting for a technician, provided the underlying node, storage, network and licence inventory exists. The page does not disclose the number of hypervisor hosts, the overcommit policy, storage replication, placement rules or the regions available in the selector.

The VPS page lists KVM plans from two to four cores, 2 GB to 8 GB of RAM and 30 GB to 240 GB of disk, with monthly transfer allowances up to 3 TB. It also says the service uses Dell servers, offers DDoS protection and targets 99.9 per cent uptime. The public shopping cart, however, currently shows only a Starter VPS beginning at INR 1,550 a month and does not expose the same resource detail. The marketing page begins at INR 1,000. A buyer cannot tell from those pages alone whether these are different generations, locations, promotional prices or simply unsynchronised catalogues.

Dedicated hardware is similarly specific at the SKU level but opaque at fleet level. The main page lists Intel E3 and E5 configurations with 1 Gbps uplinks and transfer bundles. The current dedicated-server store entry offers 128 GB of RAM, two 480 GB SSDs, 10 TB at 1 Gbps and five IP addresses at INR 12,700 a month. Yet its title says "48 Cores" while the description says an E5-2680 v4 with 28 cores. That discrepancy is not evidence of unavailable capacity, but it is enough reason to require a final bill of materials rather than treating the card title as a technical specification.

The difference between a sellable configuration and an installed fleet is fundamental. A product card can be generated before equipment is racked, can remain visible after stock is exhausted, or can describe hardware sourced on order. Logosys's dedicated page itself marks one E5 configuration "Sold out" while other configurations remain selectable. No public inventory counter, serialised hardware list, rack count or delivery lead time establishes how many units are installed and powered. The usable dedicated capacity is unknown.

The map has three different kinds of place

Public references to Hyderabad, Mumbai and Chennai should not be placed on one map without labels explaining what each point means.

Hyderabad is the strongest identity location. It is the registered and contact address in the incorporation notice, APNIC records and company policies. The looking-glass hostname also uses Hyderabad, and the page labels Hyderabad DC1. But an office address in Kothapet is not proof that production servers sit in that building. The looking glass links only to a city-level map search, not to a named data-centre operator or exact facility. The public evidence does not establish whether Hyderabad DC1 is an owned room, a leased cage, wholesale space, a remote node or a label for services delivered through another operator.

Mumbai is the strongest interconnection location. PeeringDB's Logosys record lists AS150636 at Web Werks Mumbai 1 and on a 1 Gbps port at DE-CIX Mumbai. The facility record places Web Werks Mumbai 1 at Sigma IT Park in Rabale, Navi Mumbai, and identifies four exchanges available in the building. This is good evidence that Logosys has, or at least reported, an operational network presence there. PeeringDB is maintained by network entities rather than serving as an equipment audit, so it does not prove how many Logosys racks, servers or cross-connects are present.

Web Werks provides useful context around the building boundary. Its current India data-centre page describes Mumbai 1 as a purpose-built 2.3 MW facility with N+N redundancy. Those are facility-wide operator claims. They must not be allocated to Logosys. A tenant may occupy a fraction of a cabinet or several racks; it may buy one power path or two; it may connect to one carrier, an exchange fabric, or several networks. Nothing public states Logosys's contracted kilowatts, PDU arrangement, UPS path, generator coverage, cross-connect diversity or remote-hands terms inside the building.

Chennai is currently only a company-published city label in the material reviewed. No named Chennai facility appears in the Logosys PeeringDB record. No street address, landlord, exchange port, origin prefix or test-server address was published on the looking-glass page. That does not disprove an indirect service node, rented server or private interconnection in Chennai. It means the physical status, operator, service inventory and failure independence of "Chennai DC1" are unknown.

The company's own dedicated-server statement adds a fourth point of presence and five Indian exchanges without naming them. Its colocation copy adds an unspecified US presence. These are coverage claims, not route maps. A CDN partner, transit provider, reseller arrangement or rented machine can create service reach without giving Logosys an owned router or cage at every location. Conversely, a private link or unadvertised management network may not appear in public BGP data. Exact fibre routes between any Logosys locations are not public.

There is no evidence for physically diverse ducts, separate metro entrances or independent long-haul paths.

One /23 assigned, one /24 visible

Number-resource records provide the clearest hard boundary. APNIC's RDAP record for the autonomous system identifies AS150636 as LOGOSYSCL-AS-IN, active in India and registered in February 2023. APNIC's address record assigns Logosys Cloud the portable IPv4 range 103.89.46.0 through 103.89.47.255. That is a /23 containing 512 addresses before network, broadcast, infrastructure and reservation overhead. "Portable" means the address block is assigned to the holder rather than merely being a subnet of a provider's aggregate; it does not mean the company owns buildings or fibres.

At the observation time on 15 July 2026, RIPEstat's announced-prefix view returned only 103.89.46.0/24. Its routing-status view counted 256 announced IPv4 addresses, no IPv6 prefixes and complete visibility from the 326 IPv4 RIPE RIS peers in the measurement set. It recorded the route first seen on 26 July 2023. This is an operationally useful result: the active /24 was not a faint or local-only announcement at that moment.

The second half, 103.89.47.0/24, has an APNIC route object naming AS150636, and the holder has an RPKI authorization covering the /23 with a maximum length of /24. It was not present in the current announced-prefix result. A route object and a valid route-origin authorization are permissions and policy records; they are not evidence that a route is presently propagated, accepted worldwide or carrying customer traffic. The unannounced /24 could be reserved, staged, withdrawn, used privately or simply idle. Public evidence does not settle which.

The active route has a valid origin authorization. RIPEstat's RPKI validation finds a valid ROA for origin AS150636, covering 103.89.46.0/23 with maximum length /24. That reduces one class of route-origin mistake: networks performing route-origin validation can verify that this AS is authorised to originate this /24. RPKI does not validate the entire AS path, prove that packets reach a healthy server, or protect a service from power, switching, application or support failures.

IPv6 remains a conspicuous unknown in the commercial story. PeeringDB reports zero IPv6 prefixes for Logosys, and RIPEstat observed none announced. The DE-CIX listing does not publish an IPv6 address for the Logosys port. A provider can still deliver IPv6 through another network or to selected customers, but no owned IPv6 origin is visible. Buyers requiring native dual stack should request the assigned prefix, routing policy, reverse-DNS process and a test address rather than infer IPv6 from a general cloud label.

A peering port is not five independent exits

PeeringDB is precise about the one exchange connection it lists: an operational 1 Gbps port at DE-CIX Mumbai, with route-server participation. It also classifies the network as content, gives it an open peering policy, records mostly outbound traffic and places self-reported traffic in the 1-5 Gbps range. The entry was last updated in December 2023. These fields help other networks decide whether and where to interconnect. They are not a current utilisation graph, a contract or a capacity reservation.

A 1 Gbps exchange port has a maximum line rate; it does not cap the whole autonomous system if transit or private interconnections exist elsewhere. Likewise, a self-reported 1-5 Gbps traffic band can include traffic outside that exchange. There is no contradiction in principle, but there is no public measurement tying the traffic band to specific links. A buyer should not add "1 Gbps DE-CIX" to "up to 100 Gbps server port" and assume 101 Gbps of external capacity. Server access speed, aggregate fabric capacity, transit commit and internet-exchange port speed measure different segments.

The current path evidence is especially important. RIPEstat's neighbour view sees AS133296 as the dominant network directly before Logosys across hundreds of observation paths. APNIC's RDAP registration for that ASN names it WEBWERKS-AS-IN and describes Web Werks India Pvt. Ltd. RIPEstat's BGP state for the active /24 also exposes a small number of paths in which other networks appear directly before AS150636, including paths consistent with exchange or alternate connectivity. This supports a measured conclusion: Web Werks was the dominant visible path at the time, while some logical path plurality was observable.

It does not support the stronger phrase "physically redundant multi-homing." Two BGP neighbours can terminate on the same router, use the same cross-connect bundle, traverse the same building meet-me room or depend on the same utility feed. An exchange route server can expose hundreds of peers through one physical port. Several upstream AS paths can reconverge on one carrier beyond the customer edge. The reverse is also possible: private circuits can be physically diverse while public collectors select only one best path.

To establish physical resilience, Logosys would need to disclose the edge routers, port locations, carriers, cross-connects, building entrances and failover tests relevant to the purchased service.

The company's statement of five internet exchanges may refer to networks available to customers, exchange fabrics used through another party, or connections not listed in PeeringDB. The public record does not name the other four. Until names, ports and operational status are supplied, the only independently traceable exchange attachment in this review is DE-CIX Mumbai. That is useful connectivity, but one exchange port is not a substitute for transit and does not by itself provide a route when the building, router or access circuit fails.

Who owns the rack, server and power path?

Logosys uses ownership language carefully in some places and loosely in others. The streaming page says "Fully Own Network," while the colocation page explains that customers can place their equipment in an IDC rack and that a service provider supplies power and network. The dedicated page promises single-tenant physical servers but does not say whether Logosys owns, leases or sources each server. PeeringDB names Web Werks Mumbai 1 as the interconnection facility, not as a Logosys-owned building.

There are therefore at least four possible ownership layers for a purchased service. Logosys Cloud can be the contractual service provider. A data-centre company can own or operate the building, UPS, generators and cooling. A carrier or exchange can provide external connectivity. Logosys, the facility operator, a finance lessor or another supplier can own the server. The customer controls its guest operating system or colocated hardware but may not control the hypervisor, switch, storage array or remote-hands queue. Public pages do not resolve every layer for every SKU.

The Logosys colocation offer is concrete about retail bundles. It advertises 1U at 200 W, 2U at 300 W, 4U at 400 W and 8U at 600 W, each with 100 GB of bandwidth. It also lists a quarter rack at 1 kW, a half rack at 1.5 kW and a full 42U rack at 3 kW. These are quoted product limits, not proof of live spare inventory. They also invite technical questions. The page says "Power Supply: Yes" but does not specify A and B feeds, voltage, breaker size, metering method, sustained-versus-peak allowance or treatment of power-factor overhead. The full-rack density of 3 kW is plausible for many traditional hosting workloads but can constrain dense GPU or modern dual-socket deployments.

The same colocation page calls the offer a "Tier 4 datacenter" near its top and later describes "Tier 3 data centers." It does not name a certification body, facility identifier or certificate. Tier terminology can describe design ambition, a provider's shorthand or a formal third-party certification; those are not interchangeable. The only safe conclusion is that the page makes both claims. A buyer should request the specific facility, certificate, scope and expiry rather than transfer a generic tier label to a Logosys rack.

Facility capacity is also easy to misread. Web Werks publishes 2.3 MW for Mumbai 1. That is the facility operator's figure for the site, not Logosys's installed or reserved capacity. It says nothing about the fraction available to a Logosys customer after existing load, cooling limits, contractual reservations and maintenance conditions. The article found no disclosed Logosys rack count, power commit, generator runtime, fuel contract, cooling design, spare-parts stock or server inventory. Installed, powered, operational, sold and failure-usable capacity are all unknown at company level.

Streaming changes the dependency chain

Logosys's most distinctive workload is broadcast streaming. Its live-CDN page offers plans from 1 TB and ten connections to 5 TB and 1,000 connections, with one channel per plan. It claims less than five seconds of latency for HLS and DASH, support for Wowza, and 20 streaming servers worldwide. The about page says the company has served more than 100 television channels. These are first-party commercial statements. No public node list, provider list, traffic report or customer-reference evidence establishes the present location and status of all 20 servers or the active customer count.

For a broadcaster, "20 servers" is not a capacity number without workload assumptions. A server receiving one high-bitrate contribution feed and repackaging it can have very different CPU, GPU, storage and egress limits from an edge serving cached segments. Ten connections at one bitrate are not equivalent to ten at another. A monthly transfer quota says little about peak concurrency. A CDN can use owned servers, rented bare metal, virtual machines or a third-party distribution partner. The Logosys page does not break down origin, transcode, packager and edge roles by location.

Failure impact is also asymmetric. If an edge node fails and traffic is steered elsewhere, viewers may see a brief quality change. If the sole live origin, encoder or playout server fails, every edge can remain healthy while the channel goes dark. If the customer control panel is unavailable, an already-running stream may continue but operators may be unable to restart or redirect it. If an upstream path fails, local servers may remain powered but unreachable. If a graphics or playout licence fails, network and compute capacity do not restore the programme output.

"CDN redundancy" needs a design for each role, not just a count of nodes.

The remote-planning question is equally important. A customer should ask whether its playout server and streaming origin share a host, rack, facility or power domain; whether a secondary instance is warm, cold or merely restorable; how current the media copy is; and who has authority to trigger failover. The public offer does not give a recovery-point objective or recovery-time objective. It says support is available continuously, but staffing levels, escalation targets and remote-hands response times are not published.

Capacity claims are not capacity states

The word "capacity" covers at least seven states in this market. Design capacity is what a system could support if built as planned. Installed capacity is hardware in a rack. Powered capacity has an energised circuit and cooling allocation. Lit capacity has an active network path. Operational capacity passes health checks. Sold capacity is committed to customers. Usable capacity is what remains under the failure condition being considered. Logosys's public pages mostly describe product maxima and catalogue configurations, not those states.

The 100 Gbps figure on the dedicated page is a port-speed promise for an ultra-high-bandwidth class. There is no named server, facility, switch model, transit commit or current price attached to it. The main purchasable dedicated listing shows 1 Gbps. The PeeringDB exchange port is 1 Gbps. None of these numbers proves or disproves the others because they can refer to different ports and sites. But a 100 Gbps access port cannot deliver 100 Gbps to the public internet unless the rest of the path, traffic policy and commercial commit support it.

The IPv4 inventory illustrates another boundary. A /23 contains 512 addresses, and only one /24 was globally announced at the observation time. The dedicated listing includes five IP addresses per server. That does not mean Logosys can sell only about 51 such servers: addresses can come from upstreams, be reused through private networking, or be allocated differently across products. It does mean that public, portable address space is finite and partly unannounced.

Customers needing large allocations should ask whether addresses are Logosys-held or provider-assigned, whether they can be routed after migration, and how abuse history and reverse DNS are managed.

No public utilisation data shows CPU occupancy, RAM allocation, storage consumption, oversubscription, port utilisation, rack power draw or sold reservations. PeeringDB's 1-5 Gbps band is self-reported and old enough to require reconfirmation. The product store's "Sold out" marker on one configuration shows that stock state can matter, but it does not reveal whether the constraint was processors, drives, chassis, rack power or a retired SKU. Capacity planning for a real deployment therefore has to begin with a dated quotation tied to a site and delivery date.

The 99.9 per cent promise has procedural edges

Logosys publishes a detailed service-level agreement, which is better than leaving uptime entirely to sales copy. It sets a 99.9 per cent monthly threshold. In a 30-day month, 0.1 per cent is about 43 minutes and 12 seconds. Availability between 99.9 and 99 per cent earns one day of service extension; lower bands earn two or three days, with a formula below 97 per cent. Logosys may instead provide an equivalent credit or discount at its discretion.

The remedy is narrower than the headline. A customer must report downtime by email within 24 hours of discovering it. The clock begins when the email is sent, not necessarily when the outage began. A rebate request must then be submitted with evidence by a short deadline after the billing period. Incidents are not aggregated for rebate calculations. Planned work, emergency maintenance and a wide range of outside events can be excluded. The exceptions include performance of third-party exchanges, DNS beyond Logosys's control, customer access circuits, networks not owned by Logosys and some third-party software or services.

Those exclusions map directly onto the infrastructure boundaries. The only named exchange, facility operator and dominant adjacent network are separate organisations. A customer may experience a complete application outage caused by a failure that the service contract excludes from its downtime calculation. That does not make the SLA meaningless; it makes architecture more important than compensation. A one-day extension on an inexpensive VPS is not equivalent to the business loss from a silent television channel or unavailable commerce site.

The SLA also says the customer is responsible for appropriate backup and recovery plans, including periodic testing, and that Logosys does not take responsibility for customer data integrity and security. The terms cap cumulative liability at one month's fees in the month preceding the event and exclude consequential losses. Customers who require stronger protection need a negotiated agreement defining service-specific availability, data durability, backup ownership, incident communications, recovery objectives and the precise components included in the calculation.

Local cloud does not automatically mean known data locality

Logosys presents itself as an Indian cloud provider and publishes Indian prices, an Indian corporate identity and an India-registered autonomous system. Those are meaningful locality signals. They do not by themselves establish where each category of customer data resides.

The colocation page says centres exist in India and the United States. The live-CDN page says servers are worldwide. The customer portal is a separate service surface from the marketing site. Backups, monitoring records, support attachments, DNS data and streaming edges can occupy different locations from the primary compute node. A customer buying "India" hosting should require the service order to state the facility and country for primary data, replicas, backups, snapshots, logs and support access.

The company's privacy policy identifies Logosys Cloud Private Limited and explains the categories of customer, billing and usage information it collects. It does not function as a site-by-site data-residency schedule for hosted workloads. The terms place responsibility for customer data and legal compliance largely on the customer. For a regulated or location-sensitive deployment, brand nationality and the country code on an IP registration are limited public evidence controls.

Migration also tests locality claims. A VPS image may depend on a proprietary control panel, a manually assigned address, a local backup product or a licence that cannot move with the disk. A streaming service may depend on Logosys software, Wowza configuration and a CDN arrangement. The refund policy describes self-service and manually provisioned deprovisioning, continued billing until deprovisioning is confirmed, and special treatment for committed nodes and software licences. The cancellation policy requires at least seven days' notice before renewal. Neither page promises a standard export format, a data-transfer window after termination or assistance moving an active service to another provider.

How failures would propagate

The most useful resilience test is to start with a concrete failure and follow its effects.

A rack or facility power event. If a service runs only in Web Werks Mumbai 1, a rack PDU, room, UPS path or building event can take compute and network edge equipment down together. Facility N+N marketing does not prove that a particular tenant purchased dual feeds or deployed dual-corded equipment. Recovery depends on spare hardware, remote hands, backup location and whether another site has enough reserved capacity. None is quantified publicly for Logosys.

Loss of the dominant upstream path. Current global routes predominantly show AS133296 immediately before Logosys. If that adjacency fails, reachability depends on the operational status and propagation of alternate sessions. A DE-CIX route-server port may provide direct paths to participating peers, but it is not general transit to every destination. The number of logical neighbours does not disclose whether the links share a router, cross-connect or building entrance.

Failure of the exchange port or edge router. The listed DE-CIX port is 1 Gbps in one Mumbai facility. If exchange traffic and transit terminate on the same edge chassis, an edge-router failure can remove both even when contracts name multiple networks. If they use separate chassis and paths, resilience can be much stronger. The public record does not reveal this topology.

Hypervisor, storage or inventory failure. The web-hosting page claims automatic movement to another server when hardware trouble is detected. It does not describe shared storage, replication lag, fencing, failure domains or whether every VPS product uses that design. Dedicated servers normally require component repair or a replacement chassis unless the customer has a standby. A listed server with RAID 1 can tolerate a drive failure but not every controller, motherboard, power or operator error.

Control-plane failure. The customer portal handles ordering, billing, tickets and some server actions. A control-plane outage may not stop a running workload, yet it can block rebuilds, console access, scaling and cancellation. Resilient compute without resilient access and escalation can still lengthen an incident. Logosys publishes phone, email and ticket channels, but no independent support response statistics.

Streaming-origin failure. Multiple CDN edges do not help when the only encoder, playout process or origin has stopped producing a valid stream. Recovery requires a second input, current content, licences, credentials and tested traffic switching. The public "20 server" claim does not identify these roles.

DNS or certificate failure. Logosys promotes redundant DNS, but its public pages do not name authoritative providers by service or explain separation of control and failure domains. DNS is explicitly excluded from the SLA when outside Logosys's direct control. Customers should test authoritative diversity, registrar security, certificate renewal and access to credentials independently of the hosting account.

Support and billing failure. Small-provider economics often rely on a concentrated technical team. Logosys advertises continuous support, but no headcount, on-call roster or escalation timing is public. The continued reference to a separate software company in payment instructions adds another operational handoff to clarify. During an incident, the customer needs one accountable party empowered to act across facility, carrier, hardware and software suppliers.

The economics are attractive because the boundaries sit with the buyer

Logosys's list prices can be compelling. INR 1,550 buys entry-level VPS access in the current store. INR 12,700 buys a dedicated configuration with 128 GB of RAM, SSDs, 10 TB at 1 Gbps and five addresses. A 1U colocation offer begins at INR 4,500 a month, while a full rack is listed at INR 50,000 with 3 kW. Streaming starts at INR 1,500 for one channel and 1 TB of monthly transfer. These prices give smaller organisations a route into managed infrastructure without the minimum commitments associated with a hyperscale or wholesale contract.

The economic trade is that much of the integration risk remains implicit. The buyer must price backups, managed support, software licences, extra addresses, replacement parts, bandwidth bursts, traffic overages, remote hands, second sites and migration. A low monthly server price is not the cost of a recoverable service. For a broadcaster, the meaningful denominator may be cost per protected channel-hour, not cost per core. For a business application, it may be cost per recoverable transaction or per tested restoration.

The contract reinforces this allocation. Rebates are service extensions or credits, not compensation for consequential loss. Customers must document outages quickly and maintain their own recovery arrangements. Committed nodes and used software licences have limited refund options. This can be a rational bargain for non-critical workloads, dev/test machines, regional media operations with their own backup path, or customers that value responsive local support. It is a weaker bargain when a customer assumes that a cloud label includes multi-region durability by default.

What would turn the claims into infrastructure evidence

Logosys could make its public offer much easier to evaluate without disclosing sensitive network detail. The first improvement would be a dated location matrix. Each city should name the facility operator, service classes available, whether capacity is owned or leased, and whether the site is accepting new orders. A map should distinguish office, cloud region, CDN edge, exchange port and colocation room. Lines between cities should appear only where a physical route and operator are known; otherwise the map should show service reach rather than implied fibre.

The second improvement would be a network facts page. It could list active prefixes, IPv6 status, transit providers, exchanges, port capacities, looking-glass addresses and RPKI coverage, with a last-updated date. It should state whether multiple sessions are on separate routers and whether they enter the facility through diverse paths. The current PeeringDB record is useful but was last materially updated in 2023 and names only one exchange and one facility.

The third would be a capacity vocabulary. Logosys need not publish customer-sensitive utilisation, but it could separate installed servers from orderable configurations, port line rate from committed internet bandwidth, building power from tenant power, and normal capacity from failure-usable spare capacity. For colocation, a quotation should state feed count, breaker rating, voltage, included energy, metering, cross-connects and remote-hands terms. For cloud, it should state host generation, storage durability, overcommit policy and live-migration coverage.

The fourth would be service-specific recovery evidence. The company could publish whether VPS instances are restartable on another node, whether backups stay in the same facility, how streaming origin and edge failover work, and what customers must supply. A status history should identify incidents by service and region while protecting customer details. A successful failover exercise with date, scope and measured recovery time would say more than a generic redundancy icon.

For buyers evaluating Logosys today, the diligence list is straightforward:

  1. Put the exact legal contracting and invoicing entity on the order form, including the role of Logosys Software Solutions Private Limited.
  2. Name the facility and country for compute, primary storage, replicas, backups, logs and support access.
  3. Identify who owns the server, rack, power feed, cross-connect and IP space used by the purchased service.
  4. Obtain active transit and exchange details, then ask which links are physically independent and test failover.
  5. Convert every bandwidth claim into a port, commit, burst policy, transfer allowance and congestion responsibility.
  6. Convert every capacity claim into installed, powered, operational, available-for-order and failure-usable quantities.
  7. Define backup ownership, export format, restoration test, recovery point, recovery time and exit assistance.
  8. Reconcile the marketing configuration, shopping-cart configuration and final bill of materials before payment.
  9. Negotiate incident notification and service credits around the actual business impact rather than the generic 99.9 per cent page.
  10. Require evidence for Hyderabad, Chennai, the fourth point of presence, four additional exchanges and any US location if the proposed design relies on them.

The bottom line

Logosys Cloud is not merely a web host with a cloud word attached. It has a registered Indian network, valid route-origin protection, a visible Mumbai interconnection, self-service controls, physical-server offers and a credible specialism in television playout and streaming. For regional broadcasters and smaller Indian customers, that combination can be commercially useful.

But the public infrastructure story is not yet as broad as the product story. The three-city looking glass does not disclose three independent facilities. The assigned /23 does not mean both /24s are routed. A 1 Gbps exchange port does not prove five exchange connections or a 100 Gbps internet path. A 2.3 MW facility does not give Logosys 2.3 MW. Twenty streaming servers do not establish twenty independent origins. A 99.9 per cent SLA does not guarantee recovery from facility, transit, control-plane or data-loss events.

The evidence supports a bounded conclusion. Logosys Cloud controls AS150636, actively originates one well-visible, RPKI-valid /24, and reports an operational presence at Web Werks Mumbai 1 and DE-CIX Mumbai. Hyderabad is firmly established as its corporate and operational base, while Chennai and the rest of the advertised footprint remain insufficiently specified. Everything beyond that boundary should be purchased through a site-specific, capacity-specific and recovery-specific order, not inferred from the catalogue. The next meaningful proof will be not a larger bandwidth number, but a dated statement of where the service runs, what remains available when it fails, and who is accountable for putting it back.