White Sky Hosting sells hosted capacity that still depends on racks, transit and repair windows

Summary

• White Sky Hosting has a current public service surface: the main website markets game and dedicated server hosting, the VPS page lists concrete CPU, memory, storage and price tiers, the dedicated page sells bare-metal capacity, and the billing store exposes in-stock dedicated-server ordering.
• The network layer is also live. ARIN registers AS46177, 23.136.228.0/24 and 2602:f696::/40 to White Sky Hosting; RIPE records 31.56.65.0/24 to the same organization; and RIPEstat shows AS46177 announcing two IPv4 prefixes and one IPv6 prefix on 15 July 2026.
• The strongest infrastructure clue is the public knowledge base. It describes Tenantos billing/provisioning integration, Proxmox VM nodes, Juniper switch automation, port-security bindings, virtual MACs, VLAN allowlists and switch-backup procedures. That is more operational detail than a generic hosting brochure.
• The evidence grade is Medium. White Sky is visibly operating and routeable, but its public record still does not identify the facility address, power feeds, rack count, upstream contracts, DDoS capacity proof, restore-test history, spare hardware pool, staffing depth or independent disaster-recovery site for customer workloads.

The useful story is a small host with visible moving parts

White Sky Hosting is not just a directory name. The BTW directory page links the company to AS46177, and ARIN's AS46177 RDAP record names the resource WHITE-SKY-HOSTING, associates it with White Sky Hosting, and includes the public website in the registration comments. ARIN's WTL-119 organization record places the organization in Mount Vernon, Washington and links it to AS46177, one direct IPv4 allocation and one direct IPv6 allocation.

That registry layer is supported by a working commercial layer. The White Sky Hosting homepage describes game and dedicated server hosting on a reliable network with enterprise-grade hardware and support. It links to hosting, game, support, billing, game panel, dedicated panel, knowledge-base and status surfaces. The site is not a static placeholder. It is a current retail front end with products, cart links and active subdomains.

The domain infrastructure also points back to the provider's own routed space. Local DNS observations resolved whiteskyhosting.com and billing.whiteskyhosting.com to 31.56.65.55, docs.whiteskyhosting.com to 31.56.65.35, panel.whiteskyhosting.com to 31.56.65.80, dedicated.whiteskyhosting.com to 31.56.65.75, and the two authoritative nameservers to 31.56.65.50 and 31.56.65.51. RIPE's 31.56.65.0/24 RDAP record identifies White Sky Hosting as the end-user organization for that prefix. That makes the site and control-plane hostnames more meaningful than a CDN-only marketing presence.

The first conclusion is therefore positive but bounded: White Sky Hosting is a current small hosting operator with live web, billing, documentation, status and routing evidence. It is not merely a forgotten registry row. The second conclusion is more cautious: the public evidence still does not make White Sky a fully audited infrastructure provider. It shows an operator; it does not show every physical and contractual dependency behind that operator.

That distinction matters because the provider sells services that customers may treat as infrastructure. A Minecraft server, a VPS, a dedicated Ryzen machine, a website package or a control-panel account can become a real business dependency. The fact that ordering is simple does not make the service immaterial. It means physical infrastructure has been packaged into a retail unit.

The catalogue is specific enough to reveal the economics

White Sky's VPS hosting page is unusually concrete. It lists small Xeon E5-2697v2 plans with DDR3 ECC memory and HDD or SSD storage, plus higher-end Ryzen 5900x and Ryzen 7900x plans with DDR4 or DDR5 memory and NVMe storage. Published prices range from small three-dollar instances to larger fifty-eight-dollar monthly plans. The plans advertise unlimited bandwidth, which is attractive to customers but should be read as a commercial policy rather than a physics claim.

The hardware mix says something about the business model. Older Xeon nodes can support low-cost entry plans. Newer Ryzen nodes support performance-sensitive workloads. HDD, SSD and NVMe tiers let the provider segment budget, storage-heavy and latency-sensitive customers. This is a typical small-hosting optimization: use different generations of hardware to match different price points rather than pretend every workload receives the same modern platform.

The dedicated hosting page describes bare-metal servers and repeats several cross-service claims: Arbor DDoS protection, 99.95 percent uptime, expert support, hardware monitoring, offsite backups and advanced connectivity. The billing cart dedicated-server category is more specific, showing a Ryzen 5 5600x plan marked in stock with six cores, twelve threads, 64 GB DDR4, two 500 GB NVMe drives, 1 Gbps unmetered uplink, full root, IPMI and custom ISO support. It also lists one IPv4 and one IPv6 address, DDoS protection, KVM access and instant setup.

The game-server side broadens the customer base. The games page markets Minecraft, Valheim and Satisfactory servers starting at low monthly prices. The Minecraft page goes much further, claiming AMD Ryzen 9 nodes, NVMe Gen4 storage, hardware in a Tier-3 facility the company says it owns and operates, BGP-multihoming across multiple Tier-1 transit providers, 100 Gbps DDoS protection at the rack, and deployment in under ninety seconds. Those are strong claims. They are also exactly the kind of claims that need independent confirmation before a customer treats them as redundancy proof.

The billing cart Minecraft category shows the commercial reality behind the marketing page: small plans with RAM and storage tiers, add-to-cart actions, product descriptions and upgrade logic. The Valheim cart category shows at least one simple Valheim product. This matters because it proves the site is connected to a billing flow, not just a landing page. It still does not prove the amount of unsold inventory, the real deployment time, or how many customers a node can absorb during failures.

The catalogue therefore supports a medium evidence grade. White Sky is not a pure reseller shell in public view; it has products, a cart, panels and documentation. But usable capacity is still not equal to advertised plans. Usable capacity is what remains when a host node fails, an upstream drops, a switch port is misconfigured, a DDoS attack arrives, a customer needs restore, or a migration has to occur before a renewal deadline.

The routing layer is current, but small enough to audit closely

AS46177 is visible in current public routing data. RIPEstat's AS overview for AS46177 reported WHITE-SKY-HOSTING as announced on 15 July 2026. The announced-prefixes endpoint showed three prefixes for the two-week window ending that day: 31.56.65.0/24, 23.136.228.0/24 and 2602:f696::/40. The routing-status endpoint reported two visible IPv4 prefixes, one visible IPv6 prefix, full RIS peer visibility and four observed neighbours.

That is a strong current route signal. It says White Sky's AS is not merely registered; it is visible from public collectors. It also says the visible footprint is compact. Two /24 IPv4 routes and one /40 IPv6 route can support a real small host, but they do not imply hyperscale capacity. They should be treated as a focused platform: enough for current operations, not proof of endless growth or instant failover.

The neighbour data provides a first dependency map. RIPEstat's AS46177 neighbour response listed observed neighbours including AS27563, AS32505, AS197924 and AS401111. Public route paths sampled through RIPEstat also showed traffic reaching AS46177 through upstream chains involving AS32505 and AS27563. That supports the idea of more than one visible route path. It does not prove that every rack, every service and every prefix can fail over cleanly at full load.

This is where small-network diligence becomes practical rather than abstract. A customer does not need White Sky to publish every commercial contract to understand the risk. It needs to know whether the upstream mix is diverse enough for the workload, whether each prefix is advertised from the same edge, whether route filters are tested before changes, whether IPv6 is monitored as seriously as IPv4, and whether support can distinguish a server problem from a routing problem quickly. The public routing record makes those questions specific.

It narrows the conversation from "do you have a network" to "which parts of the network are independent when one path is unhealthy."

The prefix registrations divide into two categories. ARIN registers 23.136.228.0/24 and 2602:f696::/40 directly to White Sky Hosting. RIPE records 31.56.65.0/24 as assigned to White Sky Hosting through a RIPE database entity, with an end-user organization remark and a geofeed link. That combination gives the provider address resources in both ARIN and RIPE contexts.

The routing layer also has a disclosure gap. PeeringDB's AS46177 network API record names White Sky Hosting, lists the website, describes the network as NSP / Network Services, reports traffic in the 1-5 Gbps band, and gives a North America scope. But PeeringDB's netfac API query returned no facility rows, and its netixlan API query returned no exchange LAN rows. PeeringDB facility disclosure is voluntary, so this is not a disproof of infrastructure. It is a missing public proof of facility and exchange presence.

For customers, the route layer is good enough to justify serious evaluation. It is not good enough to skip the questions. Which upstreams carry each prefix today? Are they physically diverse? Are they on separate routers and cross-connects? Is IPv6 carried with the same operational care as IPv4? What happens if 31.56.65.0/24 has trouble, given that many public hostnames observed during research point into that prefix?

The public knowledge base exposes the operational machinery

White Sky's most valuable public evidence is not the marketing language. It is the knowledge-base infrastructure section. That page describes an infrastructure platform connected to Tenantos billing/provisioning, Proxmox VM nodes and Juniper switch automation. It says IP assignment or removal events can trigger switch configuration changes, and it describes an admin panel for switches, virtual MACs, Proxmox, VLAN allowlists, backups and settings.

The port-security page gives more detail. It describes Tenantos assignment events, API calls, switch-port updates and secure-access-port bindings. Dedicated servers and VM nodes are treated differently: dedicated servers have their own switch ports, while VM nodes aggregate MAC, IP and VLAN bindings from VMs on a Proxmox node. This is operationally specific. It is hard to mistake for generic web-hosting filler.

The switch-management page describes automatic backups before switch changes, scheduled backups, manual backups, retention limits and restore procedures. It also notes that restoring a backup performs a full configuration override on the switch. That is exactly the kind of detail that reveals real risk. Switch automation helps prevent manual drift, but a bad push or mistaken restore can affect many customers.

The virtual-MAC page explains why multiple IPs on a dedicated server may need separate virtual MAC addresses in Juniper secure-access-port configuration. The VMAC usage guide describes generating, revoking, batching and migrating virtual MAC bindings. This matters for recoverability. A customer with additional IPs does not merely need the server to boot; it needs the switch to accept the correct MAC/IP/VLAN state.

These documents raise confidence because they show that White Sky is thinking in terms of switches, Proxmox, provisioning events, VLANs and backups. They also increase the diligence burden because they expose specific failure modes. If a Tenantos event fails, an IP assignment may not reach the switch. If Proxmox guest telemetry is wrong, VM bindings may be incomplete. If a VLAN allowlist is misconfigured, legitimate bindings may be skipped. If a switch backup restore is broad, unrelated ports may be affected. If a VMAC migration is mishandled, a customer can lose reachability even when the server itself is healthy.

This is the difference between a glossy reliability claim and a real infrastructure surface. White Sky's documentation gives customers enough vocabulary to ask better questions. It does not provide a full public audit of how often the automation is tested, how changes are approved, how rollback is validated, or whether the management systems are independent of the customer-facing network.

The owned-facility claim is important and unverified in public

The Minecraft page contains the strongest physical claim: hardware in a Tier-3 facility the company says it owns and operates, not leased from colocation and not resold from an upstream. It also says the provider controls racks and switches. If true, that would be a meaningful differentiator. Many small hosting companies rent space in third-party facilities and rely heavily on remote hands. Facility ownership or direct operation can reduce some dependencies and increase accountability.

But the public record reviewed here does not identify the facility address, certification body, power topology, generator arrangement, cooling design, rack count, fire-suppression system, security model or maintenance history. ARIN places the organization at a Mount Vernon, Washington address. The service pages speak broadly about reliable infrastructure. PeeringDB does not list a public facility. The status page lists services and hostnames, not a facility. The knowledge base shows switch and provisioning operations, not building ownership documents.

The right treatment is cautious. The owned-facility claim can be reported as a company claim and used as a diligence target. It should not be treated as independently proven in public sources. A customer placing critical workloads should ask for a facility summary under non-disclosure if necessary: location, power feeds, UPS and generator design, rack density, upstream entry points, maintenance windows, physical security, remote access and insurance or compliance evidence.

The same applies to the 100 Gbps DDoS and Tier-1 transit language on the Minecraft page and the Arbor by NETSCOUT wording in the billing cart. DDoS protection can be real and valuable, but customers need to know where it is applied, whether it covers every product, whether mitigation affects latency, whether game traffic is filtered differently from web traffic, whether IPv6 is protected, and what happens when an attack exceeds the service level. A number on a product page is not the same as a tested incident report.

White Sky's public route visibility makes these questions answerable in principle. Customers can test traceroutes, observe origin AS, monitor paths and compare claims to packet behaviour. But facility and DDoS claims still need contractual or operational proof. Public route collectors do not show power redundancy, staff presence or scrubber capacity.

Control-plane concentration is a real watchpoint

Several White Sky hostnames observed during research resolve into 31.56.65.0/24. The main website, billing panel and cPanel hostname resolved to 31.56.65.55. The docs host resolved to 31.56.65.35. The game panel resolved to 31.56.65.80. The dedicated panel resolved to 31.56.65.75. The authoritative nameservers resolved to 31.56.65.50 and 31.56.65.51. The status page, by contrast, resolved to 158.69.154.132, outside the observed AS46177 prefix.

This is mostly positive. It shows the provider's own infrastructure is active in the prefix that RIPE associates with White Sky Hosting. It also creates a concentration question. If 31.56.65.0/24 or the rack supporting those hostnames has trouble, the website, billing, docs, panels and authoritative DNS may share a failure domain. The externally placed status page helps, but customers still need to know whether it remains useful when the customer panel, support desk or nameservers are impaired.

Authoritative DNS is especially important. If ns1 and ns2 sit in the same /24, they may not be fully independent even if they are separate hostnames. Customers using White Sky's DNS for production should ask whether there is additional anycast or off-network DNS behind the names, whether the two servers sit on separate machines and power paths, and whether zone export is available.

The support path also needs inspection. The billing portal is a WHMCS-style customer area, the ticket submission page allowed public support-request creation with a captcha, and the server-status route redirected unauthenticated users to login. That is a normal commercial pattern. It means unauthenticated outsiders can see some support surface but cannot audit the detailed network-status panel.

The public status page is more useful. It reported all systems operational, 99.890 percent average uptime over ninety days, and separate status blocks for the main website, billing panel, game panel, dedicated panel, status page, cPanel, a TenantOS host, a stats collector and authoritative DNS. The summary JSON reported an operational state across eighteen components at the time of research. The status page also stated that it was showing sample data with live checks connecting automatically, which should temper how much weight customers place on the ninety-day chart.

The result is a pragmatic view. White Sky has a visible control plane. Some of it appears to live in White Sky's own routed prefix. Some of it, including status, appears external. That is better than no control plane. It still leaves questions about whether billing, support, DNS and panels remain independently reachable during a routing, power or switch event.

The split also shapes the migration path. If a customer's server is unreachable but the status site remains reachable, the customer can still learn that an incident exists. If the status site is reachable but the billing portal, DNS and panels are all impaired, the customer may still lack the tools needed to export data, change zones or open an authenticated ticket. A mature host solves that by documenting out-of-band support channels, emergency DNS options, and the minimum services that remain online when the primary hosting prefix is degraded.

White Sky's public record shows the ingredients for such a path, but not the finished runbook.

Redundancy proof would connect those ingredients into a tested sequence. For example, a useful public incident note would say which component failed, which route or rack was affected, how customers were notified, whether support stayed reachable, whether DNS changes were needed, and how long restoration took. A useful private customer brief would go further and map the control plane to separate power, switch and upstream dependencies. Without that evidence, the safer reading is that redundancy exists in parts, not as a fully documented customer recovery promise.

Support and terms shift some risk back to the customer

White Sky's terms of use define shared hosting and dedicated hosting, state that the company aims to deliver uninterrupted service, and also state that services are not guaranteed to be always available or free from interruptions. That balance is normal. Providers can commit to reasonable operation while preserving exclusions for maintenance, abuse, payment and events outside their control.

The terms also place responsibility on users for account credentials, lawful use and content. That matters operationally because account compromise, abusive traffic, malware, spam or unpaid invoices can produce downtime just as surely as a power event. A customer running a game community, VPS, website or dedicated server should treat account security, contact hygiene and abuse response as part of availability engineering.

The privacy policy says White Sky may collect name, email address, phone number, billing information, usage data, IP address, browser type, operating system, pages visited and visit timing, and may share information with service providers or under legal requirements. That is not unusual, but it matters for data locality and customer compliance. A workload may run on White Sky hardware, while billing, analytics, email, support or other service-provider data moves elsewhere.

The public documentation does not provide a full data-processing map. It does not identify where backups are stored, where support data is processed, which subprocessors are used, whether game-panel data leaves the primary environment, or how long logs remain. The site markets offsite backups and protected data, but customers with regulated or sensitive workloads need a written statement that separates primary data, backup data, billing data, support tickets, logs and analytics.

Support is present but not fully measured. The site repeatedly offers expert support, the billing portal exposes ticket creation, the site links Discord, and the status page separates components. Public sources do not show current staffing hours, escalation targets, after-hours engineering authority, incident communications policy or refund mechanics after SLA misses. Customers should ask before deploying revenue-facing workloads.

The key point is that White Sky's retail friendliness does not remove customer responsibility. If a customer buys a low-cost game server or VPS and stores the only copy of a world, database or website on that service, recovery depends on more than the provider. It depends on backups, credentials, DNS control, export rights and the customer's own restore practice.

Installed capacity and usable capacity can diverge during stress

White Sky's product pages show installed or sellable units: RAM, vCPU, disk, CPUs, prices, ports and game plans. The billing cart shows at least one in-stock dedicated-server plan. The status page shows monitored components. The route table shows reachable prefixes. Those are important installed-capacity signals.

Usable capacity is what remains during stress. If a Ryzen node fails, can White Sky move game servers to another node without breaking IP/MAC/VLAN bindings? If a Proxmox host loses storage, are backups local, offsite or both? If a Juniper switch commit fails, is rollback automatic, manual or dependent on staff access? If a DDoS event hits a Minecraft node, does mitigation protect the panel, billing and DNS as well as the game port? If 31.56.65.0/24 has a routing issue, can customer support and nameservers still function?

The knowledge base helps by showing that some of these problems are recognized. Switch backups exist. VMAC lifecycle exists. Port-security automation exists. VLAN allowlists exist. That is good. It also means a customer should ask for the controls around those controls. Who approves a switch restore? Who can override a VLAN allowlist? How are automated events tested before broad deployment? Are backups checked, or merely stored? Are Proxmox and Tenantos monitored independently?

There is a second capacity distinction: installed address space is not the same as deployable service space. An IPv4 /24 can look generous on a registry page, but infrastructure addresses, router interfaces, panels, nameservers, customer assignments, quarantine ranges, reverse-DNS delegation, spare pools and reputation management all consume pieces of it. A dedicated-server plan that includes one IPv4 address is simple to sell; a customer that later needs more addresses, clean mail reputation, separate management access and emergency renumbering can reveal whether the provider has enough slack.

IPv6 makes addressing easier, but it does not remove the IPv4 pressure that many game, web and legacy customers still feel.

The direct IPv4 and IPv6 allocations also have capacity implications. 23.136.228.0/24 gives 256 IPv4 addresses before infrastructure reservations; 2602:f696::/40 gives a substantial IPv6 pool. The RIPE-assigned 31.56.65.0/24 appears to carry much of the visible control surface. Address space is useful, but it can be exhausted by dedicated-server assignments, customer add-ons, infrastructure, abuse quarantine or reputation segmentation. Customers should ask how additional IPs are assigned and how reverse DNS is handled.

Bandwidth language needs the same caution. VPS plans say unlimited bandwidth. Dedicated plans advertise 1 Gbps unmetered uplinks. PeeringDB reports traffic in the 1-5 Gbps band. These can coexist, but they are not the same metric. A customer cannot infer that every server can sustain 1 Gbps indefinitely during upstream failure. The contract should define port speed, traffic policy, fair use, congestion response and attack handling.

Repair capacity is the harder public unknown. The billing cart can show that a server is in stock, but it cannot show whether there is a spare motherboard, power supply, boot device, NVMe drive, switch port, optics module or trained technician available at the hour a customer needs recovery. The dedicated plan's IPMI and custom ISO support are useful because they let customers perform some recovery work without waiting for hands-on access. They do not replace physical spares.

For serious use, buyers should ask what is repaired in place, what is migrated, what requires a fresh provision, and how long old storage is retained after a failure.

This is not a critique of White Sky specifically. It is how small infrastructure economics work. The provider packages finite hardware, finite routing and finite support into affordable plans. Customers get value because they do not have to build the stack themselves. They also inherit provider limits when the stack is stressed.

Who is affected when White Sky has a bad day

The affected parties are visible from the catalogue. Game-server customers may lose Minecraft, Valheim or Satisfactory worlds, community events, Discord-linked management and player trust. A short outage can matter if it lands during a tournament, paid community event or streamer session. A longer outage can corrupt worlds if backups and shutdown handling are weak.

VPS customers may run websites, bots, development environments, monitoring endpoints, small databases, VPNs or secondary services. For them, the main risk is not only downtime. It is state recovery: whether the VM image is consistent, whether snapshots exist, whether the customer can export data, whether DNS can move, and whether firewall rules and credentials are documented.

Dedicated-server customers may rely on single-tenant hardware for game networks, revenue-generating websites, storage-heavy workloads or agency projects. They need to know the replacement path for chassis, disks, power supplies and network ports. The cart's in-stock Ryzen plan is attractive, but customers should ask whether spare equivalent hardware exists for repair, not only sale.

Website-package customers, if they use White Sky's web-hosting product, may depend heavily on cPanel, DNS, mail and billing. The status page lists cpanel-01 as a component and the main site links website packages. These customers may be less technical and less prepared to export data quickly. They should know where backups are held and how to move the site if the provider or control panel is impaired.

The provider itself is also exposed. Because visible public hostnames cluster in 31.56.65.0/24, an incident affecting that prefix could become reputational quickly. The external status page helps, but the company would still need out-of-band support communications, DNS recovery and customer messaging that does not depend entirely on the affected systems.

The broader internet impact is likely modest. White Sky is not presented in public evidence as a hyperscale platform. The impact is concentrated among its customers and their users. That does not make it trivial. Small infrastructure providers often host exactly the communities and small businesses least prepared to build their own redundancy.

What would raise the evidence grade

White Sky could move from Medium toward Strong with a compact public operations page. It should not publish sensitive diagrams, but it could state the city or region of the primary facility, whether the facility is owned or leased, which services run there, how many independent power paths serve customer racks, whether generators are tested, and how remote access works during maintenance.

A network page would help. It could list AS46177's current upstreams, route-security practices, prefix policy, DDoS mitigation scope, IPv6 support, peering goals and planned maintenance channels. Much of the route layer is already visible through RIPEstat routing status, announced prefixes and PeeringDB. A provider-owned summary would reduce ambiguity.

Backup documentation would be especially valuable. White Sky's pages mention protected or offsite backups, but customers need per-product detail: which plans include backups, backup frequency, retention, storage location, restore cost, restore target, customer export path and last test date. Game worlds, VPS disks, dedicated-server data and website packages do not have the same restore model.

Status and incident evidence could improve. The status page is a good start, and the JSON summary is useful. A public incident archive with real maintenance notes, affected components, start and end times, root cause and corrective action would make the uptime claims easier to trust. It would also show customers how the provider communicates when something goes wrong.

Finally, the knowledge base should separate customer-facing guidance from operator-only examples. It currently exposes useful architecture concepts and placeholder-like examples. That openness is helpful for diligence, but customers need the public docs to make clear which parts are real production behaviour, which are examples, and which are not customer-configurable. Clearer documentation would reduce support confusion during incidents.

The buyer's practical questions

A buyer should start with the route question. Which prefix will my service use: 31.56.65.0/24, 23.136.228.0/24, 2602:f696::/40 or another block? Which origin AS appears from public collectors? Are IPv4 and IPv6 both supported for the product? Who controls reverse DNS and route authorization?

Then ask the facility question. Where is the server physically hosted? Is it in the facility White Sky says it owns and operates? What does Tier-3 mean in this context? Is there A/B power to the rack? Are there separate upstream entrances? What is the remote-hands or staff response model? What happens during planned electrical or cooling work?

Then ask the hardware question. For VPS, what hypervisor generation, storage backend and failover model apply? For dedicated servers, what replacement stock exists for the purchased class? For game servers, how are worlds backed up and restored? For website hosting, how can a customer export cPanel data, DNS zones and mailboxes?

Then ask the switch and automation question. If the service uses additional IPs, VMACs or port-security bindings, how are changes tested and rolled back? What happens if Tenantos, Proxmox or the switch automation fails? Is there a manual emergency path?

Then ask the support question. Which channel is emergency-grade: billing ticket, Discord, email or another path? What is staffed after hours? What does the 99.95 percent uptime promise cover? Does a DDoS event change the support path? Does the status page remain independent during network incidents?

Then ask the exit question. Can the customer leave with images, data, backups, logs and DNS? How long can old and new services overlap? Are provider-assigned IP addresses portable? If not, how much notice will be given before renumbering, termination or address-policy changes?

These questions match White Sky's strengths. The provider has enough public evidence to make detailed questions worthwhile. It also has enough undisclosed dependency to make those questions necessary.

Bottom line

White Sky Hosting is a live, inspectable small hosting provider. Its public evidence includes AS46177, current route visibility, ARIN and RIPE address records, a commercial website, WHMCS-style billing, public support-ticket creation, a status page, game and dedicated-server plans, VPS plan tables, authoritative DNS in its routed prefix and a knowledge base that discusses Juniper switches, Proxmox nodes, Tenantos provisioning, port security, VMACs, VLAN allowlists and switch backups.

That is much stronger than a dormant directory card. It supports a Medium evidence grade and a real operating profile. Customers can see enough to evaluate the service rather than guessing from a name.

The public record still stops short of resilience proof. It does not independently verify the claimed owned facility, Tier-3 status, power design, rack diversity, upstream contracts, DDoS capacity, backup independence, restore testing, spare hardware levels, support staffing or cross-site disaster recovery. PeeringDB has a network record but no public facility or exchange rows. The status page is helpful but not a full incident archive. Several control-plane hostnames appear concentrated in one prefix.

The right conclusion is neither alarmist nor credulous. White Sky Hosting appears to operate real hosting infrastructure and to expose more operational detail than many peers. Its customers should still design as though the service is physical: racks, switches, IP bindings, upstream routes, power, support queues and backup jobs can all fail. The safest buyers will use White Sky for workloads that match its price and evidence, while keeping their own backups, DNS control, monitoring and migration path outside the provider.