Summary
- Tuxis is best understood as a Dutch infrastructure specialist whose margin is earned after a customer has moved: the account depends on fewer migrations, credible backup and restore mechanics, direct support, Dutch or European data-location claims and enough network evidence to make those promises inspectable.
- Public evidence supports a real operating footprint: Tuxis B.V. lists its Ede address and Dutch registration, PeeringDB records AS197731 as Tuxis with AMS-IX, Frys-IX and Speed-IX peering and facilities in Ede, Schiphol Rijk and Amsterdam, while routing databases show originated IPv4 and IPv6 prefixes, upstreams and many peers.
- The judgment is constrained by private data gaps. Public sources do not reveal revenue, churn, gross margin, customer concentration, incident history, actual restore performance or audited facility-level uptime; those missing facts are central because Tuxis sells operational trust rather than commodity compute alone.
The decision comes after the first server is already running
The easiest sale in hosting is the first small server. The harder, more valuable sale comes a year later, when a customer has learned what it really costs to run the workload. A business that moved a database, a line-of-business application, a web platform or a managed customer environment into a cloud account no longer compares providers by the neat arithmetic of vCPU, memory and storage alone. It compares them by the cost of another migration, the chance that a restore will work, the amount of human help available during a failure, the clarity of the invoice, the location of the data, and the difficulty of explaining to a board why a cheaper platform became more expensive in practice.
That is the useful frame for Tuxis. Its public copy presents a familiar bundle: virtual private servers, dedicated Proxmox servers, private cloud, edge cloud, colocation, domain names, web hosting, SSL certificates, storage and backup services. In a market full of such menus, the words themselves do not prove much. The economics are in the mechanism. Tuxis is trying to be the provider that a Dutch or European organisation keeps after the migration has been done because leaving would reopen operational risk. That does not make it immune to competition. It makes the competitive test more specific. Tuxis has to be good enough at migration support, backup architecture, upstream connectivity, invoice predictability and local assurance that a customer sees less risk in staying than in shopping for a lower monthly price.
That position is different from the commodity VPS game. A budget virtual-server provider competes on visible price and self-service speed. A hyperscale cloud competes on product depth, global scale, procurement familiarity and ecosystem gravity. A local managed service provider competes on proximity and broad IT outsourcing. Tuxis sits between those categories. It presents itself as an infrastructure operator with a Dutch base, a Proxmox and Ceph orientation, a public network identity and an emphasis on data remaining in Dutch or European locations. The promise is not infinite scale. The promise is that, for the kind of customer that wants a virtual datacenter, a managed Proxmox estate, backup storage or colocation with a direct line to engineers, a focused Dutch provider can reduce practical uncertainty.
That is why the most revealing customer moment is not the sign-up form. It is the restore, renewal or migration decision. If a customer is moving from VMware, Hyper-V, Nutanix, a pile of self-managed servers, a managed WordPress stack or a hyperscale account, the quoted monthly price is only the first cost. The customer also pays in time, project risk, staff distraction and the fear that some obscure dependency will break during the move. If the new platform then performs reliably, produces usable backups, offers direct support and does not surprise the customer with opaque charges, the account becomes stickier. If those things fail, the same migration friction becomes a liability for Tuxis: the provider will be blamed not just for downtime, but for making the customer relive the move.
The public evidence therefore has to be read in two layers. One layer is what Tuxis says about its services: data in three Dutch data centres, daily encrypted backups on VPS plans, Proxmox Backup Server storage, colocation across multiple locations, 24-hour monitoring for managed services, open peering and transparent policies. The second layer is what external infrastructure databases show: AS197731, public peering at several exchanges, listed facilities, originated prefixes, upstreams and a long peer table. The first layer explains the commercial pitch. The second gives outsiders some way to inspect whether the company has a network presence consistent with that pitch.
Neither layer is enough by itself. Marketing pages cannot prove restore quality. Peering records cannot prove support quality. A public route table cannot show churn. Customer testimonials chosen by the company cannot substitute for an independent account-level reliability dataset. But together they allow a reasoned view of Tuxis as a small-to-mid-market infrastructure company whose value lies in the paid reduction of operational anxiety. The company matters where hosting is not an experiment, but a continuity decision.
Identity: a Dutch infrastructure company with an engineering story
Tuxis identifies itself publicly as Tuxis B.V., located at Darwinstraat 29D, 6718 XR, Ede, in the Netherlands. Its contact page lists Dutch Chamber of Commerce number 74698818, VAT number NL859996657B01, phone number +31 318 200 208, office opening hours on weekdays and 24-hour on-call support. That matters because many low-cost hosting brands reveal little beyond a shopping cart. Tuxis presents a responsible operating company, an address, tax and registry details, support routes and abuse contacts. For a customer that handles regulated, professional or client data, such boring administrative facts are part of the product.
The company’s own history is tied to Mark Schouten, identified on its site as CEO and as the person who started Tuxis Internet Engineering in 2010. The emphasis in that account is revealing. It is not written as a venture-scale cloud story. It is framed as an engineering response to a perceived gap: versatile but professional infrastructure, use of open-source tools, privacy, scalability and reliability. Tuxis highlights contributions or involvement around technologies such as Proxmox, PowerDNS and LibreNMS, and presents open-source competence as part of its cost and trust proposition.
That identity shapes the commercial pitch. A company that sells largely on hyperscale breadth wants customers to believe that no use case will outgrow it. A company that sells on low-cost VPS volume wants customers to believe that price and instant provisioning are enough. Tuxis sells a narrower story: infrastructure under its own management, a Dutch or European data-sovereignty angle, software-defined architecture, and engineers who can discuss Proxmox, Ceph, backup and networking without hiding behind a generic support queue. The most attractive buyer is likely to be an SME, software firm, IT service provider, healthcare-adjacent operator, education organisation or technology team that wants more control than SaaS and less burden than self-owning the entire stack.
The word “sovereign” is overused in European cloud marketing, but in Tuxis’s case the claim is part of a more concrete operating posture. Its site describes a “100% European Cloud” and, in Dutch pages, a “100% Nederlandse Cloud.” It says VPS data is written in three Dutch data centres and says daDup storage is kept in Dutch-owned data centres in the Netherlands. Its sensible-use policy says that unless otherwise stated, data is on equipment owned by Tuxis, data is exchanged internally across infrastructure managed by Tuxis, equipment is in Security Class 2 data centres, and data is stored in the Netherlands by default, with Germany available if chosen. These are not the same as an audited guarantee of all subprocessor behaviour, but they are sharper than a vague promise that data is somewhere in Europe.
The company also publishes unusually extensive policy material. Its policies page says Tuxis is ISO 27001:2022 certified and then goes beyond the badge by publishing acceptable use, abuse, coordinated vulnerability disclosure, peering and operating policies. The tone is almost argumentative: Tuxis says customers should not merely ask for a stamp on unknown policies, but ask for the policies themselves. That is a useful signal because infrastructure trust is mostly procedural. When things go wrong, customers need to know who can act, how abuse is handled, what disclosure process exists, how passwords and access are governed, and what commitments are merely aspirations.
There is still an evidence limit. Public policy text does not prove daily operational discipline. ISO certification, if current and scoped as represented, gives stronger assurance than an unaudited claim, but outsiders still need to know the certificate scope, audit body, exclusions, nonconformities and renewal status before treating it as a full answer. The article’s judgment should therefore be careful: Tuxis has done more than many small hosts to expose identity, policy and network posture, but the strongest evidence remains outside public view.
Product ladder: from VPS to private cloud to backup and colocation
Tuxis’s business model is built around an infrastructure ladder. At the lower end is a virtual private server that starts from a modest monthly price, with customer-selected CPU, memory and SSD storage rather than fixed bundles. The VPS page says customers can scale resources, use private networks, take snapshots, view load, use console access, get IPv4 and IPv6 and add an SLA. It says data is saved in real time in three data centres, standard backup is included, and extra backup can raise frequency and retention.
The next step is the Dedicated Proxmox Server. This is not simply a bigger VPS. Tuxis describes it as a complete platform for enterprise virtualisation with a web portal to manage virtual machines, containers, software-defined storage, networking and high-availability clustering. The economic difference is important. In a shared VPS account the provider sells slices of common capacity. In a dedicated Proxmox account the customer buys more isolation and configuration freedom, while still paying Tuxis for infrastructure, support and management options. Tuxis stresses that the customer does not share cloud infrastructure with other customers and that SSD or NVMe storage can deliver performance.
The most strategic product is Tuxis Corporate Cloud, or TCC, including TCC Edge. Tuxis presents TCC as a private cloud or virtual datacenter with data saved in three Dutch data centres, scalable storage and fixed monthly costs. The Edge variant extends that model to a location chosen by the customer, described as a fully managed virtual datacenter with the same functionality as TCC but at the customer’s preferred location. This is a stronger account-locking proposition than a VPS because it sits inside a customer’s architecture. A virtual datacenter becomes a place where network design, backup policy, access controls, application placement, migration projects and support routines accumulate.
Tuxis also sells colocation. Its colocation page says Tuxis has its own ring linking three data centres and that customers can spread services and servers across three locations. It includes a 1 Gbit/s switch port, network and power statistics, self-managed reverse DNS and 24-hour support, with pricing based on rack units, power and traffic. Colocation is strategically useful even if it is not the company’s highest-margin service. It lets Tuxis serve customers that still own hardware, bridge old and new infrastructure, and make migrations less binary. A customer can colocate equipment, connect it to Tuxis cloud services, then move workloads over time instead of gambling on a single cutover.
The backup and storage layer is just as important. Tuxis sells daDup bulk storage, accessible via SMB, S3, FTPS and SFTP, and positions it for backup and disaster-recovery use cases with software such as Veeam, Acronis, Synology NAS, DirectAdmin, cPanel, Nextcloud, OwnCloud, SyncBackPro, Akeeba and Duplicati. It also sells Proxmox Backup Server as a cloud service, with variants for standard backup, synchronization, tape and flash. The PBS page says backups can be encrypted before leaving the Proxmox server with AES-256 GCM, managed through a portal, restored to a new VPS with one click and expanded in 1 TB steps. The public price stated for one PBS account is EUR 21 per TB per month all-in, with no traffic, licence or schedule charges, calculated on peak monthly stored terabytes and rounded to a whole TB.
That is the economics of trust in miniature. Compute attracts attention, but backup and restore determine whether a customer believes the platform. A cloud account without a credible restore path is just a rented failure domain. If Tuxis can persuade customers that off-site backup, PBS sync, triplicate storage and engineer-led recovery are practical rather than cosmetic, it can defend margin against cheaper servers. If customers cannot verify restore performance, the product becomes another promise in a market full of promises.
The ladder also lets Tuxis cross-sell. A customer may start with a VPS, add extra backup, use private networks, then move to a Dedicated Proxmox Server or TCC. A managed service provider can use daDup or PBS for customer backups. A software firm can colocate a legacy appliance while running new workloads in Tuxis cloud capacity. A private-cloud customer can add support contracts, monitoring, subscriptions and consulting. Revenue then depends less on one product line and more on account depth.
The danger is complexity. Each product adds operational obligations: support scope, backup retention, monitoring rules, data-location promises, capacity planning, incident response, and customer education. A small infrastructure company can win trust by being specific; it can lose trust if specificity turns into too many semi-custom promises. Tuxis’s menu is coherent because most offerings orbit Proxmox, Ceph, storage, colocation and network engineering. The question is whether its internal systems scale with that menu.
Pricing logic: the visible price is only a small part of the bill
Tuxis’s public prices tell a partial story. A VPS starts at EUR 13 per month. Proxmox Backup Server is advertised at EUR 21 per TB per month all-in for a standard account. Colocation is priced by rack unit, consumed power and data traffic. The terms and conditions say hosting, colocation subscriptions and related internet-service agreements are invoiced monthly, while domain names are invoiced yearly in advance. The public pages repeatedly emphasize fixed monthly costs, no surprise bills and short or flexible contracts.
Those claims are commercially useful because many infrastructure buyers have been trained by hyperscale platforms to fear variable bills. In a hyperscale account, storage operations, egress, snapshots, backups, managed database options and monitoring can change the cost curve after deployment. Tuxis appears to compete by narrowing the number of variables. For example, the PBS price says it does not charge separately for data traffic, recovery actions, logins or schedules. Colocation still has usage variables, but the variables are familiar: rack space, power and traffic. TCC and Dedicated Proxmox Server copy presents fixed monthly costs and a virtual datacenter rather than a long list of metered services.
The price is not merely a discount mechanism. It is a risk allocation mechanism. When Tuxis offers a fixed amount for managed capacity, it accepts some burden of capacity planning, support staffing, automation, spares, power and upstream networking. The customer pays a premium over a bare self-service server in return for fewer unknowns. That is why Tuxis can be cheap and expensive at the same time. It can be cheap compared with a fully loaded VMware, Nutanix or hyperscale architecture for a steady workload. It can be expensive compared with a bargain VPS. The relevant comparison is not the price per CPU core; it is the price of not rebuilding the operating model.
Migration friction reinforces that logic. Once a customer has moved an application onto a Tuxis virtual datacenter, stored backups in daDup or PBS, built private networks and learned the support process, switching away has a cost. Tuxis can earn attractive account economics if it keeps customers satisfied enough that switching looks irrational. The company’s recurring revenue is therefore not only a function of new logo wins. It is a function of avoided churn.
That can be a strong position in infrastructure because the buyer is often conservative. A software company that hosts production systems, a media company that publishes continuously, a healthcare IT provider managing client environments or a local MSP serving many smaller accounts may care more about recoverability and fast support than saving a small percentage on monthly compute. Tuxis’s customer testimonials, while self-selected, repeatedly point toward stability, response time, uptime, design help and lower cost compared with more familiar enterprise stacks.
But pricing trust has its own constraints. If the gap between Tuxis and substitutes becomes too large, customers will re-open the migration question. If a customer’s workload becomes cloud-native, a hyperscale provider’s managed databases, queues, analytics, security services and global regions may outweigh Tuxis’s local assurance. If a customer’s workload becomes simple, managed SaaS may remove the need for infrastructure at all. If a customer has strong internal engineers, self-managed Proxmox, Hetzner, OVHcloud, Leaseweb, local colocation or another Dutch provider may look cheaper. Tuxis must keep the account complex enough to need trust, but not so complex that the customer decides to buy a larger platform.
The visible pricing also omits the most important private metrics. Public sources do not show average revenue per account, gross margin by product, support cost per customer, restore-ticket volume, churn, renewal discounting, power-cost hedging, hardware depreciation, spare-capacity buffers or bad-debt exposure. Those data would change the assessment materially. A provider can sell stable infrastructure at a good price and still suffer if support work is underpriced, if power costs rise faster than contracts allow, if backup storage grows without enough margin, or if a few large customers dominate utilisation.
The evidence therefore supports a thesis, not a valuation. Tuxis sells predictable infrastructure economics to customers. Whether Tuxis itself enjoys predictable economics depends on data that is mostly private.
Network and resource evidence: enough footprint to inspect, not enough to infer scale
The strongest non-marketing evidence for Tuxis is its public network footprint. PeeringDB records AS197731 as Tuxis, operated by Tuxis B.V., with aliases including AS-TUXIS, AS-TUXIS6 and The Internet Engineering Group. It describes the network as content, with a European geographic scope, traffic levels in the 100-1000 Mbps band, mostly outbound traffic, support for IPv4 and IPv6, and an open peering policy with no ratio or contract requirement. It lists public peering at AMS-IX, Frys-IX and Speed-IX, each with 10G capacity, and interconnection facilities at BIT-1 and BIT-2 in Ede, maincubes AMS01 in Schiphol Rijk and NIKHEF Amsterdam.
That footprint matters for three reasons. First, it makes Tuxis less opaque than a reseller that hides behind another network. An autonomous-system record, exchange ports and facility listings give customers, peers and researchers a way to inspect part of the operating surface. Second, it supports the company’s claim that it is an infrastructure operator rather than only a front-end brand. Third, it helps explain the service proposition: if a provider promises Dutch data-location, colocation, cloud connectivity and backup replication, public peering and facility presence are relevant evidence.
BGP data adds detail. bgp.tools identifies AS197731 as The Internet Engineering Group B.V., registered in April 2011 under RIPE, active and allocated. It lists the network type as content, originated prefixes including IPv4 blocks such as 31.3.104.0/21 and 185.119.28.0/22 and IPv6 blocks including 2a03:7900::/32. It reports nine originated IPv4 prefixes, three IPv6 prefixes, 27 /24-equivalents of IPv4 space, a large IPv6-originated space count, 223 peers, two upstreams and two downstreams. Its upstream list includes GSL Networks and atom86. Hurricane Electric’s BGP view records the same broad identity and prefix set and exposes a RIPE aut-num object with as-name TUXIS, AS-TUXIS and AS-TUXIS6 route sets, and contact addresses for abuse, peering and network operations.
These details do not prove service quality. They do show that Tuxis has a measurable network identity. In the hosting market that is a useful threshold. A provider that operates its own ASN and peering relationships can manage routing policy, improve local reachability, reduce dependence on a single transit supplier and build more credible engineering relationships. It can still fail operationally, but the external record is more substantial than a white-label hosting shop.
The open peering stance is also economically interesting. Tuxis’s own policies say it will peer with anyone who wants to peer, prefers multiple locations and IPv4 plus IPv6, and does not require nondisclosure agreements or written agreements unless the other party does. Open peering can lower transit cost, improve path diversity and signal participation in the operator community. For a small-to-mid network, the benefit is not just cheaper traffic. It is resilience and reputation. A network that is visible at AMS-IX, Frys-IX and Speed-IX can be judged by peers; it cannot hide all of its routing behaviour.
There are limits to what the public record reveals. PeeringDB traffic level is broad and self-reported or maintained through PeeringDB processes; it is not audited revenue. Prefix count is not customer count. Facility listings do not show owned-versus-leased equipment, power density, reserved capacity, cross-connect costs, or actual utilisation. A listed 10G port does not mean 10G of sustained customer traffic. The network evidence supports the statement that Tuxis is real and technically present; it does not support a claim that it is large.
The most valuable network question is actually about dependence. A company selling private cloud and backup continuity must avoid becoming brittle at the upstream, facility or hardware layer. The BGP public view currently shows two upstreams and many peers. PeeringDB shows three public exchanges and four facilities. Tuxis’s own colocation and cloud pages emphasize three data centres and a ring. That is a reasonable public posture for a focused Dutch provider. But the missing details are central: actual failover tests, path diversity across critical customer services, power redundancy, storage-cluster separation, DDoS posture, and what happens if one supplier, one exchange, one metro route or one management platform fails.
For customers, the public record should raise sharper procurement questions rather than blind comfort. Which workloads are replicated across which facilities? What is the recovery point objective and recovery time objective for the specific service? Are backups tested and restorable by the customer or only by Tuxis? Which upstreams are used for which locations? What DDoS protections are included? How are route leaks, RPKI invalids and peer failures handled? Which services depend on shared control-plane components? Tuxis’s evidence is good enough to make those questions worthwhile.
Backup proof is the core of the trust premium
Backup is where Tuxis’s proposition either earns its premium or collapses into ordinary hosting. The company talks about backups more concretely than many small providers. VPS backups are described as encrypted, daily and kept 60 kilometres away. Extra Backup increases frequency to four times per day and extends retention to daily, weekly and monthly layers. daDup is presented as external storage in a Dutch data centre, compatible with S3, SMB, FTPS and SFTP and meant to plug into common backup tools. Proxmox Backup Server is presented as a ready-to-use service with encrypted backups, 3-2-1 strategy support, restore to a new VPS and pricing that avoids traffic and recovery-action charges.
That is economically powerful because backup anxiety is one of the reasons customers avoid moving again. If a customer has seen a restore work, the provider becomes part of the continuity plan. If a backup dashboard exists but restores are slow, incomplete or expensive, the provider becomes a source of hidden risk. Tuxis’s public pages highlight not only backup storage, but the mechanisms that matter: encryption before sending, SHA-256 integrity checks, off-site copies, replicated storage, one-click restore and synchronization to another Tuxis data centre. Those claims are directionally strong.
The word “proof” still has to be used carefully. Public product pages are not proof of individual customer restores. A provider can make daily backups and still fail to restore fast enough for a particular business. It can replicate data and still suffer from control-plane failure, operator error, corrupted application state, ransomware-encrypted source data, inconsistent databases or misunderstood retention policies. The economic buyer should therefore demand evidence at the account level: a sample restore, documented RPO and RTO, retention calendar, immutable or air-gapped copy where needed, clear roles during incidents and pricing for emergency recovery work.
Tuxis’s PBS Flash and PBS Sync variants are revealing because they acknowledge that backup is not one requirement. A low-cost off-site copy is not the same as a low-recovery-time environment. A customer that needs systems restored quickly after a disaster may need flash storage, dedicated backup-server capacity, synchronization and possibly tape or air-gapped retention. The pricing ladder can therefore segment customers by risk tolerance. Some will pay only for basic protection. Others will pay for lower recovery time. The provider’s margin depends on matching the right level to the customer without overselling recovery it cannot actually deliver.
The same principle applies to daDup. S3 compatibility and support for common backup software lower migration friction because customers can keep familiar tools. But compatibility can also make responsibility ambiguous. If a customer’s Veeam, Acronis, Synology, cPanel or Duplicati configuration is wrong, is the backup failure a customer failure or a provider failure? The answer matters during a crisis, not during sales. Tuxis can reduce this risk through support, templates, monitoring and test restores. Public pages show many how-to paths, but not the rate of successful restore tests.
Backup also affects Tuxis’s cost base. Storage-heavy services consume disks, controllers, nodes, power, rack space, replication bandwidth, monitoring and engineer time. The all-in PBS price of EUR 21 per TB is attractive to customers partly because it hides operational complexity. Tuxis must still manage deduplication behaviour, peak billing, capacity expansion, noisy customers, object growth, support tickets and retention disputes. Backup storage can look high-margin until a large restore, a capacity crunch or a support-heavy customer reveals the real cost.
The article’s central judgment follows: Tuxis’s market position is strongest when customers treat backup as an operating discipline rather than a commodity. The company has public product evidence aligned with that discipline. The remaining gap is measured restore performance.
Support response is the second margin engine
Tuxis’s public support claims are not limited to a generic email address. The contact page lists office hours and 24-hour on-call support. The Proxmox services page describes management options that include support by phone, email and chat, a one-hour response time in one support tier, and fully managed service with 24-hour monitoring, 24-hour telephone support, updates, upgrades and labour included. Colocation includes 24-hour support. Customer testimonials chosen by the company repeatedly mention targeted troubleshooting, direct lines, response times, uptime and communication.
Support matters because it converts infrastructure from a product into an account relationship. A VPS customer who gets no help is always shopping. A managed infrastructure customer who gets a competent engineer during a fault becomes harder to dislodge. The provider’s brand becomes associated with an avoided disaster. That is the kind of margin that a small operator can defend against larger platforms.
But support is also where small providers can overextend. A one-hour response target is only meaningful if the provider has staffing, escalation, runbooks and monitoring that match customer criticality. Twenty-four-hour support can mean an on-call engineer for emergencies, not a full 24-hour helpdesk for every request. The economic unit in the assignment is the hosting, cloud and managed infrastructure account. The support cost per account is therefore central. If customers use support heavily for application-level issues outside Tuxis’s core responsibility, margin can disappear. If Tuxis draws boundaries too sharply, trust can suffer.
The company seems aware of this boundary problem. Its sensible-use policy describes what specific products are designed for, what data types and security settings are appropriate, how updates and migration work, and where customer-controlled settings are outside the policy. That document is commercially important because it translates “support” into scope. It helps prevent a customer from assuming that every workload, every security mode and every compliance need is covered by default. In infrastructure, explicit boundaries are a form of service quality.
The customer cases also show the market Tuxis wants. Let Things Talk says Tuxis could meet requirements at an attractive price and think along about platform design, and that during a fault Tuxis worked in a targeted way. Dronebotics mentions expertise, fast response times, uptime and safe data storage in the Netherlands. CoDesk says it evaluated known players such as VMware, Nutanix, Hyper-V, Dell and Lenovo before choosing Tuxis Corporate Cloud for similar functionality, fully managed service and lower costs through software-defined design. These examples are not independent survey data, but they point to the same buying mechanism: a customer values engineering judgement at the moment when infrastructure needs to be redesigned, not just hosted.
Unofficial market evidence is thinner than one would like. Public search results and open review trails do not produce a rich independent corpus of complaints or praise. That absence is itself a signal, but a weak one. It may mean Tuxis has a relatively professional and satisfied customer base. It may mean it serves customers who do not post on consumer-review sites. It may mean the company is too small to generate much public chatter. It may also hide private frustrations. For an infrastructure buyer, the right conclusion is not that Tuxis has no problems. It is that public reputation evidence is sparse, so reference calls and live support tests become more important.
Support is therefore a margin engine and a risk engine. Tuxis’s public materials align support with managed Proxmox, backup and private cloud. The missing facts are ticket volumes, escalation times, after-hours staffing, customer satisfaction, outage communication quality and whether Tuxis can keep the same support character as it grows.
Cost base: software-defined does not mean cost-free
Tuxis’s public proposition leans heavily on software-defined infrastructure. Proxmox replaces or competes with VMware’s virtualisation layer. Ceph provides distributed storage. Proxmox Backup Server supports backup and retention. Open-source tools reduce licence dependence and, in Tuxis’s telling, allow the company to build high-quality infrastructure at reasonable cost. That is plausible. It is also incomplete.
The cost base of a provider like Tuxis has several layers. Hardware comes first: servers, disks, NVMe storage, controllers, network switches, routers, optics, racks, spares and replacement cycles. Storage-heavy products are hardware-hungry because customer data and backups grow even when compute does not. Tuxis’s own TCC page says its architecture can use 30% less hardware and about 50% less power than regular private-cloud solutions. Whether or not those numbers hold broadly, they show the company understands hardware and power efficiency as part of its margin story.
Power and facilities come next. Dutch data centres are not free, and European energy prices have been volatile. Colocation pricing that charges for consumed power acknowledges this directly. Private cloud and VPS pricing have to recover power costs indirectly. If Tuxis sells fixed monthly infrastructure contracts, it must either price power risk into the contract, hedge it operationally, or reserve the right to adjust prices when cost factors rise. Its terms and conditions say it is entitled to increase order prices if cost factors rise, subject to relevant regulations and foreseeable increases being recorded in the order confirmation. That clause is commercially rational, but customers will care how often it is used.
Network costs also matter. Peering can reduce paid transit, but it requires exchange ports, cross-connects, routers, engineering time and operational discipline. Transit suppliers still matter for reachability and resilience. DDoS mitigation, route filtering, RPKI maintenance and monitoring add cost. Public route data shows Tuxis has many peers and a small number of upstreams. That likely helps traffic economics, but it does not eliminate the need for paid connectivity.
Software cost is more subtle. Open-source software avoids some licence fees, but it does not avoid skill cost. Proxmox, Ceph, PowerDNS, LibreNMS and backup systems require engineers who know how to design, operate, patch, troubleshoot and recover them. An open-source stack is cheapest when expertise is high and standardisation is strong. It becomes expensive when every customer architecture is bespoke. Tuxis’s managed-service model must therefore balance flexibility with repeatability.
Support labour is the most variable cost. A customer with a clean architecture and clear responsibilities may be profitable for years. A customer with legacy systems, unclear application ownership, weak internal IT and frequent emergencies may consume engineer time out of proportion to monthly recurring revenue. That is why Tuxis’s emphasis on appropriate services and sensible-use policies matters. It needs to sell engineering involvement without becoming an unlimited helpdesk.
Compliance and security add another layer. ISO 27001 certification, published policies, coordinated vulnerability disclosure, GDPR processor terms, abuse handling and incident response all consume management attention. For regulated or privacy-sensitive customers, these investments are part of the value proposition. For Tuxis, they are also fixed costs that must be spread across accounts.
The resulting economics are not the economics of a pure software company. Tuxis sells recurring services, but underneath them sit depreciating assets, power exposure, facility commitments, support labour and engineering risk. The company’s advantage is that a well-run focused provider can match steady regional workloads to a relatively efficient stack. Its risk is that one or two cost layers can move against fixed customer contracts.
Upstream and supplier dependence
Tuxis markets independence, but no infrastructure provider is fully independent. Independence in this context means reduced dependence on a single hyperscale cloud or proprietary virtualisation vendor, not freedom from suppliers. Tuxis depends on data-centre facilities, power, hardware vendors, optics, routers, transit providers, internet exchanges, domain registries, certificate providers, open-source projects, Proxmox subscriptions and the labour market for skilled engineers.
The Proxmox dependence is deliberate. Tuxis is an official Proxmox hosting partner according to its own site, and its product architecture is deeply tied to Proxmox and Ceph. This can be a strength because specialization improves support and automation. It can also be a concentration risk. If Proxmox changes its subscription model, security cadence, roadmap, backup integration or partner economics, Tuxis would feel it. The same is true of Ceph. A storage architecture based on Ceph can be powerful and efficient, but it needs disciplined design and operational expertise.
Network dependence is visible in the public records. bgp.tools lists GSL Networks and atom86 as upstreams. Hurricane Electric’s view of the RIPE aut-num object shows import and export policy stanzas involving atom86 and other transit or customer relationships. PeeringDB lists public peering at AMS-IX, Frys-IX and Speed-IX. The good news is that public peering and multiple facilities reduce single-supplier exposure. The caution is that a small provider still has fewer redundancy layers than a hyperscale platform. A serious supplier problem, exchange outage, route leak or fibre cut can be felt more sharply if mitigation is not well rehearsed.
Facility dependence matters because Tuxis’s cloud story emphasizes three data centres. PeeringDB lists BIT-1 and BIT-2 in Ede, maincubes AMS01 in Schiphol Rijk and NIKHEF Amsterdam as interconnection facilities. Tuxis’s pages refer to three Dutch data centres for cloud and storage, and to Ede, Amsterdam and Düsseldorf for Proxmox Backup Server account choices. The public record does not show the exact mapping between each product and each facility. That matters for procurement. Customers should know where primary data resides, where backups reside, whether management systems are separated, and whether a single facility failure affects support portals, DNS, backups or customer workloads.
Hardware dependence is less visible. Tuxis’s public pages mention SSD, NVMe, servers and data-centre infrastructure, but not vendor concentration, replacement intervals, spare inventory or supply-chain terms. For a provider whose services depend on storage and virtualisation, disk failure rates, controller compatibility, firmware practices and replacement logistics are not trivial. Software-defined storage can survive hardware failure only if capacity headroom and operational response are strong.
Human dependence may be the largest hidden risk. Tuxis presents a personal engineering culture, and that is attractive to customers. But smaller engineering-led infrastructure firms can become dependent on a small number of senior people who understand the whole platform. Public evidence does not show management depth, staffing levels or succession. The customer should ask who can handle a critical incident if the usual engineer is unavailable, how knowledge is documented and how support scales during simultaneous incidents.
Supplier discipline is therefore the condition that turns independence from slogan into operating fact. Tuxis has public signs of discipline: policies, peering, multi-site claims, backup products and network records. The missing supplier-level facts are exactly the ones that decide performance under stress.
Customer and market dependence
Tuxis appears to target organisations that need infrastructure control without wanting to operate everything themselves. Its public testimonials and logos point toward media, healthcare-related IT, software and hosting resellers, educational or institutional customers, managed service providers and technical firms. The company’s own homepage names healthcare, education, ICT and SMEs as target groups for private cloud and sovereign cloud infrastructure.
This is a sensible niche. Dutch and European SMEs often have workloads that are too important for casual shared hosting, but not large enough to justify a full internal infrastructure team or a complex hyperscale architecture. They may also have client or regulatory requirements that make data location, support clarity and privacy posture commercially relevant. For such customers, Tuxis can sell peace of mind: Dutch company, known address, engineers available, backups in Dutch or European locations, Proxmox expertise, and a path from VPS to private cloud.
The customer dependence risk is concentration. Public evidence does not reveal whether Tuxis’s revenue is diversified across hundreds of small accounts or concentrated in a handful of larger private-cloud and colocation customers. That distinction matters. A VPS-heavy provider has lower account concentration but higher churn and price competition. A private-cloud provider has stickier accounts but greater exposure to a few renewals. A backup-storage provider may have steady revenue but heavy capacity obligations. Tuxis likely has a blend, but outsiders cannot see the proportions.
Market dependence also changes as customer technology changes. Some customers will move upward into more managed platforms. A SaaS replacement can eliminate the need for a custom hosted server. Managed WordPress can remove a generic web-hosting account. Microsoft 365, Google Workspace, industry SaaS and vertical cloud products can hollow out local infrastructure demand. At the same time, VMware licensing pressure and interest in sovereign or regional alternatives can push customers toward Proxmox-based private clouds. Tuxis benefits from the latter trend and is threatened by the former.
The most attractive demand pattern for Tuxis is a customer with stable, business-critical, moderately complex workloads. Such a customer wants predictable monthly costs, support, backups and local control. It does not need thousands of global cloud services. It does need a provider that answers the phone. That market is not glamorous, but it can be profitable if churn is low and support is priced correctly.
The weakest demand pattern is a customer whose workload is either too simple or too cloud-native. A brochure site, small shop or hobby server will shop on price. A modern data platform, advanced analytics workload or globally distributed application may need services Tuxis does not offer at comparable scale. The company’s public positioning wisely avoids claiming to be everything. It focuses on virtual datacenters, Proxmox, backup, storage and local infrastructure trust.
Unofficial chatter does not add much confirmed evidence. The absence of a large public complaint corpus should be treated as a weak positive, not a proof point. The company appears to operate in a market where many satisfied or dissatisfied customers would communicate privately rather than on mass review sites. For a buyer, reference checks with similar customers are more valuable than generic star ratings.
Competition: the substitute is not one company but several exit paths
Tuxis competes against several different exits from the customer’s current setup. The first is hyperscale cloud. AWS, Microsoft Azure and Google Cloud offer global capacity, mature security tooling, managed databases, identity integrations, procurement familiarity and a huge partner ecosystem. For many enterprises, those benefits outweigh local support and data-centre specificity. Tuxis can win when the workload is steady, regional, cost-sensitive, privacy-sensitive or better served by direct infrastructure engineering than by a menu of managed cloud primitives.
The second substitute is the budget VPS provider. Hetzner, OVHcloud, Contabo, Netcup, DigitalOcean, Linode, Vultr and many smaller hosts can offer attractive headline prices. Tuxis cannot assume customers will pay more unless the difference is legible. Its answer is backups, Dutch locations, support, Proxmox expertise and a path to managed private cloud. That answer works for professional customers; it does not work for buyers who only want the cheapest server.
The third substitute is a local managed service provider. An MSP can manage the customer’s office IT, cloud accounts, endpoint security, Microsoft environment and vendor relationships. Some MSPs will resell infrastructure rather than operate it. Tuxis can be supplier to those MSPs or competitor to them. Its colocation, backup and private-cloud products are well suited to channel relationships if the MSP wants a technical back end. The risk is that MSPs may prefer bigger infrastructure brands or build their own stack.
The fourth substitute is in-house infrastructure. A technically strong customer can buy servers, use Proxmox or another platform, colocate equipment and manage backups directly. Tuxis competes against that by bundling management, monitoring, support and multi-site design. The value proposition is not that the customer cannot build it. It is that the customer has better things to do.
The fifth substitute is SaaS. This is the most structural threat. If a customer can replace a hosted application with a SaaS product, the infrastructure decision disappears. No amount of better peering or cheaper storage wins an account that no longer needs servers. Tuxis’s strongest customers will therefore be those with custom applications, data-control needs, reseller obligations or workloads that cannot be easily SaaS-ified.
The sixth substitute is enterprise virtualisation and hyperconverged infrastructure. VMware, Nutanix, Hyper-V, Dell and Lenovo appear directly in Tuxis customer-case language, where a customer says those options were considered before choosing Tuxis Corporate Cloud. This is an important competitive lane because VMware licensing and ownership changes have pushed some organisations to reconsider virtualisation cost. A Proxmox and Ceph specialist can benefit if customers want similar functionality with lower licence dependence and a managed partner.
Tuxis’s competitive moat is therefore not scale. It is fit. If the customer values regional sovereignty, direct support, Proxmox competence, predictable costs, backup discipline and migration help, Tuxis has a coherent offer. If the customer values global service breadth, ultra-low price or full SaaS abstraction, Tuxis is less compelling.
Regulatory, geopolitical and operational risk
The regulatory case for Tuxis is straightforward but should not be overstated. A Dutch provider with published GDPR processor terms, Dutch default data storage and European ownership claims may be easier for some customers to explain than a complex global cloud supply chain. Tuxis’s terms say that, under its data-processing annex, it acts as processor when the customer is controller, processes personal data for the customer’s purposes, and may process personal data within the European Union. Its privacy policy says service data is used to perform the service, invoice customers and comply with legal requirements. Its sensible-use policy describes security assumptions by product.
That can reduce procurement friction for Dutch and European customers. It does not eliminate compliance work. A customer still has to classify its data, configure encryption, manage users, test backups, decide retention, secure endpoints, monitor applications and understand subprocessor use. Tuxis’s sensible-use policy is useful precisely because it does not pretend one security setting fits all data.
Geopolitically, Tuxis benefits from European interest in sovereign cloud and reduced dependence on non-European platforms. The stronger that concern becomes, the more valuable a credible Dutch infrastructure provider can be. But sovereign-cloud rhetoric can also attract scrutiny. Customers will ask what “Dutch” or “European” means for hardware supply chains, software projects, support tools, identity providers, backup locations, monitoring systems and legal requests. Tuxis publishes more than many providers, but high-assurance customers will want contract-level and audit-level detail.
Operational risk remains the central risk. The public record does not show a full incident history. The status site requires JavaScript in a way that is not easily inspectable through static retrieval, and open search did not surface a comprehensive independent outage archive. Tuxis’s blog includes operating updates, such as power-supply improvements at a Tuxis data centre and Proxmox Backup Server service developments, but a blog is not an outage ledger. For customers buying continuity, the absence of easy public incident data means they should ask directly for postmortem examples, uptime statistics, restore-test evidence and escalation procedures.
Legal and abuse risk is also part of hosting. Tuxis’s acceptable-use and abuse policies describe prohibited conduct, notice-and-takedown handling, abuse-report requirements and suspension or termination rights. For a provider with public IP space, colocation, VPS and hosting customers, abuse handling protects network reputation. Poor abuse handling can get address space listed, damage deliverability, annoy peers and increase support burden. Tuxis’s policies are reasonably explicit. The missing fact is enforcement quality.
Security risk is persistent. Tuxis’s CVD policy invites vulnerability reports, describes how to submit them and says it aims to solve reported security problems within 60 days at the latest, with initial responses on shorter timelines. That is a useful public process. Still, infrastructure providers face ransomware, credential theft, misconfiguration, supply-chain vulnerabilities, hypervisor flaws, backup compromise, DDoS attacks and customer-originated abuse. A provider that sells backups becomes a more attractive target because backup systems are high-value.
The economic risk is that operational failure can destroy the trust premium faster than ordinary price competition. A serious restore failure, prolonged support silence, data-location surprise, repeated outage or billing dispute would not merely cost one account. It would weaken the story that justifies Tuxis’s place between commodity VPS and hyperscale cloud.
What the unofficial signals say, and what they do not
The market chatter around Tuxis is modest. Publicly visible company-selected testimonials are positive and specific enough to be useful as directional signals: customers mention response times, uptime, stable performance, direct lines and cost-effective design compared with familiar enterprise alternatives. Tuxis’s blog activity shows continued product and infrastructure development, including Proxmox Backup Server improvements, Dutch Proxmox Day participation, Germany service expansion and data-centre power work. Public peering and routing databases show a network that peers openly and participates in the operator ecosystem.
What is missing is just as important. There is no rich public body of independent reviews, no obvious public revenue data, no disclosed customer count, no public churn metric, no independent restore benchmark, no audited uptime report in the retrieved materials, no detailed incident archive in static form and no clear product-level margin data. That does not mean the company is weak. It means the public market signal is thinner than the marketing signal and infrastructure-database signal.
Thin chatter can be normal for this category. Professional hosting customers often do not post detailed public reviews because their infrastructure choices reveal too much about their operations. Complaints may be handled privately through tickets and account managers. Positive experiences may stay in reference calls. Smaller regional providers also draw less online attention than global platforms. The right analytical posture is therefore not suspicion by default. It is disciplined uncertainty.
The customer testimonials should be weighted but discounted. They are useful because they identify the buying reasons Tuxis wants associated with its brand: support, uptime, lower cost, Proxmox or TCC functionality, Dutch storage and direct engineering help. They are discounted because Tuxis chooses which testimonials appear, and because the absence of critical testimonials on the company site is not evidence of universal satisfaction.
The network records should be weighted more heavily for existence and posture, less heavily for customer value. PeeringDB and BGP records give hard evidence of ASN, facilities, exchange presence, prefixes and upstreams. They do not show whether a particular customer’s backup restored on time or whether support answered effectively at 03:00.
The policy documents should be weighted for governance maturity, less heavily for operational outcomes. A provider that publishes policies, CVD procedures and sensible-use product boundaries is easier to diligence than one that does not. But policies are only valuable if practised.
Taken together, the unofficial and semi-public signals support a cautious positive view. Tuxis appears to be a real, technically visible Dutch infrastructure operator with a coherent niche. The largest uncertainties are not about whether it exists or whether it offers the named services. They are about how well the private operating system performs under stress.
What would change the judgment
Several facts would materially improve the case for Tuxis. The first is tested restore evidence. A public or customer-provided record showing restore success rates, median and worst-case restore times, backup-integrity testing and customer-run restore drills would strengthen the core thesis. For Tuxis, backup is not an accessory. It is one of the main reasons a customer stays.
The second is product-level uptime and incident transparency. A readable incident archive, postmortems for material outages and service-specific availability metrics would help outsiders distinguish between a well-marketed platform and a demonstrably reliable one. A static, accessible status history would be particularly useful for customers who cannot rely on JavaScript-heavy interfaces during diligence.
The third is customer concentration and churn. A diversified recurring-revenue base with low churn would support the idea that migration avoidance works in Tuxis’s favour. Heavy dependence on a few large customers would make the company more fragile. High churn in VPS accounts would suggest that the trust premium is weaker at the low end.
The fourth is support performance. Response-time targets are useful, but actual ticket data is better. Median first response, urgent escalation times, after-hours staffing, resolution quality and customer satisfaction would clarify whether support is a true differentiator or mainly a sales claim.
The fifth is capacity and supplier resilience. Evidence of tested multi-site failover, storage-cluster headroom, upstream diversity by facility, DDoS process, RPKI discipline and power redundancy would make the network and data-centre claims more decision-grade. Public records show footprint, not stress behaviour.
The sixth is financial resilience. Hosting customers depend on the provider’s ability to invest ahead of demand, replace hardware, maintain staff and survive bad quarters. Public sources do not show Tuxis’s revenue, profitability, leverage, capital expenditure or insurance. For small infrastructure providers, financial health is operational health.
Facts could also weaken the judgment. A pattern of restore failures, unresolved outages, billing surprises, unsupported workload disputes, route instability, supplier concentration, privacy exceptions, poor abuse handling or support degradation would undermine the trust premium. So would evidence that “Dutch” or “European” data-location claims are narrower than customers reasonably infer. A major Proxmox or Ceph operational incident handled poorly would be especially damaging because Tuxis’s brand leans into those technologies.
The competitive facts can change too. If hyperscale providers make European sovereign-cloud offerings cheaper and simpler for SMEs, Tuxis faces pressure from above. If budget providers improve backup, support and Dutch data-location options, it faces pressure from below. If VMware migration pain accelerates, Tuxis gets a tailwind. If SaaS replacement accelerates, parts of the infrastructure market shrink.
Final judgment
Tuxis matters because the real price of hosting is set after the first migration, not before it. Once workloads run, backups accumulate, private networks are configured, support routines are learned and customers have seen the cost of change, the provider is selling continuity as much as capacity. Tuxis’s public materials are built around that insight. It offers VPS, dedicated Proxmox, private cloud, edge cloud, colocation, daDup storage and Proxmox Backup Server in a way that encourages customers to deepen the account rather than keep it transactional.
The evidence is strong enough to identify a real company with a coherent operating footprint. Tuxis publishes its Dutch corporate details, policy stack and service boundaries. It has a visible ASN and peering presence. It names facilities, exchanges, backup locations and product mechanics. It presents a clear technology preference around Proxmox, Ceph and open-source infrastructure. Its customer stories, though selected, point to the same economic mechanism: customers use Tuxis to reduce migration pain, get direct support, avoid licence-heavy enterprise stacks and keep data closer to home.
The evidence is not strong enough to treat every reliability claim as proven. Public sources do not reveal the private facts that decide whether a hosting trust premium is deserved: restore outcomes, incident history, support metrics, customer churn, concentration, margins and supplier stress tests. A serious buyer should therefore treat Tuxis as diligence-worthy, not diligence-complete.
The most defensible view is that Tuxis is not competing to be the cheapest server or the broadest cloud. It is competing to be the provider a Dutch or European customer does not want to leave after the hard work of migration is over. That is an attractive niche when support response, backup proof, upstream discipline and data-location trust are worth more than a few euros of monthly compute savings. It is also a demanding niche, because one failed restore or one badly handled outage can erase years of quiet reliability.
For Tuxis, the commercial challenge is to keep turning engineering specificity into customer confidence without letting bespoke support and storage obligations eat the margin. For customers, the practical question is simple: ask Tuxis to show not only where the data sits and what the monthly bill says, but how the restore works when the system is under pressure. If that proof is strong, the company’s price is not just for hosting. It is for avoiding the next migration.