Summary
- Interhost's cloud is physically concentrated in two Spanish operating locations: a private suite within a carrier-neutral Tier III colocation facility in Madrid and an autonomous data-centre site in Aviles. That supports a credible domestic-hosting proposition, but it does not by itself prove that every customer service is replicated across both locations.
- The company operates AS15919 and, on 12 July 2026, RIPE observations showed six IPv4 announcements, one IPv6 announcement, 18,432 announced IPv4 addresses and complete visibility among the reporting RIS peers. Public routing evidence confirms a live network; it does not establish fibre-path independence, application availability or the quality of each customer contract.
- The decisive risks sit at ownership boundaries. Interhost is responsible for equipment and vendor maintenance in dedicated hosting, while a housing customer remains responsible for its own hardware. Recovery, spare capacity, support response, licensing, backups and migration are separately priced or designed, so usable resilience can be much narrower than the provider's total technical capability.
- Current BSI certification, a public contract entering force in 2025, a recent parent-company case study and live route announcements support an active-operator assessment. The final network evidence grade is Medium because public sources omit rack occupancy, power headroom, hardware-stock levels, tested recovery results and service-by-service topology.
The cloud starts in a room
The most revealing sentence in Interhost's public material is not about elasticity. It is the company's description of its Madrid facility as a private technical room or suite inside a large, carrier-neutral Tier III colocation centre. Its second named location, in Aviles in Asturias, is described as an autonomous data centre. Those details in Interhost's data-centre description turn an abstract cloud proposition into a concrete operating model.
At one end of the model is a customer who sees processors, memory and storage in a portal or on an invoice. At the other are racks drawing power in two Spanish cities, top-of-rack switches, storage arrays, routers, cross-connects, firewalls, backup media and people with permission to enter the room. Between them lies a chain of contracts. Interhost may own a server but lease the room in which it runs. It may operate the autonomous system but buy upstream transit. It may administer an operating system while a customer owns the application. It may offer a remote copy while the customer has not paid for a warm recovery environment.
That chain is the useful way to understand Interhost. The company is neither merely a reseller of anonymous hyperscale capacity nor, on the public evidence, an owner of a vast self-contained estate. It is a Spanish managed-hosting operator that combines its own network and service staff with a mixture of dedicated equipment, shared cloud resources and third-party facility and carrier inputs. Its value comes from assembling those layers for customers that want more attention, domestic location and operational help than a commodity virtual machine normally provides.
Its risk comes from the same assembly: availability depends on where responsibility changes hands.
Interhost's 2022 service catalogue is unusually candid about this. It treats migration, setup, network segmentation, monitoring, backups, disaster recovery and support as distinct services with prerequisites and charging units. This is important. A provider can possess two sites, multiple carriers and remote-copy technology while an individual customer has contracted only one machine in one room. Corporate capability is not the same thing as service entitlement.
The public evidence supports the existence of a real operator. It does not support a precise claim about megawatts, occupied racks, server count or spare capacity. Interhost publishes no current capacity dashboard, no inventory of available bare-metal models and no service-by-service placement map. The responsible conclusion is therefore narrower: Interhost has identifiable Spanish facilities, a live autonomous system, long-standing address resources, current certification and evidence of recent commercial activity. How much usable capacity any buyer receives remains a contract and architecture question.
A subsidiary with a specific job
The legal and ownership structure matters because customers are buying more than compute. SATEC's 2024 non-financial report identifies Servicios de Hosting en Internet, S.A.U., known as Interhost, as a wholly owned subsidiary of SATEC. It gives the company's principal purpose as hosting and housing in the Spanish and Portuguese markets. The parent describes Interhost as the group company responsible for infrastructure hosting and delegated operations, while SATEC supplies a broader systems-integration and consulting capability.
This arrangement can be commercially useful. A customer moving a complex estate may need application knowledge, network design and migration labour as well as rack space. SATEC's current Madrid Chamber of Commerce case study describes private cloud infrastructure, dedicated links, replication to a secondary data centre, managed service and a physical move that was largely uninterrupted except for non-redundant services during transport. The case illustrates what the combined group can assemble.
It also illustrates why buyers should name the accountable party for each layer. The parent may design and migrate; the subsidiary may host and operate; a colocation company may provide the Madrid building; carriers provide circuits; technology vendors provide servers, storage and virtualisation software. A single commercial front does not erase those dependencies. When an incident crosses them, the useful measure is not how many companies are involved but whether one party has authority to coordinate diagnosis, approve replacement, communicate status and restore service.
Current evidence reduces, but does not eliminate, the concern created by Interhost's small public profile. A BSI ISO 9001 certificate is effective from September 2024 to August 2027 and covers information-systems hosting. Its scope page lists workplaces at Avenida de Europa in Aravaca, Calle Albasanz in Madrid and La Curtidora in Aviles. A Spanish public-sector contract notice records Servicios de Hosting en Internet S.A.U. as the successful bidder on a contract entering force on 2 January 2025. Neither record proves the performance of a particular hosted application, but together with current routing they are better evidence of continued operation than an undated marketing page.
The ownership structure also shapes financial risk. A wholly owned specialist subsidiary can draw on the parent group's sales, engineering and purchasing relationships. Yet customers should still understand which legal entity owns their equipment, invoices their service, holds software licences, employs on-call staff and bears service-credit obligations. Parent affiliation is not automatically a guarantee of subsidiary liabilities. The relevant protections belong in the signed agreement.
What the customer is actually buying
Interhost spans several models that are easy to blur together. Its dedicated-hosting page describes physical equipment and software reserved for one customer and sized by Interhost. In that model the company handles configuration, vendor relations and preventive, corrective and evolutionary hardware maintenance, along with basic software such as the operating system. The customer substitutes recurring service charges for an upfront equipment purchase and delegates a significant part of the repair burden.
Dedicated does not mean isolated from every shared component. Interhost itself says dedicated equipment is integrated with shared connectivity, security, data back-end and auxiliary infrastructure. A customer can therefore avoid contention on a server and still depend on shared border routers, firewalls, storage services, power distribution or support staff. The architecture may be well designed; the point is that the word dedicated defines only some layers.
Housing changes the boundary. On Interhost's housing and colocation page, the customer supplies the infrastructure and remains responsible for maintenance and correct sizing. Interhost defines integration requirements and can provide assistance, but the customer's machine is still the customer's problem unless additional management has been purchased. In basic colocation, the provider chiefly supplies rack units or a rack, power, energy and usually connectivity. A failed disk at 02:00 can therefore produce two very different outcomes: automatic action by Interhost under a managed dedicated contract, or a notification that requires the housing customer to authorise work, supply a part or send an engineer.
The cloud offer introduces shared capacity. Interhost's virtual data-centre page lists public cloud, private cloud, managed private cloud, virtual data centres and virtual private clouds. It says a virtual data centre can combine servers, security, storage, communications, administration, monitoring and backup. It also explicitly notes that resources in a shared pool may be assigned to virtual machines with oversubscription.
Oversubscription is not inherently defective. It is one economic foundation of cloud computing: customers rarely consume their maximum processor, memory, storage and network allowances at the same instant, so a provider can sell logical capacity above the continuously usable physical total. The risk appears when too many tenants peak together, when storage latency rises, when a host fails and remaining hosts cannot absorb its load, or when a recovery site lacks the same headroom as production. Buyers need performance objectives and failover assumptions, not merely a nominal count of virtual CPUs.
Private cloud can reduce neighbour contention, but it introduces hardware lifecycle and minimum-commitment questions. Who owns the servers at contract end? How quickly can a failed host be replaced? Is a spare installed, held locally, available from a distributor or ordered after diagnosis? Does a refresh require a new term? Can the customer reduce capacity, or is flexibility mainly upward? Interhost's public pages explain the service categories but do not publish standard answers. Those omissions do not imply weak practice; they mean the economic terms cannot be inferred from the product name.
Managed services are another separate layer. Interhost publishes pages for continuous first-line support, second-line support, remote hands and room assistance, delegated systems administration and monitoring. The menu conveys a crucial fact: detection, triage, diagnosis, physical intervention and operating-system administration can be separate obligations. A 24-hour monitoring claim is not the same as a 24-hour right to change a customer's system.
The service should therefore be read as a bundle. Compute is only one line. The operational product also includes the time to detect a fault, the authority to act, access to parts, access to the room, escalation to carriers and vendors, backup integrity, customer communication and the commercial rules for exceptional work. A low monthly price may reflect a narrow bundle rather than more efficient infrastructure. A higher price may buy staffing and recoverability that remain invisible in a virtual-machine specification.
Madrid, Aviles and the meaning of locality
Interhost's geography is compact enough to be meaningful. The company names Madrid and Aviles as its two operating data-centre locations. Madrid is Spain's largest connectivity and enterprise market; Aviles provides geographic separation in Asturias, hundreds of kilometres to the north-west. For organisations that want data kept in Spain, this can be easier to reason about than a broad cloud region whose customer-facing name masks several facilities and subcontractors.
Locality has at least four dimensions. The first is the resting place of primary data. The second is the location of backups and replicas. The third is where administrators and support systems can access the data. The fourth is the legal chain of processors and suppliers. A Spanish primary server does not prove that every copy stays in Spain, and corporate ownership in Spain does not prove that every support tool or software vendor is domestic. Interhost's two-site description and its Spanish addresses make a domestic design plausible, but each customer must confirm the actual placement and subprocessor terms.
The distinction between facility owner and service operator is particularly important in Madrid. Interhost describes its footprint there as a private suite in a large neutral colocation centre, not as a building wholly owned and operated by Interhost. That model can be a strength. A specialist colocation facility can offer robust power, cooling, physical security and a dense carrier meet-me room. Interhost says its Madrid location has more than 50 carriers available through the facility's meet-me-room service.
But the neutral facility remains a dependency. Interhost can control its racks, switching and service configuration while relying on the landlord for utility feeds, generators, cooling plant, access rules, shared security and cross-connect delivery. Maintenance may require coordination across both organisations. A facility-level incident can affect several providers at once. A carrier-rich building does not help a customer whose two circuits share a duct outside it, terminate on one device, or were never ordered in the first place.
Aviles is described as autonomous, which suggests a different facility boundary. Public materials do not disclose its current power rating, cooling design, occupancy, carrier list or whether it has the same spare hardware and staff coverage as Madrid. BSI's certificate lists hosting activities at La Curtidora in Aviles, and SATEC lists an office there. Those facts support an operating presence, but a workplace address and a service claim are not a substitute for an engineering schedule.
The separation between Madrid and Aviles is valuable only when the service architecture uses it. A backup copied overnight to Asturias is protection against loss of the Madrid copy, but it does not create an application that can restart immediately. A replica without licensed compute, network routes, security rules, current credentials and a tested runbook can still take hours or days to activate. An active-active design may recover faster but costs more, can be difficult for stateful applications and may expose both sites to a bad deployment or compromised administrator.
Customers also need to distinguish data sovereignty from operational concentration. Keeping production and recovery in Spain can simplify jurisdiction and latency for Spanish users. It does not remove common dependencies on Interhost personnel, management systems, identity services, virtualisation software, backup products or a parent-group support function. Two buildings do not provide independence if the same mistaken change, expired licence or compromised account can disable both.
AS15919 is visible, but visibility is not resilience
Interhost operates its own autonomous system, AS15919. That is a meaningful capability for a provider of hosted services. It allows the company to originate address space, apply routing policy and connect to more than one upstream rather than placing all public reachability behind a single access provider. Interhost's IP transit description says it uses its own address ranges and autonomous system, multiple transit providers, high-capacity BGP routers and two fibre entrances for carrier access at each data centre. It also says local providers normally carry traffic while remote providers can be used after a failure.
Current third-party observations support the basic claim that this is a live routed network. RIPEstat's AS overview for AS15919 marked it announced on 12 July 2026. Its routing-status record showed 18,432 announced IPv4 addresses across six observed IPv4 prefixes, one IPv6 announcement containing 65,536 /48 units, and visibility from all 326 reporting IPv4 RIS peers and all 322 reporting IPv6 peers. The announced-prefix record included 217.75.224.0/19, 79.171.104.0/21, three more-specific 213.134 blocks, the covering 213.134.32.0/19 and 2001:b90::/32.
The observations also show a smaller live edge than the long list of import policies in the registry might suggest. RIPEstat's neighbour observation found four unique adjacent autonomous systems on the measurement date: AS174, AS286, AS3257 and AS16091. The RIPE routing entity lists additional policies, but registry policy is declared intent and may outlive, precede or differ from observed routing. Neither source reveals the physical route taken by each circuit.
This is enough to say Interhost is not presenting a purely nominal network identity. The address space is globally visible, IPv6 is present and multiple neighbours are observed. It is not enough to calculate application uptime. BGP can route perfectly to a firewall behind which a storage array has failed. Two upstreams can share a conduit. A broad aggregate and several more-specific announcements can all originate from the same router. Complete visibility from route collectors means the routes are seen, not that packets meet a latency or loss objective.
Route security is another open question. RIPEstat's RPKI checks for sampled Interhost prefixes returned an unknown state because no validating route-origin authorisation was found in those queries. That does not mean the routes were hijacked or invalid; it means the sampled origin announcements did not receive the protection of a matching visible ROA at the time checked. For a hosting network, publication of valid ROAs and documented filtering practices would strengthen the external evidence.
Customers buying private circuits face a separate topology. Interhost's VPN and circuit page explains that private point-to-point lines, carrier MPLS services and out-of-band access can be provisioned, using the Madrid facility's interconnection room. These links may be more relevant to an enterprise application than public Internet transit. Their resilience depends on ordered paths, handoff equipment and the customer's own site. A dual-carrier design can still fail at a single customer router or building entrance.
The practical due-diligence request is a service-specific diagram under confidentiality: production rack or cluster, recovery site, border devices, carriers, physical entrances, cross-connects, private circuits, address advertisements, firewalls and management access. It should distinguish provider-wide capability from components assigned to the contract. Public BGP evidence is a useful cross-check, not the architecture itself.
Installed capacity is not usable capacity
Hosting economics are governed by the difference between what is installed and what can safely be promised. A rack may contain servers whose processors are mostly idle, yet have no power headroom for another dense chassis. A storage array may have free terabytes but limited public evidence input-output performance during backup or rebuild. A cluster may run comfortably in normal conditions but saturate after losing one host. A recovery site may hold copies without enough licensed compute to run every protected customer at once.
Interhost's public material offers no current utilisation figures, which is normal for a private operator but limits external assessment. There is no published measure of rack count, sellable kilowatts, reserved failover headroom, storage latency, hardware age or unallocated recovery capacity. Claims of scalability should therefore be interpreted as a design and procurement capability, not proof of immediate supply at every size.
Its own energy-efficiency paper recognises that data centres depend on electrical distribution and environmental control and that electricity is a major cost. The paper is a general discussion rather than a facility audit. Still, it points to an unavoidable commercial mechanism. Higher electricity and colocation prices eventually reach customers through tariffs, renewals, power bands or restrictions on dense equipment. A provider can absorb volatility for a time, but not repeal it.
Dedicated hosting adds the cost of inventory. If Interhost promises to maintain customer-specific hardware, it must choose between installed redundancy, local spares, distributor agreements and replacement lead times. Each choice has a price. Keeping a compatible server or controller idle shortens repair time but depresses utilisation. Relying on vendor dispatch is cheaper until a part is scarce. Public pages say Interhost manages vendor relations; they do not disclose standard spare-part commitments.
Shared cloud shifts the equation from individual parts to pool headroom. Interhost explicitly allows oversubscription in a virtual data centre. Buyers should ask how processor, memory and storage commitments are controlled; what happens during maintenance; and whether the remaining cluster can carry contracted loads after a host failure. A useful assurance is not that a platform is redundant in the abstract but that the provider models and tests the relevant failure while preserving performance objectives.
Recovery capacity creates a difficult allocation problem. If Aviles protects several Madrid customers, is capacity reserved per customer, pooled on the assumption that failures are isolated, or purchased after a regional event? Pooling can be rational because many incidents affect one customer rather than an entire city. It is weaker against a large facility outage, exactly when many customers may invoke recovery simultaneously. The contract should state whether recovery resources are dedicated, guaranteed, prioritised or best-effort.
Software licences can be as constraining as hardware. Virtualisation platforms, databases, backup agents, security appliances and operating systems may require secondary-site rights. A technically complete replica may not be legally or operationally ready to run. Interhost's catalogue says disaster-recovery pricing reflects resources, RPO, RTO, replication or failover licences and testing frequency. That is evidence of a tailored service, but it also means recoverability cannot be assumed from the presence of a backup line item.
Support labour is another capacity pool. Interhost's pages distinguish first-line response, expert second-line response, hands in the room and delegated administration. In a broad incident, alerts arrive together. Staffing that handles ordinary ticket volume may face a queue when power, storage or a carrier failure affects many systems. Buyers need priority definitions, escalation times and communication obligations for major incidents, not only a general statement that support is continuous.
Recovery is a designed service, not a second address
Interhost's strongest resilience proposition is the ability to combine Madrid and Aviles. Its disaster-recovery paper says the company has two operational data centres and presents three broad arrangements: an Interhost site as backup for a customer's own primary site; one Interhost site as primary and the other as secondary; or disaster recovery in Interhost's public cloud, with backups and replicas stored there. It mentions private inter-site connectivity, similar infrastructure at the recovery location and multiple replication techniques.
The company's backup page and continuity page go further. They describe file-level agents for physical servers, image-level backup for virtual machines, bare-metal recovery, remote vaulting and replication between Madrid and Aviles. The continuity page says backup copies are replicated between the two sites as a standard practice.
These are credible building blocks. None guarantees recovery without a customer-specific design. Recovery point objective determines how much recent data may be lost. Recovery time objective determines how long restoration may take. A nightly copy can be healthy and still lose a day's transactions. A near-real-time replica reduces that gap but can reproduce corruption, encryption or operator error. Synchronous replication can approach zero data loss but adds latency sensitivity and does not protect against every logical failure.
Restoration also has an order. Identity, network, security rules, storage, databases, middleware and applications may need to return in sequence. External DNS, certificates, payment providers or customer offices can remain unavailable after the servers start. A disaster plan that covers only virtual machines may miss the operating context that makes them useful.
Testing frequency matters because dormant recovery arrangements decay. Credentials expire, applications change, firewall rules diverge, backup agents fail quietly and staff move roles. Interhost's catalogue recognises test frequency as a pricing component. That should focus a buyer's attention: a cheaper plan tested rarely is a different product from a plan exercised quarterly with measured results and corrective actions.
The recent Madrid Chamber case study is useful but should be read at the right level. It reports real-time replication of primary machines to a secondary data centre and says recovery was made faster. It does not publish measured RPO, measured RTO, test dates, failover duration or application-level acceptance criteria. As a provider-authored case study, it demonstrates a claimed implementation, not independent performance verification.
A buyer should demand evidence from the service it will receive: the date of the latest restore test, the amount restored, the elapsed time, the point in time reached, any failed components and the remediation. For a two-site service, it should include a loss-of-primary exercise rather than a restoration inside the same cluster. Sensitive details can remain confidential; aggregate proof can still show whether the design has been used.
Seven ways the service can fail
The first failure path is the rack or facility. Loss of a power feed, cooling fault, fire-suppression event, access-control problem or maintenance error can stop equipment even when the server itself is healthy. Madrid's carrier-neutral Tier III setting and the redundancy features claimed by Interhost are positive signals. Yet the public record does not identify the facility, its current certification, the exact power paths to Interhost's suite or incident history. Aviles is even less described. Customers should verify which facility obligations are passed through and whether maintenance exclusions erode the service objective.
The second is upstream connectivity. AS15919 is live and multihomed, but route diversity and physical diversity are not identical. Failure can occur at an upstream, a cross-connect, a router, a shared fibre duct, a route leak, a denial-of-service event or a customer's private circuit. Interhost's claim of dual fibre access at each site is valuable if the paths are truly separate. Contract drawings and carrier letters should establish that point.
The third is hardware stock. Dedicated infrastructure concentrates performance but ties recovery to compatible parts and vendor response. A failed disk may be routine; a failed controller, motherboard or end-of-life appliance may not be. Where the customer owns housing equipment, responsibility can become ambiguous during diagnosis. The agreement should define who holds spares, who can break seals, how data-bearing parts are handled and when replacement time starts.
The fourth is support. Monitoring can detect a symptom while no one has authority to reboot, replace or fail over. First-line staff can open a ticket but wait for a specialist. A specialist can diagnose a storage issue but wait for the customer, facility or vendor. These handoffs shape outage duration. Interhost's separate support services make the boundary visible; customers must ensure their bundle closes the gaps.
The fifth is billing and contract status. Hosted services can be disrupted by expired licences, disputed invoices, exhausted prepaid resources or a renewal that changes price and scope. Interhost's service-level page says agreements can define availability, capacity, continuity, incident handling, measurement, penalties and termination. That is the right frame. The actual protection depends on grace periods, notice, cure rights, data access during a dispute and the size of service credits relative to harm.
The sixth is migration. A new environment can fail during data copy, address change, DNS cutover, application testing or the physical transport of non-redundant equipment. The Chamber case study explicitly notes that non-redundant services experienced the time needed for physical transfer. That is refreshingly concrete: even a successful migration has a physical critical path when a machine exists in only one place.
The seventh is provider-contract failure. Interhost may perform well technically while a facility lease, carrier agreement, software licence or vendor support arrangement changes. The customer sees Interhost; Interhost must manage the supplier beneath it. Portability terms should cover access to data and equipment if the commercial relationship ends, not only if a server fails.
These paths interact. A power incident may expose a failed battery, which leads to an unclean shutdown, which corrupts storage, which requires a restore, which waits for application credentials. An upstream outage may be extended by a stale route policy. A provider dispute may block the very staff needed for migration. Resilience is the ability to handle sequences, not a collection of component claims.
Who is affected when the system stops
Interhost's historical references and parent-company case studies place it in the part of the market where outages can become public-service or business-continuity problems. The company's own archive describes work connected with public websites, universities, museums, judicial infrastructure, insurers and transport-ticketing services. Older announcements are not proof that every named customer remains hosted today, but they show the kind of workloads the operator has pursued.
The current Madrid Chamber case study describes a private cloud, secondary replication and high-speed links for an institution whose digital services connect businesses, staff and physical offices. SATEC's current Servicios Funerarios de Madrid case study describes dedicated infrastructure hosted and managed by Interhost, plus migration, monitoring, support and disaster recovery. Provider-authored success stories naturally emphasise positive outcomes, yet they illuminate the affected groups: employees, residents, businesses, partners and development teams can all depend on the same hosted estate.
For a public website, downtime blocks information and transactions. For an internal application, employees may lose access to case files or scheduling. For a ticketing platform, revenue and journeys are affected. For a database-backed service, an apparently brief outage can leave reconciliation work after restoration. The effect therefore depends on application state, not only minutes offline.
Concentration can increase the blast radius. A customer that places compute, backups, network access, monitoring and administration with one provider gains simpler accountability but reduces supplier diversity. Several customers sharing the same cloud cluster, storage system or carrier edge can fail together. Interhost's small scale may allow personal response, but it can also make specialist staffing and spare capacity more concentrated than at a large provider. Public sources do not quantify either effect.
The right mitigation is not necessarily to avoid concentration. Splitting responsibility across vendors can create slower diagnosis and incompatible objectives. The useful question is whether the chosen concentration is visible and compensated: a second site, independent backups, exportable configurations, customer-held credentials, tested restoration and clear incident leadership.
Portability is the final redundancy
A recovery site protects against a location failure. Portability protects against a provider relationship that no longer works. For dedicated hosting, exit can require data export, configuration records, software licence transfer and sometimes the physical movement or purchase of equipment. For housing, the customer may already own the machine but still needs room access, carrier changes and a safe removal window. For shared cloud, the data may be portable while network and security constructs require rebuilding elsewhere.
Interhost's catalogue acknowledges setup and migration as project work agreed with the customer. That is realistic. Moving a live system is labour-intensive and often carries one-off charges. The risk is leaving exit design until the end, when time is short and technical knowledge has atrophied.
A sound contract should identify data formats, export bandwidth, assistance rates, deletion timing, backup retention, equipment ownership, licence rights and the service period after termination notice. It should say whether service credits or disputes suspend exit assistance. It should also establish who owns automation, diagrams and configuration created during managed administration.
Network portability deserves separate attention. A customer using Interhost-assigned addresses may need to renumber when moving. DNS time-to-live can be reduced before migration, but external allowlists, certificates and partner configurations may still embed old addresses. A customer with portable provider-independent space has more control but assumes routing responsibilities. Neither option is free.
Backups should include a copy beyond the same administrative domain when the workload justifies it. Interhost's two-site replication can protect well against a site incident. It is less independent against a provider-wide account compromise, legal dispute or destructive administrative action. An encrypted customer-controlled copy, regularly restored elsewhere, changes that risk. It may cost more and complicate key management, but it is genuine option value.
Portability also disciplines pricing. A customer that can move within a known period has leverage at renewal. A customer whose application depends on undocumented private arrangements may accept increases because exit is too risky. Interhost's managed attention can create real operational value; the economic question is whether that value is accompanied by informed choice or by avoidable lock-in.
What the evidence establishes, and what it does not
Interhost's public footprint is thin compared with the largest cloud companies, but it is not empty. Several independent or externally verifiable signals line up. SATEC's audited 2024 report identifies the subsidiary and ownership. BSI's certificate extends into 2027 and covers hosting activity at three workplaces. A government contract entered force in 2025. The parent has recently published case studies naming Interhost infrastructure. RIPE saw AS15919 announced with full collector visibility on the observation date. The company's domain and long-held address resources connect the historical brand to the current network.
Those signals establish legal continuity, current network presence and plausible ongoing service activity. They do not establish revenue, profitability, customer count, staffing by shift, facility ownership, power capacity, occupancy, spare inventory, incident record or fulfilment of a particular service objective. LinkedIn's company page labels Interhost as an 11-50 employee company and lists Madrid, Barcelona and Aviles locations, but this is a company-maintained social profile and not an audited headcount.
Marketing statements need similar calibration. The claim of a neutral Tier III Madrid facility is specific and plausible; the facility is not named on the page, so its certificate and current status cannot be matched publicly. The claim of more than 50 carriers describes availability in the facility, not the number Interhost buys. The claim of two fibre entrances does not show their street paths. The claim of replicated backups does not show a customer's last successful restore.
Unofficial network services can provide corroboration. IPinfo's AS15919 page associates 18,432 IPv4 addresses and a large IPv6 allocation with the Spanish hosting network, matching RIPE's observed IPv4 total. Hurricane Electric's AS-set view shows a maintained AS-INTERHOST registry entity. These services suggest consistency across public routing datasets. They cannot prove facility placement, commercial ownership of every component or application performance. Direct provider records, contracts and measured tests would settle those questions.
The evidence grade should therefore be Medium. It is stronger than a directory entry inferred from an address block: there is current routing, certification, ownership disclosure and recent commercial evidence. It is weaker than an operator that publishes named facilities, live status history, detailed peering, audited capacity, sustainability metrics and tested service outcomes. Medium is not a verdict on service quality. It is a measure of what an external reader can verify.
The questions that turn capacity into a service
For a prospective customer, the decisive questions are specific. Which site will hold production, backups and recovery? Is the Madrid service in Interhost's own suite, and which facility operator supplies power and cooling? Which parts of Aviles are equivalent to Madrid and which are not? Are recovery resources reserved or pooled? What were the measured results of the latest full restore and site-loss test?
Network questions should name physical and logical paths. Which autonomous systems carry the service today? Do dual circuits use separate entrances, ducts, line cards and customer-premises devices? Which prefixes have valid route-origin authorisations? How does Interhost mitigate denial-of-service traffic? Can private circuits fail over to encrypted Internet connectivity, and has that mode been tested at useful throughput?
Hardware questions should identify the repair clock. Which components are installed redundantly? Which spares are on site? What is the maximum vendor dispatch time? Who replaces customer-owned housing equipment? How are failed drives erased, retained or returned? What happens when a product reaches end of support?
Operational questions should map detection to authority. Which team watches the service, which team may change it, and who leads a severe incident? What response and restoration targets apply by severity? How often are customers updated? Are planned maintenance windows capped, announced and excluded from availability calculations? Can one emergency change affect both sites?
Commercial questions should expose the usable bundle. Which support levels, backup retention, replication licences, test exercises and migration hours are included? How are electricity, colocation and licence increases passed through? Is there a minimum term? What happens to service and data during a billing dispute? Are penalties meaningful, and do they increase after repeated breaches?
Exit questions should be agreed while relations are good. Can the customer obtain virtual-machine images, database backups, firewall rules, diagrams and logs in standard formats? At what speed and price? Who owns dedicated equipment? How long will Interhost retain and then erase copies? Can an independent backup be restored outside Interhost without proprietary dependencies?
Answers to those questions can reveal a robust service even where public disclosure is sparse. They can also expose a low-cost configuration that relies on one site, best-effort recovery and slow replacement. The provider's catalogue shows that Interhost understands many of these distinctions. The customer's job is to make sure the signed service includes the desired version.
A local cloud with physical terms
Interhost occupies a useful niche. It offers Spanish hosting, cloud, connectivity and operational support with the intimacy of a specialist and the broader engineering reach of SATEC. Its own autonomous system is visible. Its two-site design can support genuine geographic recovery. Its service catalogue is more honest than the effortless-cloud language common in the market because it shows how many separate pieces must be designed and paid for.
The same evidence prevents a romantic conclusion. Madrid depends on a colocation facility. Internet reach depends on upstream networks and physical cross-connects. Dedicated service depends on spare parts and vendor terms. Shared cloud depends on headroom. Recovery depends on licences, replication, reserved capacity and testing. Support depends on the right person being available and authorised. Migration depends on time, documentation and customer cooperation.
Interhost is therefore best understood not as a place where physical constraints disappear, but as a company paid to manage them. That can be valuable. Many customers do not want to buy servers, negotiate carriers, staff a room around the clock or design remote recovery. Delegation converts those burdens into a service relationship. It does not remove the burdens from the system.
The public record supports continued operation and a credible technical base, while leaving major capacity and performance questions private. A buyer should give weight to the current BSI scope, recent contract evidence, live AS15919 announcements and the specificity of the two-site material. It should give equal weight to the missing numbers and demand them at service level. The real product is not the virtual machine displayed on an order form. It is the tested ability of racks, routes, people and contracts to keep that machine useful when one of them fails.