Summary

  • HostingSoltia is a genuine Internet-number identity: RIPE records it as the name of AS201426 and links that number to Soltia Consulting SL. Live observations showed one IPv4 /24 with a valid route-origin authorisation, while Soltia's wider network and public website sit in the larger AS201942 operating context.
  • Soltia publishes a broad Spanish hosting offer and unusually specific promises about uptime, backups, support, data centres and fast deployment. Those claims are useful procurement inputs, but public routing and interconnection records cannot verify customer-level availability, recovery, staffing or data residence.
  • The public record contains material differences that a buyer should resolve before relying on the service: current pages and older general terms describe support, resource allocation, availability and backup responsibility differently, while company, privacy, contract and RIPE records do not all show the same address.
  • The commercial test is therefore record consistency under repeated use. A buyer should require a current signed service schedule, facility and data-flow map, network dependencies, measured support clocks, restore evidence, change logs and an exit test before treating locality or automation as assurance.

The name resolves to a network record

The most important fact about HostingSoltia is that the name has a precise technical origin. The BTW directory entry offers a public place to begin the inquiry, but it does not name a website, alias, registration number, facility or service catalogue. On its own, that is a commissioning clue rather than a company dossier. The stronger attribution comes from the RIPE Database record for AS201426. Its autonomous-system name is HostingSoltia; its organisation reference points to Soltia Consulting SL; and its assigned status dates from October 2014.

That record changes the character of the inquiry. HostingSoltia is not just a string repeated by an unverified directory. It has been maintained inside the European Internet-number registry as the name of a specific routing domain. The entity also declares import and export policies involving AS174 and AS201942. These fields establish an attributable resource and a stated routing relationship. They do not establish that HostingSoltia is a separate legal company, a current retail brand, a product line or the name under which every customer contracts.

The distinction is easy to miss because infrastructure language compresses several layers into one. A company can hold a network number. The network number can carry an engineering label that differs from the company's commercial brand. A larger network can provide transit to a smaller one owned by the same company. A website can run on the larger network while some hosting addresses originate from the smaller one. Customers can buy services described simply as Soltia without seeing either autonomous-system number in their order. All of those statements can be true at once.

For a buyer, the right first question is therefore not whether HostingSoltia exists. It does as a registered network identity. The question is what role AS201426 plays in the proposed service. Will the customer's addresses originate there? Does it carry shared hosting, a particular facility, a legacy platform or a customer segment? Is AS201942 the normal transit path? Which network appears during mitigation or recovery? Public records identify the pieces but do not publish the product map that joins them.

The result is a disciplined starting position. The name supports attribution to a real Spanish resource holder, but it does not carry assurance by itself. An ASN can tell a customer who is authorised to announce a route. It cannot tell the customer whether a database was restored, whether a ticket reached an engineer, whether two fibres share a trench or whether a virtual machine stayed within Spain. Those outcomes belong to other records.

A Spanish company is visible behind it

The legal identity is more concrete than the directory entry. Spain's official 2013 incorporation notice records Soltia Consulting SL beginning operations on 11 January 2013 with EUR3,000 in capital, a Madrid address, a sole administrator and registry sheet M-550986. Soltia's published general terms use the same company name, tax identifier B86633401 and registry references. RIPE's organisation record also names Soltia Consulting SL and classifies it as a local Internet registry in Spain.

These records form a credible identity chain from the HostingSoltia network name to a Spanish limited company. They answer who holds the Internet-number organisation and which legal name appears in the service terms. They do not answer every corporate question. The incorporation notice reports the facts filed in 2013, including an original company purpose beginning with real-estate activities. A company can change or expand its purpose and operations. The fixed public record examined here does not establish when hosting became central, current ownership, present staffing or financial capacity.

One discrepancy is especially relevant because it demonstrates why record freshness is an operating concern. A 2022 official notice records a change of registered office from Calle Zurbano 45 in Madrid to Avenida de los Sauces 41, Parque Coimbra, Mostoles. Current Soltia web pages, the privacy policy and the visible general terms still publish Zurbano. The RIPE organisation record also showed Zurbano even though its modification timestamp was May 2026.

There may be an ordinary explanation. Zurbano could remain a commercial or correspondence office; a later filing outside the examined set could have changed the registered office again; or some pages may simply retain an old address. None of those possibilities can be selected from the available evidence. The point is not to infer misconduct from two addresses. It is to ask which address governs contractual notice, data-protection contact, abuse response and formal escalation, then ensure the answer appears consistently in current documents.

The same standard should be applied to corporate role. The contract should identify Soltia Consulting SL as the counterparty if that is the entity invoicing and delivering the service. Any reseller, facility operator, hardware lessor, software licensor or support subcontractor should be named by function. HostingSoltia can remain a technically useful network label, but legal obligations need the company name, tax identifier, registered address and authorised signatory. A buyer should not ask an engineering alias to carry obligations that only a legal person can perform.

AS201426 is narrow; AS201942 is the wider surface

The observable routing footprint helps define the boundary. A RIPE Stat route query for AS201426 showed one IPv4 announcement, 195.184.73.0/24, during the fortnight ending 14 July 2026. The companion routing-status view counted 256 IPv4 addresses, no visible IPv6 origin and visibility among all 326 participating IPv4 collector peers at capture. RIPE's RPKI validation reported a valid authorisation for AS201426 to originate that /24.

This is strong evidence for a limited proposition. AS201426 was not a dormant name with no visible route at the observation point. Its one observed origin was broadly visible to RIPE's collectors, and the origin matched a cryptographic authorisation. Independent views were consistent: bgp.tools and Hurricane Electric's BGP Toolkit each showed one originated IPv4 /24, no originated IPv6 block and an observed connection through AS201942.

It would be a mistake to inflate those facts. RPKI validity means the relevant holder authorised that ASN to originate the prefix within the permitted length. It does not inspect the servers behind the addresses, the route's physical diversity, a firewall policy, the legitimacy of application traffic or the availability of a customer's service. Broad collector visibility means the route was visible, not that every packet arrived quickly or that a hosted application responded. One /24 also says nothing reliable about customer count or commercial scale.

The wider Soltia surface belongs to AS201942. PeeringDB's entity-maintained record identifies Soltia Consulting SL, also known as SOLTIA, and describes a European cable, DSL and ISP network with an open peering policy. It declares a 1 Gbps connection at DE-CIX Madrid and facility presence in Madrid and L'Hospitalet de Llobregat. Current routing observations for AS201942 showed dozens of IPv4 prefixes, one IPv6 prefix and two observed upstreams. That is materially larger than AS201426's single visible origin.

The public website itself supplies a practical link to the wider ASN. At capture, soltia.net resolved to 31.170.101.96; RIPE Stat mapped that address to 31.170.100.0/22 and AS201942. The HTTPS page was reachable and its certificate covered Soltia's domain. This shows Soltia operating its public web identity on an address originated by its wider network. It does not show that every sold workload uses AS201942 or that the website's physical host is in a particular facility.

This is where network-resource evidence becomes operationally useful. Record the normal origin ASN for each customer prefix, upstream dependencies, RPKI authorisations, DNS providers, mitigation path and expected failover state. Alert when observed state diverges from the schedule. Preserve route and DNS evidence with incident timestamps. The purpose is not to turn a procurement team into a network operations centre. It is to make sure a provider's network names can be joined to the exact service the customer is paying to protect.

The product surface depends on automated state

Soltia's current home page presents a broad catalogue: shared and WordPress hosting, reseller accounts, VPS, dedicated servers, cloud servers, domains and IP-address rental. It advertises cPanel and WHM, daily backups, free migration, security controls and Spanish-language support. The VPS page adds root or managed service, Linux or Windows, snapshots, optional Plesk or cPanel, dedicated firewall features, and deployment in less than five minutes after payment.

This offer is not merely capacity rental. It is a chain of automated records. A new order creates an account, verifies payment, selects an image, reserves compute and storage, allocates an address, applies network policy, creates credentials, updates billing and sends access details. A plan change must alter entitlements without losing data. A snapshot must belong to the right machine and retention policy. A migration must coordinate files, databases, mail, DNS and a cutover time. Each convenient button represents several state transitions that can disagree.

The commercial value of automation is real. Fast provisioning can remove queues. A standard panel can make routine DNS, mailbox, certificate and database work accessible to a small business. Snapshots and scripted migration can reduce manual mistakes. Reseller tools can let an agency separate client accounts without running its own platform. Yet automation earns trust only when every accepted action produces an attributable record and every partial failure has an intelligible state.

A buyer should therefore ask to sample one provisioning record from payment through usable access. The sample should show request time, approval, image and plan identifiers, address allocation, policy application, credential delivery, monitoring enrolment and billing activation. For a change, it should show the before and after state and what happens if one component fails. For deletion, it should show the grace period, snapshot treatment, address release, backup expiry and final credential revocation.

Soltia distinguishes unmanaged and managed VPS. That is important because the control boundary changes. In an unmanaged service, the customer owns operating-system updates, account security, application configuration and much of recovery. In a managed service, the provider's page says its team can handle updates, hardening, monitoring and backups. The order should name each task, cadence, exception and evidence source. Otherwise the word managed can obscure the very responsibilities automation is supposed to clarify.

Current pages and published terms need reconciliation

Public assurance becomes most informative where records do not quite agree. Soltia's current VPS copy says resources are dedicated and not oversold, and promises a 99.9% availability commitment backed by automatic compensation. Its current contact page describes continuous ticket availability with response targets under 15 minutes for a critical incident and under 30 minutes for general technical support. Its home page describes daily backups retained for 30 days. These are specific, testable promises.

The published general contract terms describe a different or older boundary. They say VPS customers share one physical machine and that complete use of contracted resources cannot be guaranteed because performance depends on other customers. They allow scheduled maintenance with or without notice and do not guarantee total availability or sufficient capacity for unexpected demand peaks. They provide up to two free telephone-support hours per month during Madrid business days, with work outside that window potentially charged. Ordinary backups are described as occurring with some frequency, but complete restoration is not guaranteed unless a separate backup service is contracted.

These differences should not be converted into an accusation. General terms can be supplemented by product-specific conditions. Ticket support is not the same channel as free telephone assistance. A new offer may carry a newer SLA than the visible PDF. Managed and unmanaged products may allocate responsibility differently. The contract appears to retain an old address and may simply predate the current pages. The evidence does not establish which version a new customer receives at checkout.

It does establish a procurement requirement: promises that influence the purchase must survive into the executed documents. A customer considering a VPS because of automatic credits should receive the exact availability formula, exclusions, maintenance treatment, measurement point and credit process. A customer relying on daily 30-day backups should receive the backup scope, schedule, retention, encryption, restore method and responsibility. A customer buying 24/7 support should know which products and severities qualify, whether the clock measures acknowledgement or restoration, and which work attracts an additional charge.

For the customer, the practical method is simple. Save the proposal and exact product schedule. Compare them line by line with the order and general terms. List every difference that affects capacity, location, support, backup, security, liability or exit. Resolve the difference in writing before migration. This work can feel formal for a modest hosting account, but its cost is small compared with discovering during an outage that the sales page and governing service boundary measured different things.

Spanish locality needs a workload map

Soltia's data-centre page makes an unusually detailed locality claim. It describes Madrid I as the principal site, Madrid II as a geographically separate redundancy site and Toledo as a backup and disaster-recovery location. It also claims Tier III standards, N+1 infrastructure, multi-carrier connectivity, synchronous replication and automatic failover in under 30 seconds. The VPS page places its plans in an EXA Madrid data centre, while the home page says servers are in Madrid and Toledo.

These claims are commercially meaningful. Spanish placement can reduce latency for Spanish users, simplify some data-governance decisions and improve access to local support. A separate recovery location can reduce a single-site failure. A named city is more useful than a vague European-region label. Yet the public pages do not name the Madrid I and Madrid II facilities consistently, identify certification numbers, show which products use which sites or publish a recovery test.

PeeringDB offers a different kind of location evidence for AS201942. Its self-maintained record lists presence at several Madrid facilities and one in L'Hospitalet de Llobregat, along with DE-CIX Madrid. It does not list Toledo. That absence does not disprove a Toledo backup site. PeeringDB is designed for interconnection, not for inventorying every storage or disaster-recovery location; its facility data is also older than the current web pages. Conversely, presence in a listed facility does not prove that Soltia owns the building, staffs it, or places a particular customer's workload there.

A buyer should turn the locality promise into a data and control map. For each workload, name the primary compute site, database site, object storage, snapshots, long-term backup, logs, monitoring platform, support attachments, encryption keys and administrative access locations. State whether replication is synchronous or asynchronous, which failures trigger it, and what happens to security policy during failover. Include third-party mail, payment, DNS and software services where they process customer or account data.

The map should also distinguish service classes. Shared hosting may use one platform, VPS another and dedicated servers a third. A customer's web files may stay in Madrid while mail uses an external provider. A control panel may send telemetry to a vendor. A backup marketed as Toledo-based may protect only selected plans or require an add-on. The phrase "data in Spain" is useful only after every material copy and support path is assigned to a service and location.

The point is not that Spanish locality is implausible. The company's legal identity, network footprint, facility declarations and current product pages all provide supporting context for a Spanish operating surface. The point is that context cannot choose a customer's exact placement. The provider can close that gap with a current schedule and evidence from provisioning and recovery. Until then, locality remains a first-party promise whose scope must be confirmed.

Backup claims must end in a restore

Backup language exposes the difference between an available feature and a recoverable service. Soltia's home page advertises automatic daily copies retained for 30 days and one-click restoration. The data-centre page adds a Toledo recovery location, long-term retention, synchronous replication and rapid failover between Madrid sites. The VPS page says snapshots are included and managed service can add backups. Together, these statements suggest several mechanisms rather than one uniform backup product.

The general terms draw a stricter line. They say Soltia makes backups with some frequency but does not guarantee complete restoration of ordinary copies; the copy may lag the lost data or be corrupt. They describe a separately contracted backup service under which responsibility changes. This language is valuable because it identifies the risk that marketing shorthand can hide: the existence of a copy is not the same thing as a committed recovery point, a successful restore or a provider accepting responsibility for the outcome.

A useful service schedule should state recovery point and recovery time for each data class. It should name the source, destination, frequency, retention, immutability, encryption, key owner and deletion behavior. It should specify whether databases are application-consistent, whether mail and DNS configuration are included, and whether restore work is included in the price. It should identify events that suspend or invalidate protection, such as non-payment, customer-side encryption, a full storage quota or unsupported software.

Testing then has to cross the line from job completion to customer use. Select a representative site or server, restore it to an isolated environment, verify file and database integrity, rotate credentials, attach the required network policy and let an application owner confirm the result. Measure from declared incident to usable service. Record operator steps and exceptions. A dashboard's green backup state should be treated as an input to that test, not as its conclusion.

The advertised sub-30-second failover deserves its own drill because failover and recovery are different. Which component detects failure? Is the target a network path, virtual host, storage service or complete application? What state can be lost? Does DNS change? Are active sessions preserved? Does the customer need to approve the move? Does the failover site have the same firewall, monitoring, keys and support access? A narrow infrastructure test can legitimately complete in seconds while the customer's application remains unavailable for longer.

Exit is the final recovery scenario. The terms place responsibility on the customer to download content before service ends. That makes export testing essential. A customer should retrieve data, database dumps, DNS records, certificates, logs and configuration in documented formats before termination pressure exists. It should know how long residual backups remain and how deletion is confirmed. A hosting service is more trustworthy when recovery and departure are normal operations rather than exceptional negotiations.

Privacy records describe a boundary, not the whole data path

Soltia's privacy policy was marked as updated in April 2026. It identifies the company as controller for account-related processing and lists identity, contact, billing, technical and support data. It states that support records are kept for three years and technical logs for up to 12 months. It names payment gateways as categories of recipients, refers to infrastructure providers in the European Union, says transfers outside the European Economic Area do not occur without explicit consent, and asserts encryption in transit and at rest.

These statements improve the public record because they supply retention periods and processing categories that many small hosting pages omit. They also concern more than abstract compliance. Support tickets can contain credentials, configuration fragments and incident evidence. Logs can identify users and administrators. Billing records join a person to a service. Retaining these records for fixed intervals affects security investigation, data rights, deletion and the evidence available after a dispute.

The policy does not, however, map all customer-hosted data. In a hosting relationship, Soltia may act as processor for content and account data controlled by the customer while acting as controller for its own billing, security and support operations. The general terms discuss this processing role and permit subcontracting. They also say a subprocessor may be replaced without prior customer authorisation or information. A buyer subject to stricter notification or approval requirements should resolve that clause in the signed data-processing terms.

The data map should name providers by function and legal identity where the risk requires it. Payment processing, mail delivery, control-panel licensing, anti-DDoS service, monitoring, ticketing and offsite backup can all create distinct flows. A statement that infrastructure providers are in the EU is useful but does not show where their support staff, telemetry or subprocessors operate. The provider should be able to explain the lawful and technical path without forcing the customer to infer it from IP addresses.

Retention should be connected to deletion. A maximum of 12 months for technical logs and three years for closed support tickets leaves questions about backups, security events, abuse records and exported ticket attachments. The customer should know when deletion starts, whether retained copies remain searchable, which legal holds can extend periods and what happens when an account closes. For regulated workloads, evidence retention may need to be longer than the default; privacy minimisation may require it to be shorter.

The address mismatch matters here again. Data subjects and customers need a reliable controller contact. A current privacy notice should explain whether Zurbano is the correspondence address while Mostoles is the registered office, or update the record if appropriate. This is not cosmetic. Good data governance depends on identifiers and contact routes remaining consistent across policy, contract, account and registry systems.

Local support is measured in authority and closure

Soltia's contact page sets out a clear support proposition: tickets are available at all hours, a critical service-down incident should receive a response in under 15 minutes, general technical support in under 30 minutes, billing in under two hours and commercial email in under 24 hours. It also says the clocks begin when a ticket is opened. Specific clocks are better than an undefined claim that support is fast.

Their value depends on what the response contains. An automatic acknowledgement can arrive in seconds. A qualified engineer may take longer to inspect the right platform. A network problem may require an upstream carrier. A failed drive may require access to a facility and a spare. A recovery may require customer approval. Procurement should separate acknowledgement, initial triage, qualified diagnosis, workaround, dispatch, arrival, restoration and customer-accepted closure. One response target cannot stand for all seven.

The general terms describe up to two free telephone-support hours each month during Madrid business days, with assistance beyond those limits potentially charged. That can coexist with a 24/7 ticket desk, but only if the channel and entitlement boundaries are clear. A customer should know whether an overnight ticket reaches a person, which actions are included, when managed work becomes billable and whether critical incidents receive authority to change the service immediately.

Local labour matters because hosting failures cross software and physical systems. Someone must interpret an alert, locate the customer asset, verify authority, enter a facility, replace equipment, coordinate a carrier, update the ticket and preserve evidence. A Spanish-language desk improves communication for local customers, but language does not prove presence, technical depth or decision authority. Soltia's public pages do not disclose team size, shift coverage, subcontracting by site or historical performance against the support clocks.

The ticket record should be as trustworthy as the technical event record. Severity changes need reasons. Clock pauses need a named dependency. Customer questions and provider requests should be timestamped. A closed case should state the tested outcome, not only the action taken. Reopened incidents, hand-offs, time to qualified diagnosis and engineer minutes per accepted fix reveal more than a headline response time. They show whether the service reduces customer labour or simply moves it into chasing and supervision.

Support is also where the HostingSoltia identity becomes practical. Incident reports should name the legal operator, affected service, facility or platform, relevant ASN or prefix, responsible team and external dependency. If AS201426 was unaffected but AS201942 carried the failed path, the report should make that distinction. Good local support turns layered records into one coherent explanation; weak support leaves the customer to discover the topology during the outage.

Security claims should be tied to evidence

The home and VPS pages advertise SSL, a web application firewall, daily malware checking, anti-DDoS protection at several network layers, dedicated firewall controls and monitoring. The privacy policy asserts technical and organisational measures and encryption. These controls are plausible parts of a modern hosting stack, but each name can describe a wide range of implementations.

A web application firewall may use a standard rule set, a managed service or customer-specific tuning. Malware checking may scan files daily without inspecting memory, database content or compromised credentials. DDoS protection may filter volumetric traffic while leaving application exhaustion to the customer. A dedicated firewall may be a policy entity on shared infrastructure rather than a physical appliance. None of those models is inherently inadequate; the buyer needs the actual boundary.

The RPKI-valid AS201426 route is one concrete security-positive signal. It reduces ambiguity about who is authorised to originate the observed prefix. It should be credited for exactly that. RPKI does not prevent an authorised network from being misconfigured, a route from taking an undesirable path, an application from being compromised or an administrator from making a harmful change. Security evaluation fails when one visible control becomes a proxy for all the controls that are harder to observe.

Ask for architecture and operating evidence appropriate to the workload. That can include the anti-DDoS activation model, firewall ownership, privileged-access process, vulnerability and patch cadence, backup immutability, event retention, incident-notification terms and recent recovery exercises. If certifications are offered, verify the legal entity, service, facility, scope and date. If penetration tests or audit reports cannot be shared in full, a current independent summary and remediation evidence can still establish more than a logo.

The most useful security metric is not the number of blocked requests displayed on a dashboard. It is whether controls reduce actual loss without creating unmanageable false positives or hidden exceptions. Track material incidents detected, time to contain, repeat causes, unauthorised changes prevented, restore success, privileged exceptions and customer effort per resolved case. The provider should be able to explain what it monitors and what remains the customer's responsibility, especially for an unmanaged VPS.

Public evidence does not support a verdict that Soltia's controls are ineffective. It also does not support treating feature names as audited outcomes. The correct stance is conditional: the network and policy records show an identifiable operating surface, and the product pages name relevant controls; assurance depends on whether current contracts, configurations, logs and tests connect those controls to the purchased service.

The evidence schedule for a buyer

A compact evidence schedule can resolve most of the uncertainty without turning a hosting purchase into an endless audit. Start with identity. Record Soltia Consulting SL, B86633401, registry sheet M-550986, the current registered and correspondence addresses, the authorised signatory and the precise role of the HostingSoltia name. List any reseller, facility operator or subprocessor that can affect delivery, access, support, security or recovery.

Next bind the product to infrastructure. Name the plan, managed or unmanaged boundary, physical or virtual resource model, performance limits, normal facility, recovery facility and included software licences. Identify which of Madrid I, Madrid II, Toledo or the EXA Madrid label applies. Obtain certification details only for the sites and controls relevant to that plan. Record whether capacity, backup and support claims come from general terms, product conditions or a bespoke schedule.

Build a network sheet. List the assigned addresses and prefixes, normal origin ASN, upstreams relevant to the service, RPKI state, DNS service, mitigation provider and failover route. Explain the role of AS201426 and AS201942. Store a baseline from normal operation and define which changes require notice. Do not demand that public topology expose confidential physical details, but require enough information to test promised diversity and identify shared failure domains.

Build a data sheet. Map customer content, databases, mail, snapshots, backups, logs, tickets, telemetry, billing data and keys. Name the countries and processors used in normal operation, support, incident response, recovery and deletion. State retention and export formats. Confirm whether the provider can access plaintext and what evidence remains after an administrator acts. Attach the current data-processing terms and subprocessor-change mechanism.

Build a recovery and exit sheet. Set recovery points and times by data class, backup independence, restore-test frequency and evidence retention. Define what the advertised failover target covers. Test an isolated restore and a representative export. Document domain and address migration, final access revocation, residual backup expiry and deletion confirmation. The terms' warning that customers should retrieve content before service ends makes this work particularly important.

The commercial choice includes supervision cost

Soltia's public offer is aimed at making Spanish hosting accessible: low-entry shared plans, VPS tiers, familiar panels, rapid deployment, migration assistance and local-language support. For a small business or agency, that combination may remove the need to assemble infrastructure, licences, network resources and round-the-clock operations independently. The visible AS201942 footprint and the real AS201426 record provide more technical substance than a hosting name with no attributable network.

The value still has to be measured against the customer's supervision burden. A low monthly price can be overwhelmed by time spent reconciling a plan with older terms, determining which backup is included, clarifying where data sits, escalating after an acknowledgement or rebuilding an incomplete migration. Those costs rarely appear on the invoice. They appear as engineer hours, delayed releases, compliance review, customer-support work and risk retained by management.

Buyers should compare total operating cost rather than headline capacity. Include licences, management add-ons, backup, restore work, additional addresses, migration, security review, recovery exercises, incident coordination and exit. For an unmanaged VPS, include the customer's patching, hardening, monitoring and on-call labour. For a managed service, verify which of that labour genuinely transfers and how the provider proves completion.

A controlled proof period is often more informative than another sales meeting. Use a representative but non-critical workload. Test provisioning, patch responsibility, a plan change, support outside business hours, route and DNS visibility, backup restoration, event export, billing reconciliation and deletion. Record customer and provider labour. The goal is not to manufacture failure. It is to observe how the service behaves when two systems disagree and a human decision is required.

Renewal should depend on evidence that improves with use. Compare promised and measured support intervals, successful restores, repeat incidents, portal exceptions, unauthorised changes, billing corrections and export quality. Review addresses, contacts, subprocessors, facilities and network dependencies after material change. This is where record consistency becomes a performance metric rather than a documentation preference.

The decision can be framed in three gates. First, can Soltia provide a current, internally consistent identity and contract set? Second, can it bind the proposed service to locations, networks, controls, support and recovery evidence? Third, does measured performance justify price plus the customer's remaining labour and exit risk? A weak answer to the first gate makes the next two hard to score. A strong answer does not guarantee flawless service, but it makes accountability possible.

A measured conclusion

HostingSoltia has a firmer public foundation than its compressed name initially suggests. RIPE uses it for AS201426, links that ASN to Soltia Consulting SL and shows a long-lived assigned record. Live observations found one visible, RPKI-valid IPv4 origin. The larger AS201942 supplies a broader network context, a declared Madrid exchange connection and the route serving Soltia's current website. Spanish official notices and Soltia's own terms establish a legal counterparty.

The public service surface is also substantive. Soltia describes shared, reseller, VPS, dedicated and cloud products; automation through familiar control panels; Spanish facilities; security controls; backup and recovery mechanisms; and Spanish-language support with stated response intervals. These are more useful than vague claims because they can be translated into tests and contract schedules.

What prevents the record from becoming assurance on its own is not the absence of every clue. It is the incomplete alignment among clues. The registered-office notice, current address displays, RIPE record, contract, support page, VPS wording, backup promise and availability claim do not yet read as one versioned service definition. Public route data cannot close those gaps, and no public evidence examined here supplies audited customer outcomes, independent recovery results or staffing performance.

That is a manageable conclusion rather than a negative one. The company can strengthen the case by reconciling public identity and terms, naming the scope of facility and certification claims, publishing the current SLA logic, clarifying backup responsibility, and giving customers exportable operating evidence. A buyer can protect itself by insisting that the executed schedule carries the promises that matter and by testing provisioning, support, restore and exit before dependence grows.

The HostingSoltia name should therefore be treated as an attributable network anchor, not as a shortcut to trust. Its value is that it gives due diligence somewhere concrete to start: a company, two network numbers, a visible route and a Spanish service proposition. Operating assurance begins when those records remain current, agree about the purchased boundary and survive the moment a customer needs a human being to restore service rather than merely describe it.