Summary

  • AS131316 had seven visible IPv4 announcements covering 2,048 addresses on 15 July 2026. PeeringDB listed operational 10 Gbps exchange connections in Melbourne and Perth and a 1 Gbps EdgeIX connection in Melbourne, while RIPE RIS saw the network through 325 of 326 IPv4 peers.
  • The current dedicated-cloud sheet starts at A$200 plus GST and promises a CWP-based VPS with redundant compute, storage and networking. It does not identify a cloud facility, second compute site, rack count, storage layout, power design, spare-host pool, recovery objective or tested failover result.
  • The same four-page product document gives two different resource descriptions: at least 2 vCPU, 8GB RAM and 50GB SSD near the front, then a 6-core, 16GB RAM and 150GB SSD VPS in its closing summary. A customer needs the quotation and service schedule to settle what is actually reserved.
  • Current network operation is well supported, but hosted-capacity resilience is not. The fair assessment is Medium for the visible network and Weak for the public evidence of physical cloud redundancy, usable spare capacity and customer restoration.

The clearest number is on the network edge, not inside the cloud

Slnet Hosting has a more substantial public network footprint than its compact name might suggest. At 08:00 UTC on 15 July 2026, RIPEstat's routing-status view for AS131316 counted seven IPv4 prefixes, 2,048 announced addresses, five observed neighbours and visibility from 325 of 326 IPv4 RIS peers. The first observed route dated to July 2011. This is not a dormant registration kept on a shelf. It is a long-running autonomous system whose routes were almost universally visible to the collectors in that snapshot.

The interconnection record is specific too. The operator-maintained PeeringDB profile lists a 10 Gbps port at IX Australia Melbourne, a second 10 Gbps port at IX Australia Perth and a 1 Gbps port at EdgeIX Melbourne. All three entries are marked operational and all three include IPv4 and IPv6 exchange addresses. EdgeIX's own participant list independently shows Screw Loose Software, AS131316, on a 1 Gbps connection. Those records establish a credible east-west Australian network edge.

They do not establish the capacity of the cloud sold to a customer. An exchange port is a place where a network can exchange traffic. It is not a count of hypervisors, a storage-replication guarantee, a power reservation or proof that a customer's workload can restart in the other city. Summing 10, 10 and 1 into a 21 Gbps headline would be arithmetically easy and operationally misleading. The ports sit at different exchanges, may serve different traffic, and can be constrained by transit, route policy, internal links, server ports or the workload itself.

The customer-facing hosting number comes from a different document. Screwloose IT's December 2025 Dedicated Cloud Hosting service sheet advertises a VPS container from A$200 plus GST a month. It says the platform includes underlying redundancy across compute, storage and network. Yet it does not name the data centre, the number of independent rooms or racks, the location of the backup copy, the recovery time, the recovery point, or the most recent failover test.

That gap defines the story. Slnet can prove a live routed edge. It can prove that a current hosting product exists. The public record does not join those two layers into a verifiable recovery design.

Slnet is the network name inside a broader Australian services business

The names around AS131316 need to be untangled before judging ownership. APNIC's autonomous-system record calls the network SLNET-AU, describes it as Slnet Hosting and identifies the registrant as Screw Loose Software. The registration has been active since 7 June 2011 and was last changed in September 2024. PeeringDB uses Screw Loose Software as the organisation name and ScrewlooseIT as the alternate name.

The current commercial website uses Screwloose IT. Its customer documents display ABN 59 160 395 479. The Australian Government's ABN Lookup record identifies that number as Australian Client Services Pty. Ltd., an active private company, and lists Screwloose IT and Hostone among its registered business names. In other words, Slnet Hosting is best understood as the public routing and hosting identity associated with a wider Australian managed-IT, telecommunications and cloud business. It should not be treated as a separately verified legal company merely because the ASN has a distinct label.

The first-party history gives useful context. Screwloose IT's company page says it invested in a data-centre presence in 2009 and began offering Hosted Exchange, website and web-application hosting, cloud servers and cloud desktops. It says the business entered telecommunications in 2013 and later gained a Western Australian footprint through Host One. A separate Host One announcement says the acquisition took effect on 1 January 2022 and added a Perth team and three more support hours each day through cooperation between Perth and Melbourne.

Those two pages do not present a perfectly aligned chronology: one history labels the Western Australian expansion as 2018, while the acquisition announcement gives 2022. The discrepancy does not erase the visible network or the current ABN. It does mean the exact date and legal structure of the Host One integration should come from corporate records and contracts, not a marketing timeline.

The contact page now lists offices in Osborne Park, Mulgrave, Milton and Bondi. These are valuable support and service-area signals. They are not data-centre addresses. An office can house engineers and account staff while customer servers sit in a third-party facility elsewhere. None of the office listings should be plotted as a cloud site without a separate facility statement.

This ownership boundary matters during an outage. Australian Client Services can control the customer relationship, platform configuration, its own servers, AS131316 route policy and escalation. A colocation operator controls building access, power distribution and remote hands. Transit and exchange operators control other parts of the path. The customer controls application design, independent copies and the ability to move. The name on the invoice cannot remove those other dependencies.

Two hosting products expose two very different capacity models

The current product literature describes both shared hosting and a dedicated cloud container. The Website Hosting service sheet prices shared web hosting at A$15 plus GST per month. It provides a CWP account, a shared public address and a common Apache or Nginx, PHP and MariaDB or MySQL stack. CPU, memory and disk input-output are shared among customers. The document expressly warns that one customer's heavy use may affect others, that some settings cannot be changed at account level and that email reputation is shared.

That is a straightforward pooled-hosting arrangement. The provider maintains availability of the shared server, common services, baseline security and server health. The customer or developer maintains the site, code, plugins, themes, database use and administrative accounts. OS patching, CWP repair, performance work, malware removal, site repair and most restores sit outside the A$15 plan. Migration and non-server-fault restoration can be purchased as professional services.

The dedicated product moves the boundary but does not eliminate it. The Dedicated Cloud Hosting sheet describes a VPS container with a dedicated static address, dedicated bandwidth allocation and root-level isolation. It promises at least 2 vCPU, 8GB RAM and 50GB SSD storage, sized through a formal quotation. It also lists a web-application firewall, ModSecurity rules, FirewallD or CSF protections, attack detection, logging, monitoring and automatic service restarts where required.

The provider accepts responsibility for keeping the VPS available, making the allocated CPU, RAM and storage function, maintaining its cloud infrastructure and keeping baseline security controls active. But the fee does not include operating-system patching, CWP updates, server-stack upgrades, performance tuning, stronger hardening, site troubleshooting or incident response for a server-level breach. Restoring a compromised site is outside scope, and restoring from backup is included only when the need arises from server failure.

This is not a criticism of an unusual contract. Hosting is often divided into facility, platform, system and application layers. The important point is that the current sales page calls Screwloose's offer a professional cloud service and says local specialists provide ongoing support, while the formal inclusions sheets draw a narrower line around the base hosting fee. A buyer needs to decide whether it wants an isolated container, a managed operating system, a managed application, or all three. The invoice can look like one cloud service while recovery crosses several separately priced responsibilities.

The 2-core and 6-core descriptions cannot both define one standard minimum

The dedicated sheet contains a concrete specification problem. Section 2 says every dedicated environment will include at least 2 vCPU cores, 8GB RAM and 50GB SSD storage. Section 6, on the final page, summarizes the plan as a dedicated 6-core, 16GB RAM and 150GB SSD VPS. The document does not explain whether the larger configuration is an example, a revised plan, a customer-specific remnant or the actual standard product.

This matters because capacity accounting begins with the unit sold. If the base container reserves two virtual cores and 8GB, its host-density and price economics differ from a six-core, 16GB service. A 50GB disk creates a different backup, snapshot and migration burden from 150GB. The phrase "starting from" already leaves room for quotations; the contradictory summary makes the quotation essential rather than supplementary.

A customer should not resolve the discrepancy in its own favour. It should ask for a signed service schedule that states whether CPU is shared, capped, burstable or pinned; whether "core" means vCPU or physical core; whether memory is reserved; whether storage is local or distributed; whether 50GB or 150GB is included; and whether the static address comes from AS131316. It should also ask what "dedicated bandwidth allocation" means in megabits per second, whether it is a port speed or a committed rate, and what congestion or fair-use controls apply.

The discrepancy also limits any estimate of installed capacity. Public routing data provides 2,048 addresses, but one address does not equal one VPS and many addresses can serve routers, shared hosts, customer networks or dormant assignments. The product sheets provide per-account resources, but no host count. PeeringDB provides port speeds, but no server-facing fabric capacity.

The defensible capacity statement is therefore narrow. Slnet has a real routed address estate and declared exchange connectivity. Screwloose sells at least one shared-hosting tier and one quoted VPS tier. The total number of servers, virtual cores, terabytes, racks and available orders remains undisclosed.

Seven valid IPv4 routes show current operation, not spare compute

The route estate is unusually tidy. RIPEstat's announced-prefixes response showed these seven routes continuously visible over the observed 1-15 July window: 103.4.122.0/24, 103.4.123.0/24, 103.50.12.0/24, 103.50.13.0/24, 103.100.199.0/24, 103.114.34.0/24 and 103.172.76.0/23. Together they contain 2,048 IPv4 addresses.

APNIC records reveal the history behind the set. The 103.4.122.0/24 and 103.4.123.0/24 records carry the SLNET name. 103.50.13.0/24 is registered to Hostone Pty Ltd. 103.114.34.0/24 names Screw Loose Software. The 103.172.76.0/23 allocation names Australian Client Services Pty Ltd. Another visible /24 is drawn from a block registered to Bottle Communications. These labels are consistent with a network assembled across operating names and acquired or related address holdings, but they do not by themselves prove the current contract governing each block.

All seven origin checks returned valid in RIPEstat when tested against AS131316. For example, the 103.172.76.0/23 validation found a matching route-origin authorisation with a /23 maximum length. Valid RPKI is valuable: it lets participating networks reject an unauthorized origin for the covered route. It does not keep the authorized router powered, prevent a bad policy, add bandwidth, or restore a failed server.

The public edge also had no originated IPv6 space in the RIPE snapshot. That is notable because each PeeringDB exchange entry includes an IPv6 interface. An IPv6 address on an exchange LAN shows that the router can participate there; it is not the same as originating customer IPv6 prefixes. A buyer that needs native IPv6 should ask for a service-specific allocation and test it, rather than infer availability from the exchange rows.

The seven routes are strong evidence that the operator remains active. They cannot tell a buyer how many addresses are free, how much server inventory is available behind them, whether the Perth and Melbourne address pools map to separate compute, or whether a customer's address can move during a site failure.

Three exchange rows are not a physical route map

PeeringDB labels the 10 Gbps Melbourne and Perth exchange connections operational, and the newer EdgeIX Melbourne entry was updated in March 2026. Packet Clearing House's WA-IX participant view also lists AS131316 at 27.106.192.207, providing independent corroboration of the Perth exchange identity. The network is plainly represented in both cities.

What is absent is just as important. The PeeringDB API returns no facility records for AS131316. That does not prove the network owns no racks or leases no colocation. PeeringDB is self-maintained and incomplete. It means only that the public profile does not identify the buildings in which Slnet's routers or hosting systems sit. The exchange names identify metro fabrics, not exact suites, power feeds or cable paths.

An exchange connection can be delivered several ways. A router may sit in one of the exchange's listed facilities. A carrier can extend the exchange LAN over transport to another building. A reseller can provide a virtual connection. A single physical port can carry several logical services. Without a facility record or operator statement, an exchange row should be treated as logical metro presence with a declared port speed, not a route drawn through a named building.

The same caution applies to address geolocation. IPinfo places responsive AS131316 addresses in Melbourne and Perth and observed a recent short path to 103.172.76.1 from a Perth probe. That is a useful market signal. Geolocation databases can be based on registry, latency, routing and operator submissions, and can be wrong at building level or even city level. A probe result shows a network endpoint answering with low latency from a location; it does not show the rack that holds customer disks.

Screwloose's offices cannot fill the gap. An Osborne Park support office is not automatically the WA-IX router site. A Mulgrave office is not automatically the Melbourne cloud. The 2009 statement about a data-centre presence establishes that the company entered hosted infrastructure, but it does not name a current facility. The Host One acquisition supports a Western Australian business and network footprint, but it does not state that VPS containers replicate between Perth and Melbourne.

The map that can be drawn responsibly has two city-level network nodes, Melbourne and Perth, plus four business offices. It cannot include an exact cloud facility, a customer-data route or an inter-city failover line. Those remain procurement questions.

Redundancy must be attached to a failure domain

"Underlying infrastructure redundancy" sounds comprehensive because it names compute, storage and network. To make the phrase operational, each layer needs an independent component and a defined failure it is intended to survive.

Compute redundancy may mean a spare physical host, a cluster that can restart a container, live migration, or simply multiple power supplies in one chassis. Those designs have different outcomes. A spare host can absorb one failure only if it has enough compatible CPU, memory, storage access and network configuration. Live migration helps during planned maintenance but may not help after a sudden host or storage failure. Two hosts in the same rack still share rack power and switching.

Storage redundancy may mean mirrored drives, RAID, replicated volumes, snapshots or backups. Mirroring can survive a drive failure but copy corruption immediately. A snapshot can protect against a mistaken change while remaining on the same array. Replication can improve availability while preserving the same operator and account dependency. A backup becomes useful only when it can be restored with the applications, settings, credentials and network configuration needed to resume service.

Network redundancy may mean dual links, two switches, two routers, separate upstreams or physically diverse building entrances. PeeringDB's three exchange ports create useful options, and RIPEstat's neighbour view observed Kinetix Networks, Simtronic, Hurricane Electric and two lower-confidence neighbours. But observed BGP adjacency does not reveal contracts, traffic share, fibre paths or whether failover was tested. Two logical upstreams can share one carrier tail or power domain.

Power redundancy is not described in the hosting sheet at all. Public material does not state the number of utility feeds, UPS topology, generator runtime, rack power density or whether Slnet's equipment uses A and B feeds. Those are normally facility-level facts and may be available under confidentiality, but they cannot be inferred from an exchange connection.

The relevant customer question is not "Is it redundant?" It is "Which single failures can this service survive without customer action, and what happens after two related failures?" A useful answer names the primary and secondary hosts, storage copy, rack and facility, the trigger for restart, the expected data-loss interval, the expected restoration time and the last successful exercise. No public Slnet document provides that chain.

The first failure path starts inside the VPS

A Slnet-hosted application can fail while AS131316 remains perfectly visible. The guest operating system can hang. A full filesystem can stop a database. An unpatched CWP component can be compromised. A site plugin can exhaust memory. A certificate can expire. In these cases, routers, facility power and the physical host may all be healthy.

The dedicated service sheet draws this boundary sharply. The provider monitors basic reachability and keeps baseline firewall tools active, but operating-system patching, CWP updates, web-stack upgrades, proactive tuning and stronger hardening are not included. Site-level compromise recovery is also outside the base fee. A customer that thought "professional cloud hosting" included managed system administration could discover the difference during the incident.

The second failure path is the host. A processor, memory module, mainboard, network card, drive, controller or power supply can fail. The public record does not disclose how many hosts exist, whether customer disks are local, whether a cluster can restart a container elsewhere, how much reserved memory is kept free, or whether replacement parts are on site. Automatic service restart is useful for a crashed process; it is not evidence that a failed chassis can be replaced within a target.

The third path is shared storage or the server pool. A dedicated VPS may have reserved guest resources while still sharing storage arrays, switches and control systems with other containers. A shared-hosting account goes further: the product sheet explicitly says customers share CPU, memory and disk input-output, and one heavy user may affect others. Capacity pressure can therefore appear as slow pages, delayed database queries or failed mail before it appears as a complete outage.

The fourth path is the rack and facility. A breaker, power distribution unit, cooling event, access restriction or maintenance error can affect several hosts at once. Redundancy inside one chassis does little if both power supplies use the same feed. A spare host in the same rack may be unavailable during a rack outage. Without a named second failure domain, the public redundancy claim should be treated as local to an undisclosed architecture.

None of these risks proves poor operation. They define the evidence a serious buyer needs. Slnet's current documents establish responsibilities and product features. They do not publish failure history, status metrics or timed restoration results that would show how the layers behave under stress.

Backups are promised in marketing and assigned to the customer in the terms

Screwloose's cloud-services page says the cloud is always backed up and puts redundancy at the core of the solution. The broader migration material recommends immutable copies, agreed recovery time and recovery point objectives, routine test restores and rollback plans. These are sensible practices.

The legal and product documents are more conditional. The General Terms and Conditions state that the customer is solely responsible for backing up and securing data connected to or supplied with the service. The dedicated sheet excludes restoring a website from backup unless the need arose from server failure. The shared sheet similarly limits included restores and makes other restoration billable.

Those statements can coexist if the service maintains infrastructure copies while the customer remains responsible for business recovery. But the public documents do not define the distinction. They do not state backup frequency, retention, encryption, immutability, location, media, account separation, restore bandwidth or deletion timing. They do not say whether "always backed up" applies to every VPS, only to managed engagements, or only to some data classes.

The Australian Cyber Security Centre's Essential Eight assessment guidance distinguishes having copies from proving restoration. It asks whether data, applications and settings can be restored to a common point in time and whether full or partial recovery has been exercised. That distinction is directly relevant here. A disk copy without the correct CWP configuration, database state, DNS, keys and firewall rules may not recreate a working service.

A Slnet customer should ask for two answers. First, what copy does the provider maintain to recover from its own host or storage fault? Second, what copy can the customer retrieve independently if the provider, account or facility is unavailable? The second copy should include data and enough configuration to rebuild on another platform. It should be tested outside the primary hosting account.

Without those answers, the safest interpretation is conservative: provider redundancy may improve normal availability, but the customer still owns continuity. That is also the position most consistent with the posted general terms.

Route diversity helps only when the server is reachable from the edge

AS131316's observed network relationships reduce the chance that one logical adjacency is the entire public edge. RIPEstat saw two high-power left-side neighbours, AS134143 and AS55707, plus Hurricane Electric and two uncertain relationships. PeeringDB shows route-server participation at all three exchanges. Public route-origin authorisations cover all seven visible prefixes. This is a stronger routing posture than a small host with one provider-assigned address block and no independent AS.

Yet each network control answers a limited question. RPKI helps other networks distinguish an authorized origin. It does not stop Slnet from withdrawing a route or announcing a wrong path. An exchange route server helps establish many peerings efficiently, but it is not a substitute for paid transit to the whole internet. A 10 Gbps port can carry local exchange traffic while customer traffic to another destination uses a smaller or congested transit path. A Perth edge and a Melbourne edge can still depend on one internal control plane or one supplier contract.

The General Terms acknowledge the supplier boundary directly. They allow Screwloose to use and vary a mix of its own and third-party infrastructure, say service may depend on equipment and third-party arrangements, and allow termination where a third party ceases to supply a necessary service. They also disclaim responsibility, to the extent allowed by law, for failures of third-party network infrastructure.

For a hosted customer, route resilience needs to be tested from the workload outward. Is the VPS dual-homed to separate edge routers? Are those routers in the same building? Does the customer prefix appear through both transit relationships? Can a route move between cities without moving the server? Does DDoS mitigation introduce another dependency? Is there an out-of-band console when the public route fails?

IPv6 deserves its own test. PeeringDB's exchange interfaces are dual-stack, but RIPEstat saw zero originated IPv6 prefixes on 15 July. A customer should not assume its VPS has globally routed IPv6 merely because the edge router has an exchange address. The order should state the assigned prefix, origin and support boundary.

Slnet's public network record is good enough to ask precise questions. It is not detailed enough to answer them on behalf of the operator.

Repair depends on people, scope and the clock

Screwloose presents local support as a differentiator. The cloud page says specialists manage migration and ongoing support and that helpdesk hours are Monday to Friday, 9am to 5pm. The Host One acquisition announcement says Perth and Melbourne teams extend daily support coverage by three hours. The current contact page lists the same weekday office window across four cities.

The posted Managed IT Services SLA adds detail for customers who buy that service. Regular remote and email support runs 9am to 5pm Western Australian time. After-hours calls are forwarded to a mobile where possible and handled on a best-efforts basis, with an external answering service as backup. Urgent incidents have a target response of zero to four business hours, while medium and low priorities can take longer. The first Sunday of each month is reserved for system maintenance with notice if an outage is expected.

That SLA is not automatically the hosting SLA. It governs a named managed-IT agreement and may be replaced by a customer-specific schedule. The dedicated VPS sheet offers basic monitoring but publishes no incident priority, acknowledgement time, restoration objective, service credit or 24-hour engineer commitment for the hosting product itself.

The complaints procedure provides escalation for faults, service, agreements and billing. It promises immediate acknowledgement when a representative answers by phone and acknowledgement within two business days for email or recorded messages, followed by manager escalation if necessary. This is a useful customer-rights path. It is not an emergency repair channel and should not be mistaken for one.

When a host fails at 2am on Saturday, the decisive facts are practical: does monitoring page an engineer; can that engineer reach the hypervisor and storage; is facility remote hands available; is compatible hardware on site; who can authorize a failover; and how is the customer updated? A Monday-to-Friday helpdesk can coexist with automated recovery and on-call engineering, but the public hosting documents do not define that arrangement.

Support labour is capacity. One engineer can handle a routine restart. A facility or route event can produce many simultaneous calls, require supplier escalation and consume the same people who are communicating with customers. Slnet's national office surface is a positive signal. Team size, on-call depth and surge procedures remain undisclosed.

Billing and supplier contracts can stop a healthy server

Not every outage begins with broken hardware. Screwloose's General Terms allow it to restrict, suspend or terminate service when money is owing. They also allow termination if a required third party stops supplying service. These clauses create two non-technical failure paths: the customer account and the provider's supplier chain.

A billing suspension can make a healthy VPS unreachable. A disputed invoice, expired card or administrative error can arrive at the same customer-facing symptom as a router failure. The terms provide a billing-dispute route and require undisputed amounts to be paid. They do not state whether emergency data export remains available during a dispute or suspension.

The supplier path is equally important. Slnet can own routers and servers while leasing rack space, power, fibre, transit or remote hands. A facility contract, carrier invoice or commercial withdrawal can force a migration without any equipment failing. Screwloose's own use of third-party infrastructure is explicit in its terms. Public materials do not name the cloud facility or suppliers, so customers cannot assess concentration, contract duration or replacement options from the website alone.

The Host One history shows why commercial continuity matters. Western Australian operations and address space appear inside the current AS131316 footprint, but the public pages offer different dates for the integration. That does not signal a present problem. It illustrates how business combinations can move people, addresses and customer services across organisational boundaries while the network name remains stable.

The relevant protection is a contract that separates access to data from an account dispute, defines notice before planned withdrawal, states how long data is retained after termination and requires reasonable assistance for migration. A customer should also keep current contact details, payment methods and escalation contacts outside the hosted environment. If the only password vault, email system or support portal is hosted on the affected service, administrative recovery becomes harder.

Cloud economics often make these dependencies invisible during normal operation. The customer pays one monthly amount, while the provider pays several suppliers and allocates finite staff. Continuity depends on every link remaining available or being replaceable within the customer's tolerance.

Portability stops at the address unless the contract says otherwise

Screwloose's 2026 cloud-migration playbook recommends inventory, performance profiling, recovery objectives, immutable copies, pilot groups, phased cutovers, delta synchronization and a tested backout path. It also says workloads and backups should stay in Australian regions when locality matters. This is sound migration advice.

The hosting inclusions sheets make migration a paid or separately scoped activity. Shared-hosting migration can attract professional-service charges. The dedicated sheet says application management belongs to the customer or developer. That means a move from Slnet to another provider may require both infrastructure cooperation and application labour.

IP addresses are especially clear. Clause 12 of the General Terms says an address is issued only for the term of the service, the customer's right to use it ends at termination, and Screwloose controls associated routing and DNS delegation. A normal customer therefore cannot assume that a static AS131316 address will follow its VPS elsewhere.

The consequences extend beyond DNS. Partners may whitelist the old address. Email reputation may attach to it. Security logs, certificates, firewall rules, payment systems and remote APIs may depend on it. Shared-hosting customers face an additional reputation boundary because the service sheet says they share the public address and mail reputation with other accounts.

A practical exit test should rebuild a representative workload on an independent provider using a new address. It should restore current data, rotate credentials, update DNS, replace allowlists, validate outbound mail, verify monitoring and measure the elapsed time. The customer should know which artifacts can be exported: database dumps, web files, virtual-disk images, CWP configuration, DNS zones, logs, certificates and backup archives.

The public record does not say whether a Slnet VPS image is exportable, whether snapshots exist, or how fast a full disk can be retrieved. It does say the customer owns backups and application management. Until the order says more, portability should be designed by the customer rather than assumed from the word cloud.

Australian scope is visible; workload locality is not

Every strong identity signal points to Australia. APNIC gives AS131316 an Australian country code. PeeringDB says its geographic scope is Australia. The ABN is active, the company has Australian business names and the public offices span Western Australia, Victoria, Queensland and New South Wales. The routing edge is declared in Melbourne and Perth. Screwloose's current migration and hosting copy repeatedly discusses Australian businesses and Australian data residency.

That supports an Australian operating scope. It does not prove where each workload, backup, log or support system resides. A registry country code describes the resource holder, not the server. An exchange city describes interconnection, not storage. An office describes business presence, not a rack. Even an Australian primary VPS can have an overseas backup, monitoring service, email relay or support tool.

The distinction matters under privacy and procurement rules. The Office of the Australian Information Commissioner's APP 8 guidance explains that an Australian entity can remain accountable when it discloses personal information to an overseas recipient. It also distinguishes disclosure from some tightly controlled contractor uses and points to contract terms, access, retrieval, deletion and subcontractors as relevant facts. Simply buying from an Australian company does not answer those questions.

Screwloose's own cloud-hosting comparison advises customers to confirm that backups, logs and support tools remain local, not just the primary server. That is exactly the disclosure missing from the dedicated VPS sheet. The page explains the right diligence test but does not publish a location schedule for Slnet's product.

A regulated or locality-sensitive customer should ask for the primary facility country and state, secondary-copy location, support-access countries, subprocessors, monitoring and logging locations, and what changes during failover. It should also ask whether Melbourne and Perth are both orderable compute locations or only network locations. If the service fails over to another platform, the location and contractual controller may change at the moment locality matters most.

A provider can sell beyond Australia without operating a globally distributed cloud. Public evidence supports an Australian network and Australian service business. It does not support a multi-country compute estate.

The economics reward utilisation, while resilience consumes idle capacity

At A$15 a month, shared hosting works by pooling. Many small sites share a server, address, mail reputation, software stack and support structure. At A$200 and above, the VPS product buys more isolation and a larger resource allocation, but it still sits on shared physical infrastructure unless the order says otherwise. Neither price can be understood without utilization.

Providers recover the cost of servers, storage, rack space, power, transit, addresses, software and labour by selling slices of the installed estate. Idle capacity is expensive. A spare host earns little until something fails. A second city requires equipment, licences, connectivity and maintenance even when customers do not actively use it. Backup retention consumes storage; test restores consume staff and temporary compute. Genuine resilience therefore has a cost that may not fit inside the cheapest plan.

Slnet's address estate and exchange presence give it useful economies. It can route its own blocks, peer locally in two markets and spread network engineering across hosting, internet and other managed services. The Host One integration may also spread support across time zones within Australia. These are plausible advantages grounded in visible assets.

The constraints are just as grounded. Shared hosting admits noisy-neighbour effects. The dedicated sheet leaves its base resources inconsistent. The traffic profile in PeeringDB is only 100-1000 Mbps and was last updated in 2024, far below the sum of declared port speeds; because traffic levels are self-reported bands and port speeds are maxima, neither figure proves current load. The public record gives no sold, reserved or free capacity.

For a customer, the right comparison is not simply A$15 versus A$200. It is the cost of meeting an availability target. A small brochure site with external backups and no revenue dependency may rationally accept shared hosting. A business application may need a managed OS, independent backup, secondary environment, after-hours response and tested recovery. Those additions can exceed the base compute price, but they buy the layers that turn a VPS into a continuity plan.

The cheapest service is not necessarily bad, and the most expensive is not automatically resilient. The key is whether the price includes the failures the customer cannot absorb.

What customers should ask Slnet to demonstrate

The first request should be a corrected service schedule. It should settle the 2 vCPU versus 6-core discrepancy, state reserved memory and SSD capacity, define dedicated bandwidth, identify the virtualization and storage boundaries, and list every paid support option needed for patching, incident response and restoration.

The second should be a location schedule. It should distinguish offices, network points and compute sites. For each active cloud location, it should name the facility operator, state or country, whether Slnet owns or leases the hardware, and whether a second location is available for customer workloads. If facility names cannot be made public, they can still be disclosed under a customer agreement.

The third should be a failure-domain statement. Which components are duplicated? Are hosts split across racks? Does storage replication cross racks or facilities? Do network paths leave by separate carriers and building entrances? Are A and B power feeds used? Which failure triggers automatic restart, and which requires a person?

The fourth should document operating capacity. A buyer does not need customer-sensitive inventory, but it can ask for current headroom policy, spare-host targets, storage free-space thresholds, port utilization policy, hardware replacement stock and the conditions under which new orders are delayed. Installed equipment, powered equipment, operational equipment and immediately usable capacity should be separated.

The fifth should be a recovery result. Ask for the date and scope of the most recent host evacuation, storage restore and site-level exercise. Request measured recovery time and data loss, any manual steps, and whether the test used a copy outside the primary account and failure domain.

The sixth should cover the network. Ask which upstreams carry the customer prefix, whether Melbourne and Perth are physically independent, how route-origin and route-leak controls are maintained, whether native IPv6 is available, and how an address changes during recovery. Exchange ports should be treated as supporting evidence, not the whole answer.

The seventh should define human coverage. Which number is staffed after hours for a hosting outage? Who has facility access? What acknowledgement and restoration targets apply? When are maintenance windows, what notice is given, and what service credits apply?

The eighth should cover exit. Can the customer export a full image, database, DNS zone, logs and backups? How long is data retained after cancellation or suspension? Can export continue during a billing dispute? Which addresses, licences and control-panel settings cannot move?

The ninth should settle locality. Where are production data, backups, logs and support tools stored? Who can access them from outside Australia? Which subcontractors are involved? Does failover change the jurisdiction?

The tenth should be a customer-run test. Build a small workload, measure routes and latency, force an application restart, restore from an independent copy and rebuild elsewhere. A successful sales demonstration shows that a service can start. A recovery exercise shows whether it can return.

A live Australian edge surrounds an incompletely described cloud

Slnet Hosting should not be dismissed as a name with no operating substance. AS131316 is active and long-lived. Seven IPv4 announcements were nearly universally visible on the publication date. All seven checked origins were RPKI-valid. Peering records show operational exchange connections in Melbourne and Perth, and EdgeIX independently corroborates the Melbourne 1 Gbps presence. The current business has an active ABN, national offices, current 2026 publications and explicit shared and dedicated hosting offers.

The uncertainty begins where customer resilience begins. PeeringDB names no facility for the network. The hosting documents name no cloud site. The dedicated sheet promises redundant compute, storage and network but gives no topology or test. Its own resource summary conflicts with its minimum specification. Public material does not disclose rack count, host count, raw or usable storage, power, current utilization, spare parts, sold capacity, backup retention, restore results or a second orderable compute location.

That produces a split assessment. Network operation deserves a Medium evidence grade, approaching strong on route visibility and identity but held back by missing facility and physical-path detail. Hosted-capacity resilience deserves a Weak grade because the decisive physical and recovery facts are unavailable. Neither grade predicts an outage. They measure what a customer can verify before one.

The most important distinction is between reach and recovery. Slnet has demonstrated reach: its prefixes are visible and its exchange ports span two Australian metros. Recovery requires a different body of proof: compatible spare compute, independent storage copies, power and route separation, people with access, a defined clock and a customer exit path. Until those details are attached to the A$200 VPS, the hosted promise remains dependent on infrastructure the public can see only at its network edge.