Summary

  • The Macrohosting name connects across LACNIC, CABASE and the provider's website to Nicolas Lagunas Turczyn and an Argentine hosting operation. The public pages reviewed do not identify a separate incorporated counterparty or tax number, so a buyer still needs the exact contracting identity.
  • AS265694 was visibly originating a 1,024-address IPv4 allocation through three overlapping route announcements on July 15, 2026. All 326 included IPv4 collectors saw it, and the observed routes were RPKI-valid; this is meaningful network evidence, not proof of application uptime, server ownership or backup quality.
  • A customer can select hosting, VPS, email, domains and managed services through a live account portal. Yet generic security copy, sample testimonial text, an empty public knowledge base and a status route that leads to login make the public assurance layer weaker than the ordering layer.
  • The Argentine registration, Buenos Aires contact points and AR-IX presence do not establish data residency. Procurement should bind each service to a legal counterparty, facility, origin network, backup location, support schedule, restoration target and remedy before treating the brand as operating assurance.

The name joins across several records, but not into a full contract

The BTW directory entry begins with an unusual identity string: a person's full name followed by the Macrohosting brand in parentheses. That form is not merely a directory convention. LACNIC's record for AS265694 names the registrant as Nicolas Lagunas Turczyn(MACROHOSTING), identifies Nicolas Lagunas Turczyn as the administrative, technical and abuse contact, and records the autonomous-system allocation on March 31, 2017.

There are useful joins outside the number registry. The Macrohosting website publishes a Buenos Aires contact address and a telephone number ending in 3147-0978. The number matches the core number in LACNIC's registrant record, despite differences in formatting. CABASE, the Argentine internet chamber, lists Lagunas Turczyn Nicolas (Macrohosting) among its members under hosting and housing. Together, those records support a reasonable conclusion that the person, brand, website and network registration belong to the same operating surface.

The limits are equally important. LACNIC is recording responsibility for internet resources; it is not certifying an incorporated company, beneficial owner, financial condition or authority to make every commercial promise on the website. The site's legal notice gives the Macrohosting name, address, phone and contact email, but the reviewed page does not state a legal form, tax identifier or registration number. The website now gives an address on Avenida de los Lagos, while the LACNIC record gives Avenida Gaona. A change of address, separate business premises or an older registry record could explain the difference.

The public evidence does not choose among those explanations.

That means the brand is traceable without yet being contract-complete. A business customer should ask the order form and invoice to state the legal name, tax number, notice address and person authorised to bind the supplier. It should also say whether Nicolas Lagunas Turczyn is contracting as an individual, through a company, or on behalf of another entity. This is not paperwork detached from reliability. The answer determines who must return data, issue credits, respond to a legal notice and fund restoration after a serious incident.

An orderable catalogue is evidence of a service, not of every promise

Macrohosting's storefront is concise. It offers shared hosting with 20 GB of storage, cPanel, Imunify360 and included SSL, plus two larger hosting configurations described with virtual cores, memory, storage, CloudLinux and DirectAdmin. The order buttons lead into a separate customer administration portal that exposes categories for web hosting, VPS, corporate email, managed services, domains, site security and support. Customers can choose between US dollars and Argentine pesos, create an account, place an order and enter a ticket-oriented support area.

This is a recognisable automation layer. Product selection, currency, registration, ordering and account access have been moved into software. For a small company buying web hosting, that can remove several manual exchanges before service begins. It also creates a record of the selected plan and a channel for later requests. The catalogue is therefore stronger evidence than a static page saying only that cloud services are available.

But automation does not settle what happens after checkout. The public pages reviewed do not state a provisioning deadline, resource contention policy, maintenance window, backup schedule, restoration objective or numerical support response target. A virtual-core count says how a plan is packaged, not how CPU time is scheduled under load. Included SSL says little about renewal failure handling. Security-product names identify components but do not establish configuration, monitoring, patch responsibility or compensation after an incident.

The portal also carries reasons for caution. Its home page says more than 35,000 customers trust the service and displays a 100 per cent uptime guarantee. Around those claims are generic SiteLock descriptions, sample names and repeated lorem ipsum testimonial text. The public announcements area shows the standard message thanking the user for choosing WHMCS. Those elements look like unfinished vendor-theme content rather than company-specific evidence. They do not prove that the service is poor; they mean the affected claims cannot responsibly be used to prove that it is good.

This distinction matters in enterprise software procurement. A functioning billing and account system proves that transactions can be automated. It does not prove that the operational policies behind the buttons are complete. Buyers should ask for a service description that converts each visible feature into a testable obligation: when the resource becomes available, what limit applies, how usage is measured, which logs can be exported, what change history is retained and how a failed automated action reaches a human operator.

AS265694 is the strongest operating evidence

The network record is more concrete than the warranty language. LACNIC directly allocated 170.78.136.0/22 to Nicolas Lagunas Turczyn(MACROHOSTING) on September 28, 2016. The block runs from 170.78.136.0 through 170.78.139.255, a total of 1,024 IPv4 addresses. The same named person is listed for administrative, technical and abuse responsibility.

By July 15, 2026, RIPEstat's routing view showed AS265694 actively originating that address space. The system was visible to all 326 IPv4 peers included in the response. RIPEstat counted three IPv4 announcements, no IPv6 announcement and two observed neighbours. The current origin history reached back to July 1, 2017.

The three routes need careful reading. The operator announced the covering 170.78.136.0/22 and the two more-specific halves, 170.78.136.0/23 and 170.78.138.0/23. Those routes overlap; they do not add up to 2,048 distinct addresses. The allocated and originated space remains 1,024 IPv4 addresses. RIPEstat's prefix history showed all three continuously present during the July 1-15 observation window. Route-origin validation returned valid for the covering block and both /23s under a route authorisation permitting lengths through /24.

That is valuable evidence. The network is not represented only by a dormant registration. Its prefixes were being propagated widely, and an origin-authorisation control was in place. A customer can monitor the ASN and routes independently of the provider's marketing page. An abuse report also has a named contact path in the authoritative record.

The evidence still has a boundary. A visible route cannot reveal whether a particular website, mailbox or VPS uses these addresses. It does not measure packet loss, latency, capacity headroom, server availability or incident response. RPKI validation authorises the origin; it does not authenticate every path or protect an application from failure. The absence of an observed IPv6 announcement is relevant for a buyer that requires native IPv6, but it should be confirmed against the ordered product rather than turned into a claim about every private or partner network the provider may use.

AR-IX presence adds a local interconnection clue

Macrohosting also maintains a public PeeringDB network profile. The record describes AS265694 as an enterprise network with a South American scope, mostly outbound traffic and an open peering policy. It was updated in March 2026. Its exchange record lists an operational IPv4 port at AR-IX CABASE, with a stated speed of 10 Gbps and route-server participation.

That exchange presence helps explain the network's local role. Connecting at AR-IX can provide a direct path to other entities rather than sending every packet through upstream transit. Combined with CABASE membership and the active routes, it is a persuasive sign that Macrohosting participates in Argentina's internet ecosystem rather than merely reselling a foreign storefront under a local name.

PeeringDB information is operator- and exchange-maintained directory data, however, not a traffic audit. A 10 Gbps exchange port does not mean every customer receives 10 Gbps, that the port is uncongested at peak time or that all destinations use it. Nor do two observed routing neighbours establish physically diverse fibre, separate buildings or independent power. The procurement question is not simply whether there is more than one named connection. It is whether the ordered service has paths whose failure modes are sufficiently independent, monitored and covered by an escalation agreement.

A useful network schedule would name the service prefix and origin ASN, customer port or shaping limit, IPv6 availability, primary and alternate upstreams, exchange dependencies, DDoS handling and the evidence used to measure availability. It should also say who contacts CABASE, an upstream or a facility when the fault sits outside Macrohosting's own equipment. Public resource records identify the network. The schedule would identify the service the customer is actually buying from it.

Argentine network evidence does not settle data location

Nearly every public identity clue points to Argentina: the LACNIC country, Buenos Aires contacts, CABASE membership, South American PeeringDB scope and AR-IX connection. It would still be unsafe to infer that all customer data remains in Argentina.

The reviewed public pages do not name a data centre, facility operator, city for the servers, backup site or cloud subprocessor. They do not say whether shared hosting, VPS, email and managed services use the same infrastructure. Exchange presence describes where networks interconnect; it does not locate a disk. A locally originated IP address can serve a workload in one place while account data, ticket attachments, DNS, security telemetry or backups are processed elsewhere.

The thin privacy page sharpens the problem. It offers no public explanation of data categories, processors, retention, international transfers or deletion. For an individual buying a low-risk website, that may be a reason to ask a short question. For an enterprise handling employee, customer or regulated data, it is a missing part of the service specification.

Locality should therefore be mapped by data class. The customer needs the primary and recovery location for hosted files, databases, mailboxes, snapshots and backups. It also needs locations and retention rules for account identity, invoices, support messages, access logs, monitoring and malware findings. If a third-party security, control-panel, DNS or payment service receives data, its role should be stated. Only then can an Argentine supplier and Argentine network become an evidence-based residency position.

Support exists as a channel; accountability needs service terms

Macrohosting exposes several ways to begin a conversation. The main site has a contact form and telephone number. The portal has a public contact form, registration and login, plus menu entries for tickets, announcements, a knowledge base and network status. Those elements show that customer support is part of the intended service, not an entirely absent afterthought.

What they do not show is the labour commitment behind the interface. The knowledge base returned no public articles during review. The network-status route led to a client login rather than a public component history. The reviewed pages did not disclose support hours, severity levels, acknowledgement targets, restoration targets, escalation contacts or outage remedies. A ticket button can organise requests, but it cannot by itself guarantee that the right engineer will respond before a customer's recovery window expires.

This is where a smaller provider can either create or lose value against a hyperscale alternative. A local operator may offer direct language, local context and access to someone who understands both the server and the network. Those advantages are operational only when the people, hours and authority are real. The customer should know who watches the platform outside office hours, who can change a route, who can restore a backup, who can approve emergency access and who communicates when a dependency fails.

Backup responsibility deserves its own line. No reviewed public document establishes that every plan includes backups, how often copies are made, how long they are retained or whether restoration is tested. Storage capacity in a plan is not a recovery promise. A buyer should assume responsibility remains unresolved until an order states the recovery point, recovery time, copy location, encryption arrangement, retention period and restore-test cadence.

Convert the public footprint into an assurance pack

Macrohosting has more operating substance than its sparse storefront initially suggests. The person and brand recur in authoritative resource records. The IPv4 block is directly allocated. The autonomous system has a long-lived, globally visible route origin, valid origin authorisation, two observed neighbours and an operational AR-IX entry. Those are useful and independently inspectable facts.

The next step is not to demand a larger website. It is to make the commercial record as precise as the network record. Before placing a production workload, a buyer should obtain one document that names the legal counterparty and ties the selected plan to its facility, address range, origin ASN, upstream model and customer resource limits. It should define maintenance, monitoring, incident severity, support coverage, escalation, restoration, credits and termination assistance.

A second schedule should map data and recovery. It should locate primary data, backups, account records, tickets and security telemetry; identify subprocessors; set retention and deletion rules; and record a tested export and restore path. A third should allocate human work: who patches the operating system, renews certificates, watches resource exhaustion, responds to malware alerts, changes routes and contacts external providers.

That pack would not replace the value of Macrohosting's public network evidence. It would let the evidence do its proper job. AS265694 proves a visible operating role on the internet. The catalogue proves that services can be ordered. The contact surfaces prove that requests can be submitted. Operating assurance begins when those facts are joined to enforceable, product-specific answers about identity, control, locality, recovery and human response.