Dade2 is a London-based enterprise cloud provider serving regulated industries with HIPAA, SOC 2, ISO 27001, and PCI-DSS-certified infrastructure across Europe and the USA. I ran a full benchmark suite on a live HPC instance in Madrid: the disk results stand out, the onboarding process requires patience, and the CPU shows its age. Read on for the full picture.
To evaluate Dade2, I applied our hosting review methodology across hands-on provisioning, live benchmark testing, knowledge base review, and portal exploration. The scores below reflect what I found, not what the product page claims.
| Parameter | Score | Why This Score |
|---|---|---|
| Prices | 9.0/10 | Enterprise pricing model with no public rate card. A free trial requires no credit card, which is a genuine advantage for evaluation. |
| Features | 9.5/10 | HIPAA, SOC 1, SOC 2, ISO 27001, and PCI-DSS certifications set this apart. SLA-backed response times and hybrid cloud options add to a strong feature set for the target market. |
| Performance | 9.0/10 | 25,800 random IOPS, near 1 Gbps network throughput, and a clean zero-failure stress test. Single-thread CPU speed is the one place where older silicon shows. |
| Ease of Use | 9.1/10 | Application-based signup and VMware terminology throughout create real friction. No onboarding guidance once inside the portal. |
| Support | 9.2/10 | 30-minute help desk and 59-second LiveChat SLAs are strong commitments. The KB lacks any Dade2-specific platform documentation. |
| Overall | 9.2/10 | A well-specified platform for regulated enterprise workloads. Strongest where storage performance and compliance credentials matter most. |
Dade2 does not publish a public rate card. The platform runs on a custom enterprise pricing model where costs are determined by the resources you configure: CPU count, RAM allocation, disk size, and region.
A live cost estimate appears at the bottom of the provisioning wizard and updates as you adjust each slider, which gives you a clear picture of what a specific configuration costs before you commit.
A few things worth knowing before you start:
To put Dade2’s infrastructure to the test, I provisioned a single HPC instance in the Spain (Madrid) region and ran a full benchmark suite covering CPU, memory, disk I/O, network speed, and sustained stress testing.
Before getting into the numbers, it is worth being clear about what kind of server this is and who it is built for. The Dade2 HPC tier sits above a standard consumer VPS. It runs on VMware vCenter, uses enterprise-grade hardware, and is aimed at business teams, not individual developers spinning up a personal project.
The instance I tested came with an Intel Xeon Gold 6132 processor, a server-class chip designed for multi-socket enterprise workloads rather than high single-thread throughput. That distinction matters, and I will come back to it throughout this section.
Here is the full configuration I tested:
I ran the sysbench CPU benchmark at single-thread first to get the raw per-core result, then at all four threads to see how the allocation scales. Prime number limit was set to 20,000 throughout, each run lasting 10 seconds.
Single-thread:
Multi-thread (4 threads):
The multi-thread result tells a clean story. Four threads produce 1,713 events per second against a single-thread baseline of 432, which is almost exactly 4x. Every core is carrying an equal share of the load, and a thread fairness standard deviation of 8.44 across 4,284 events per thread represents a variance of less than 0.2%. That is about as flat as multi-thread scaling gets.
The part of the CPU result that needs honest context is the single-thread number. 432 events per second is low by current cloud standards. Modern AMD EPYC platforms running the same test return 1,500 to 1,650 events per second.
The Xeon Gold 6132 is a 2017 Skylake-SP server chip, and the single-thread throughput reflects that age. This is not a chip built for fast serial compute. It was designed for multi-socket scalability in enterprise environments, and that shows in the benchmark.
For teams running databases, web application backends, or file serving, where I/O is the bottleneck and CPU is rarely the constraint, this gap matters less. For CPU-bound workloads such as compilation pipelines, rendering, or computational tasks, the per-core performance will be a real ceiling.
I ran sysbench with a 1K block size and 10 GiB total transfer on both passes.
Sequential Write: 4,844.92 MiB/sec
Sequential Read: 6,261.59 MiB/sec
Both results are strong. The read speed of 6,261 MiB/sec means the memory subsystem can feed data to the CPU faster than most workloads will ever demand. Average latency on both passes came in at 0.00ms at millisecond precision, meaning access times are operating below the resolution of the measurement.
For applications that hold large working sets in memory, such as Redis instances, session caches, or query result buffers, the memory on this instance has real headroom.
I used fio across three scenarios: sequential write, sequential read, and random 4K mixed read/write under concurrent load. The –direct=1 flag was set throughout, which tells fio to bypass the OS page cache and write directly to the storage layer. The numbers below are not inflated by memory caching.
Sequential Write: 1,209 MiB/s (1,267 MB/s), IOPS 1,208
Sequential Read: 2,123 MiB/s (2,226 MB/s), IOPS 2,123
Random 4K Mixed: Read IOPS 25,800, Write IOPS 25,800, throughput 101 MiB/s each
The sequential read result of 2,123 MiB/s and the random 4K figure of 25,800 IOPS are genuinely high for a cloud virtual server. This is fast NVMe-backed storage.
One finding from the sequential write test is worth calling out separately. The average throughput of 1,209 MiB/s is strong, but the per-sample statistics show a minimum of 37 IOPS, a maximum of 2,048 IOPS, and a standard deviation of 704 across the test run.
Compare that to the sequential read, where the minimum was 1,736 IOPS, the maximum was 2,192 IOPS, and the standard deviation was 74. Reads are flat and predictable. Writes are not.
That gap in write variability is the kind of detail that matters for latency-sensitive write workloads. A transaction log, a write-ahead log for PostgreSQL, or any application that treats write latency as a performance constraint will occasionally hit the floor of that variability range. For most workloads, the average will dominate. For the ones where it matters, the range is worth knowing before you commit.
The random 4K result of 25,800 IOPS is the figure that production database teams care about most. This is the I/O pattern that drives query performance on indexed tables, and 25,800 IOPS under a mixed concurrent read/write load gives a PostgreSQL or MySQL instance a lot of room before storage becomes the bottleneck.
I ran the Ookla speedtest twice against the same Madrid-based server to check consistency.
Run 1:
Run 2:
Download barely moved between the two runs, landing within 2 Mbps of each other. Upload showed more spread, 921 Mbps on the first run against 882 Mbps on the second, though both numbers sit comfortably in the same tier. Idle latency held under half a millisecond on both tests, and packet loss stayed at zero throughout.
Dade2 advertises a full 1 Gbps connection on its VMs, and this instance delivers on that. A Madrid-hosted server returning over 930 Mbps download with zero packet loss is a strong result for a cloud VPS at this tier, and the sub-half-millisecond latency confirms the route stays local rather than hopping through a distant exchange.
The stress test ran all three stressors in sequence, each for 180 seconds. CPU used all four workers, memory used two workers allocated 75% of available RAM, and HDD used two workers.
Zero failures across all three phases. Every stressor dispatched returned as successful and nothing was flagged as untrustworthy.
The HDD stress figure of 48,882 bogo ops/s over three minutes of continuous disk pressure is consistent with the strong fio numbers from earlier. The storage holds its performance under sustained load rather than showing a strong initial result that degrades over time. That distinction matters more than the bogo ops number itself.
A server that benchmarks well in isolation but falls apart under sustained combined pressure tells you something important about the underlying infrastructure. That did not happen here.
The Dade2 HPC instance is strongest on storage and network, with the CPU as the one area where the numbers tell a different story. Sequential read at 2,123 MiB/s, sequential write averaging 1,209 MiB/s, and 25,800 random 4K IOPS under mixed concurrent load put this server well above standard cloud SSD performance, and the stress test confirms storage holds up under sustained pressure.
Memory is equally strong at 4,844 MiB/s write and 6,261 MiB/s read with sub-millisecond latency. Network throughput reaches close to a full Gbps, with idle latency under half a millisecond and zero packet loss across two separate test runs, a strong result for a Madrid-hosted instance.
For databases, file serving, and bandwidth-heavy applications, this instance performs well above what the specs alone suggest. For CPU-bound compute, the gap is real and worth planning around.
To get a fair picture of the Dade2 experience, I went through everything from scratch: landing on the website, submitting an application for trial access, and working through the portal until I had a live server I could connect to.
Dade2 positions itself in the enterprise space, and that orientation shapes every part of the process. Here is a detailed account of what each step looks like in practice.
The Dade2 homepage makes the free trial visible immediately. A “Try our cloud for free” button sits in the main hero section alongside a globe graphic showing the provider’s data centre cities: Miami, Reykjavik, Nuremberg, and Madrid.
Scrolling down surfaces a second entry point dedicated to enterprise cloud. The heading reads “Test Drive our Enterprise Cloud Infrastructure,” with “No credit card required” and a “Get started for free” button below it.
Both buttons lead to the same place. This is the single most important thing to know about Dade2 registration: it is not an instant self-service signup.
Clicking either button opens an application form that asks for:
Every field on that form points to the same audience: businesses and IT teams. The Work Email field alone rules out anyone signing up with a personal address, and the Company Name and Job Title fields make the B2B intent clear before you hit Submit.
After the form goes through, the page shows a brief confirmation: “Thank you for your message. It has been sent.”
From that point, you wait. Access is provisioned manually by Dade2’s team after they review the application.
There is no verification email with an instant login link. I received portal credentials after going through that process.
How I found it: The no-credit-card offer is a genuine advantage for evaluation. But the lack of instant access will surprise anyone who has used consumer- or developer-focused cloud platforms, where you can typically provision a server within minutes of landing on the homepage.
With access granted, the portal is open. A green “Create Server” button sits at the top right of every screen.
Clicking it opens a five-step wizard.
Step 1: Cloud Locations
The wizard opens on a full-width interactive world map. Clicking a pin reveals a tooltip showing the country and city of that data centre. Dropdown fields at the bottom of the screen confirm the selection.
I selected Spain, Madrid and moved to the next step.
Step 2: Templates
Templates are grouped by region and displayed as card tiles with image counts. The groups in my session were:
Selecting a group populates the right panel with available OS images and their minimum memory and storage requirements.
Pricing updates live at the bottom of the screen as you make selections. I picked HPC – AlmaLinux-84 – ESP.
Step 3: Properties
This step covers the display name, hostname, and domain for the server. The domain defaults to “localdomain” and can be left as is for most setups.
The password field includes a placeholder reading “Leave Blank for Auto Generation,” which I used. Auto-generating the password and retrieving it from the portal later is cleaner than setting one manually at this stage.
Step 4: Resources
This is the most detailed step in the wizard. You configure compute and storage through a combination of sliders and dropdowns:
The estimated hourly price at the bottom updates as you adjust each slider. My trial account showed €0.0000 throughout, but the mechanism works for production accounts to track costs in real time as they configure each resource.
Step 5: Confirmation
A clean summary before anything is committed. The confirmation screen shows:
Clicking “Create Virtual Server” triggers an immediate notification confirming the build was queued and takes you to the Virtual Server Details page. The server status shows as Building in the right panel.
One detail worth noting: the IP address and login credentials appear in the right panel before the build finishes. You can copy your SSH details the moment the server enters the queue, without waiting for Active status.
How I found it: The wizard is well-sequenced and mostly clear. The interactive map in Step 1 is a thoughtful visual approach to region selection, and the live pricing updates in Steps 2 and 4 remove the guesswork from cost planning. Step 4 is where the platform’s enterprise character shows up most sharply.
CPU Priority, vCenter Resource Pool, and Data Store Zone are all terms drawn from the VMware world. An IT engineer will move through this step without pausing. Someone approaching cloud hosting without that background will need to stop and research what these settings mean before proceeding.
The confirmation screen in Step 5 is one of the better-designed pre-launch summaries I have seen at this level, and the credentials appearing before the build completes is a small but practical touch.
The Dade2 cloud dashboard is organized into three clear zones:
The four statistics charts populate once you have active servers running. Before that, they show “No data to display” across the board, which gives the dashboard an empty feel on first login.
Nothing in the sidebar is buried more than one click away, and the labels are descriptive enough that you can work out what each section covers without prior familiarity with the platform.
The Activity Log below the statistics charts is where the dashboard earns the most of its value. Every platform action is logged and filterable by status:
Each log entry shows a reference number, timestamp, action type, target server, and the dependent task ID that triggered it. If a build fails mid-provisioning, you can see exactly which step in the chain did not complete.
That level of logging removes a lot of the uncertainty that normally comes with watching a server provision, and it means your first call is not to support asking what went wrong.
The green “Create Server” button is fixed at the top right and persists across every portal screen, which is the right decision for a platform where server creation is the primary action.
How I found it: The Activity Log is the standout feature of the dashboard and the clearest sign that this platform was built by people who understand how operators work. For everything else, the dashboard does what it needs to do and stays out of the way.
From the Virtual Servers list, I clicked the server label to open the management interface for PROD-01.
The management interface organizes everything under five tabs:
The Overview tab is the most information-dense of the five. The right panel keeps the operational essentials permanently visible: server name, OS image, power controls, an ACTIONS dropdown, login credentials with a clickable password link, and the estimated hourly rate.
Everything needed to identify, access, and control the server is on one screen without any additional clicks.
The Notes field below the spec summary lets you attach free-text annotations to each server. For teams managing multiple instances across regions, keeping operational notes tied directly to each server saves time and avoids the confusion that builds up when that information only lives in a shared document.
The Activity Log at the bottom of the Overview tab shows the full build chain for this specific server. For PROD-01, all four steps ran in sequence and completed with green status:
Seeing the build chain at this level of detail has a practical purpose. If any step had failed, you would know exactly where in the sequence it happened rather than receiving a generic error with no indication of what to do next.
The Console tab deserves a specific mention. In-browser console access to the server is available directly from the management page without any additional configuration. For situations where SSH has been misconfigured or is not yet set up, having console access one click away is a real operational safety net that matters most when something goes wrong at an inconvenient time.
How I found it: The server management interface is well put together. The tab layout covers everything needed for daily operations, related settings are logically grouped, and the Activity Log at the instance level is as useful here as it is at the account-level dashboard.
Dade2 is an enterprise cloud platform, and the experience at every step reflects that. Registration is a managed application process, not a self-service signup. The provisioning wizard is logically sequenced, but the Resources step assumes a VMware background that many users will not have.
The dashboard is clean, and its Activity Log is one of the more transparent build-chain displays in this category, but the platform offers no onboarding guidance for new users. The server management interface covers everything needed for day-to-day operations and does so without unnecessary complexity.
The learning curve at Dade2 is real, and the platform makes no attempt to flatten it. If your team has the enterprise IT background this platform was built for, you will find it capable and well-organized.
Before submitting a ticket or picking up the phone, my first instinct with any new provider is to check whether I can find answers on my own.
A good knowledge base saves time on both sides. So before testing any live support channel, I went straight to the Dade2 KB to see how far self-service could take me.
The KB is accessible from the main navigation bar under “kb.” The homepage opens to a category grid organized by technology and topic.
Categories I could see at a glance:
Each category carries a badge showing how many articles sit inside it. Linux leads at 15, CPanel and centos at 10 each. Several categories hold a single article. A search bar runs across the top of the page for anyone who knows what they are looking for.
To test the quality properly, I opened the article on resizing a root partition in Ubuntu using GPT. This is a real-stakes technical topic where a bad instruction can cause data loss, which makes it a fair test of how seriously the KB treats its readers.
What the article does well:
One thing I noticed in the metadata: the article shows an update date of August 11, 2027, which is more than a year from the date of this review. That is either a CMS entry error or a display bug. It does not affect the article content, but it raises a question about how closely the content management side is being monitored.
The larger observation about the KB as a whole: it reads as a general Linux and server administration tutorial library, not documentation for the Dade2 platform itself. There are no articles covering:
For a new user who just provisioned their first server and wants guidance specific to the platform, the KB will not answer those questions.
How I found it: the article quality is genuinely good for what it covers. The inline warnings, the terminal screenshots, and the step-by-step format all reflect real care for the reader. But walking through the full KB, I could not find answers to the questions I actually had about the Dade2 platform.
The library is useful for general Linux administration. It is not useful for learning how Dade2’s own product works.
For a platform that already assumes enterprise IT experience from its users, that gap in platform-specific documentation is one of the more significant support weaknesses I found.
For the right customer, yes. Dade2 is a well-built enterprise cloud platform that delivers on its most important promise: certified, SLA-backed infrastructure for businesses operating in regulated industries.
The disk performance is the standout result from testing, with 25,800 random IOPS and clean sequential throughput that suit database and file-serving workloads. The certification stack, HIPAA, SOC 2, ISO 27001, and PCI-DSS, is genuine, and the hardware replacement and response time SLAs give production teams something concrete to hold the provider to.
Where Dade2 falls short of a full recommendation is for anyone outside its target audience. The application-based signup, the VMware-heavy provisioning interface, and the complete absence of platform documentation in the knowledge base all assume an enterprise IT background that most individual developers and small teams do not have.
The Xeon Gold 6132 CPU is a 2017 chip, and that generation gap shows up in single-thread benchmarks. For CPU-intensive compute or high-bandwidth applications, this platform is not the right fit.
If your team manages infrastructure for a regulated business and needs certifications, SLA-backed uptime, and a provider that treats you as an enterprise customer, Dade2 earns its place on the shortlist.
| Plan Name | Space | CPU | RAM | Bandwidth | OS | Price | |
|---|---|---|---|---|---|---|---|
| Free trial | Unlimited | - | Unlimited | $0.01 | Details |
Dade2 is a strong enterprise cloud provider for regulated industries, backed by HIPAA, SOC 2, ISO 27001, and PCI-DSS certifications. Benchmark testing showed 25,800 random IOPS and a clean zero-failure stress test on the HPC tier. It is not designed for individual developers or self-service users.
Dade2 operates across four regions: Madrid (Spain), Iceland, Germany, and the USA (East). All four are available through the same provisioning portal using the same five-step wizard.
Dade2 offers a cloud trial that requires no credit card. Access is not instant: you submit an application with your work email, company name, and job title, and the Dade2 team provisions your account after reviewing the request.
Dade2 holds HIPAA, SOC 1, SOC 2, ISO 27001, and PCI-DSS certifications. The platform is also GDPR compliant. These credentials make it a valid option for healthcare, banking, online gaming, and other industries with strict data compliance requirements.
Dade2 does not advertise a money-back guarantee. Compensation under the SLA is issued as hosting credits rather than refunds. Credits are capped at the customer’s monthly recurring charge and must be claimed within three business days of an incident.
Answer a few simple questions and find the perfect solution for you!
Start Hosting Search
