All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Delux Host 6‑Month Review: Great Price, Horrible Support, Subpar Performance
Tried a lot of budget VPS providers from this community, so here’s a “short” review of what has been one of my worst experiences with a so-called technical team. Expectations were already low, and they still managed to limbo under them.
Overall ratings: Pricing 8.5/10, Performance 5.5/10, Support 0/10.
Disclaimer & expectations
Before anyone jumps in with “it’s a promo, what did you expect?”: yes, this was a cheap deal and no, top-tier performance was never part of my fantasy. I fully expect older hardware, overprovisioning, and the occasional potato-level disk.
All that is fine with me as long as the server stays reachable and support can read a ticket without getting lost. “Somewhat decent performance + basic reliability + minimally competent support” was the entire bar. Spoiler: only one of these even half-cleared.
For reference:
- Provider: Delux Host
- Plan: Offer Z – Z-4
- Location: Netherlands
- Specs: 2 vCPU (Intel Xeon Gold), 8 GB RAM, 80 GB SSD, “Unlimited” bandwidth (FUP), 10 Gbps port, 1× IPv4 + IPv6
Now to the fun parts.
Pricing – 8.5/10
Pricing is honestly the best thing about this service. You look at 8 GB of RAM at this price and think, “Surely something will be terrible, but this seems worth a gamble.”
For what you pay, it’s hard to complain about the raw numbers on paper. If this were just about cost per GB of RAM, Delux Host would look great.
Performance – 5.5/10
This was a blind buy mostly for the RAM; the VPS sat idle for about two months while plans were made to move some apps over. That’s when reality hit.
The moment dependencies were installed and things started to actually do work, the VPS would just freeze: SSH would hang, nothing responded, and after 5–7 minutes it would suddenly “come back to life” like nothing happened. Benchmarking with YABS showed performance worse than a 10-year-old dual-core laptop, and the disk speed felt firmly in “old HDD” territory. Still, at this price, it was tolerable, because uptime and reachability were what really mattered for the low-traffic apps deployed.
Then users started reporting they couldn’t reach the applications. Zeabur’s dashboard (the platform used, similar to Railway with personal server integration) showed services were fine and logs were clean. Digging deeper showed that from some ISPs the VPS IP simply wasn’t reachable at all unless traffic was proxied through Cloudflare; direct access failed.
After taking backups, the OS was rebuilt from scratch and tested with no modifications: same issue. From some other servers, pings and connectivity to the VPS worked. From certain networks/ISPs, nothing. That points pretty clearly to a routing/IP-level problem, not some random misconfiguration on a fresh OS.
Support – 0/10
At this point, all the usual evidence was collected: ping results, MTR/traceroute, the affected IP address, clear explanation that the VPS itself was reachable from other locations but not from specific ISPs. A ticket was opened with all of this asking them to investigate and, if necessary, assign a replacement IP.
The first answer looked like it came from an automated assistant. Fine. The second reply, allegedly from their “technical team,” was:
“Could you please provide the server IP and password in order to do a manual check with our team on it?”
The IP was already in the ticket, along with snippets(mtr,ping). Apparently reading beyond the subject line was a bit too advanced. Still, the details were reiterated, and a root password was created and provided, just to remove excuses.
The next reply?
“Please send the IP affected.”
At this point it was unclear whether they were trolling or genuinely unable to scroll up in their own ticket system. The issue remained unresolved more than 24 hours later. Fortunately, no critical or high-traffic workloads were entrusted to this provider, because this level of “support” would have been catastrophic.
In short: pricing is attractive, performance is barely passable, and support is an absolute write-off. Hosting companies in so-called “third-world” countries manage better responsiveness and basic reading comprehension than this.
Comments
Would it be fair to say that by reading the title I know all I need to know? The bla bla looks intimidatingly long.
I feel like they are trying, but growing too fast and they don't hold themselfs back. For me the support is actually fine, tho I didn't pressure much either.
If they could bring the performance on par to similar providers here on LET, it would be a great deal.
Yeah, the title is the TL;DR. The ‘intimidatingly long bla bla’ is just me going full Karen and asking for the manager in written form.
Hello,
Thank you for taking the time to write a detailed review.
We’d like to provide some additional technical context, as each support ticket is handled individually and depends heavily on the specific situation and information available at the time.
Regarding the routing issues mentioned, over the past months we have actively worked on this area and resolved the vast majority of reported routing problems. In most cases, these issues originated from upstream transit providers rather than our internal infrastructure, which can make resolution more complex and time-consuming. Where possible, routes were corrected, escalated with providers, or IP ranges adjusted.
On the support side, when a customer operates multiple services, our team may explicitly ask to confirm the affected IP or VPS, if there are doubts, even several times, but this does not mean voluntarily delaying. This is a necessary step to avoid troubleshooting or modifying the wrong service and potentially impacting unrelated systems, not a lack of attention to the ticket content.
Our support generally gets positive reviews on issues that actually depend on us, but when it comes to other types of problems, which depend on external factors, the situation tends to change.
We are constantly trying to improve, and managing infrastructure, upstream providers, and support at scale is not always straightforward. That said, we’re genuinely sorry that your experience did not meet expectations.
If you’re willing, please feel free to share the ticket ID related to this case. I would be more than happy to personally review it, understand exactly what happened, and see where we could have handled things better.
We appreciate the feedback, even when critical, as it helps us continue improving.
Thank you again.
That’s a fair take and honestly I want them to succeed, because on paper the deals look great.
My experience just happens to be from the “when things break and support mishandles it” side, so I figured it was worth documenting that angle too.
You’re right that we’re in a growth phase, and scaling while maintaining consistent performance is something we’re actively working on. Support quality and infrastructure improvements are both areas we’re continuously refining.
Bringing performance in line with comparable LET providers is absolutely one of our goals, and ongoing upgrades (including storage-side improvements) are aimed exactly at that.
Thanks again for the balanced perspective.
I have this strange problem where my ISP can't access or ping one of my VPSs for some reason.
The deal is ridiculously good for the price, so I didn't bother opening a ticket to get it fixed.
Thanks for pointing that out.
If you’re experiencing reachability issues from specific ISPs, please do open a ticket and let us know which VPS/IP is affected. We’ll be happy to look into it and help get it resolved.
Even on discounted plans, routing and connectivity issues are something we do take seriously.
A few points, though:
At this point, I mainly want to see how long it takes for the support team to fully resolve this case. I’ll wait another 48 hours; if it’s resolved (or not) by then, I’ll update my review accordingly and include the ticket number for full transparency.
Thank you for the clarification, your point is understood.
If you’re willing, please share the ticket ID so we can review the entire case in detail and handle it with maximum priority. There may indeed have been an oversight in the back-and-forth, and while that can happen, our focus here is not on excuses or defensive explanations, but on resolving the issue properly.
Once we have the ticket reference, we’ll do our best to drive it to a clear resolution in the shortest possible time.
We appreciate your patience and the constructive approach.
That sounds very similar to what I ran into. I probably would’ve shrugged it off too (the deal really is hard to ignore), but the overall experience pushed me to open a ticket and the way the support responses were handled is what ultimately pushed me to write the LET review.
seems to working now, but network looks unstable and with packet loss to some locations.
I've dealt with several connectivity issues with these guys. Eventually everything gets resolved but it takes forever because of the idiotic back and forth, and then a couple weeks later it's happening again. Every issue was related to UDP filtering except the last one. It hasn't happened again since a recent sale thread here on LET where a couple other people mentioned it and I jumped in with a "me too".
The most recent one is also similar to what @ShalaWorks describes, suddenly my pimary IP was filtered (from 2 vps, different offers so I assume different boxes). Again it was eventually taken care of but it took 6 days or something. You could clearly see from the traceroutes where it was happening, not mysterious at all (except the why, never explained).
I suspect you can check any ticket for this because it happens every time I've reported network issues too. I take pains to provide all info in the first ticket specifically to cut down on back and forth, but we end up doing it for a few days anyway because we must recite the service ip over and over, even though it's in the ticket dropdown and the subject and the traceroutes.
I'm a little annoyed that you're here pretending you don't know this is exactly what goes on, since we just had this conversation about my most recent ticket exchange. Maybe you're the guy not actually reading the tickets?
I was going to avoid this thread but your response annoyed me enough to share my experience.
Hello,
As I have already mentioned to you in private, most of the routing issues encountered, or those related to them, did not originate directly from us but from our upstream provider. We work closely with them at all times, providing all the necessary information for the analysis and resolution of reported issues, and then wait for a solution from them, which for the moment has already been found for most of the problems.
An issue that appears similar may have different causes compared to another user’s problem. Without a reference ticket ID, unfortunately, I am unable to understand precisely which situation is being referred to or how to intervene in the most effective way.
I do not manage the ticketing system directly, but i always do my best to provide support and contribute to everyone’s satisfaction.
We're trying to solve and help everyone, from every perspective.
I've currently been trying to contact the guy on the post to see if I can get a ticket ID that I can check to see what happened, whether there was a mistake on our part, only then I can help him and I'm more than willing to do so of course.
And specifically, this doesn't change one inch of our goal of providing the best possible service at the lowest possible price, your reviews only push us to improve.
That actually makes my experience feel less like a one-off and more like a pattern. If this is a known issue that keeps happening, the technical team looks even more incompetent than I thought. Was the rep’s name “AF” by any chance?
Here’s the thing: as a hosting company, your technical team should be competent enough to recognize the type of issue a client is facing. If it’s an isolated case, investigate and resolve it. If it’s a widespread, recurring problem, you ask for any missing specifics and provide transparency: a link, a blog post, a status page literally anything that explains what the issue is, what you’re doing about it, and what customers should expect. That’s what every competent company does. Transparency matters. This review should serve as a warning for future potential buyers in this community.
yabs.sh = yet another bull shit - summer host
Hello,
We fully agree that transparency is essential, and this is exactly why we maintain a public status page where any widespread or recurring issues are always documented and communicated in detail.
In this specific case, our monitoring systems and customer reports do not indicate a general or recurring problem affecting other users. When an issue appears to be isolated, our standard approach is to investigate it on a case-by-case basis, working directly with the customer to identify environmental or configuration-specific factors that may be involved.
We have asked for the ticket ID, which we are currently unable to obtain despite our requests, for solve the problem, and we remain available to do so. Should evidence emerge that this is a broader issue, we would of course communicate it transparently through our usual channels, as we have always done in the past.
Our goal is not to dismiss concerns, but to resolve them based on verifiable data and collaboration. We remain open to continuing this process.
There is one thing we are definitely working on, though: improving our customer support even further and making it faster and more efficient.
I completely agree with the author of the review. I have exactly the same impressions, only my tariff plan is the cheapest - F1 with 1GB of RAM.
The server started working very slowly a long time ago, my first payment was in May, and already in August it worked very slowly, but I use it very rarely, almost 99% of the time it was just idle and I don't keep monitor of it. And then I needed to check one script on it, the script checks which country the IP of the server belongs to from different services - Youtube, Spotify, Netflix, etc. So, the script didn't even start on my server from Delux Host!!!
By the way, I have 2 other servers - One in Turkey, the other in Russia, even with a smaller amount of RAM, immediately run this script and go through it within 20-30 seconds.
I wrote about it in support. Then everything is as it is with you - Write the IP of the server, give us your username and password, we will check, then they checked something for 3 days and wrote to me - only this script does not work for you, but the rest work? How should I know? I need this script to work, it's as simple as possible))) In general, I did not continue the dialogue with the support and closed the ticket.
Then, about a month ago, my ping to the server increased from 45ms to 90ms! I have never had such a high ping to the servers in the Netherlands, the ping has always been within 45-53ms, I currently live in Russia, Moscow.
Knowing what kind of support they have - and as the author correctly noted, it's at level 0 and it's useless to contact him, I decided that I rarely use the server anyway and there's no point in writing to the support. I just made a conclusion for myself - That it's better if I pay more money to someone else for the server and get exactly what I paid the money for, than I will save and use something that actually works poorly.
I will not recommend Delux Host to anyone. In pursuit of money and sales numbers, they lost all quality and customer trust.
It’s not that things broke that bothers me; any provider can have routing or network issues. The real problem is what happens after something breaks.
The core of my review isn’t “oh no, there was downtime” – it’s that once things do go wrong, the support/technical handling is so flimsy that the only reliable way to get traction is to post on a public community like LET and hope the extra visibility magically bumps the priority. That’s not a process, that’s a ritual. If something breaks again, are customers really expected to follow the same script every time: open ticket, repeat the same information several times, then escalate via a forum thread just to get proper attention?
This is a hosting company; people are running personal and commercial apps and sites on these VPSes. If support can’t consistently understand the kind of issue being reported, relate it to similar cases, and proactively say “here’s what’s happening and what we’re doing about it”, you’re not just wasting everyone’s time, you’re actively putting customers’ revenue and reputation on the line. In my case, it’s honestly a good thing I hadn’t moved paid services and higher‑value clients onto this VPS yet, or this would have been an expensive outage instead of just an annoying LET review.
Deluxhost just deserves the red profile picture
https://lowendtalk.com/discussion/211275/deluxhost-x-3#latest
I'm not getting into any back and forth, I've stated [some of] my experiences. I'm also not trying to bash some poor support guy, but I will say there certainly appears to only be one (which may be part of the issue).
I've had more connectivity problems in 6 months here than with all other providers I use added together. I almost said "ever", but I've been doing this a long time and I'd feel guilty making that claim without checking. I don't even care about the overselling or weak cpu or slow disk, all I care about is the actual network.
The amount of time I've spent diagnosing issues and dealing with support makes this hands down the most expensive vps I've ever owned. I don't contact support until it's been a many-days issue because maybe it will magically clear up without me having to spend days repeating what my fucking ip is.
Pardon my french.
Hello again,
I understand the point you’re making, and I want to clarify a few things directly.
First of all: I do not directly manage the ticket department, nor do I follow every single reply in real time. It’s not unusual for some users to contact me privately when they want to better understand what’s going on or ask for a quicker follow-up. When that happens, out of responsibility, I check the case internally and, where possible, try to push things forward or add context.
That said, this does not mean a problem automatically becomes solvable, especially when the root cause does not depend directly on us but on upstream factors.
That being said, regarding the handling of this specific ticket, it’s clear that something didn’t work as it should have. Asking multiple times for information that was already provided is not the experience we want to offer, and there’s no point in avoiding that: it was an operational mistake.
Not due to lack of care or attention, but because the support load and pressure over the past months have been high. This is not an excuse, it’s context. For this reason, we hold weekly meetings with the ticket team to improve workflows, case review, and the handling of network-related issues.
On a broader level, after addressing and resolving the downtime and routing problems that affected our network in recent months, overall stability and node upgrades are our top priority at the moment.
When it comes to transparency, we have always communicated real issues through our status page (currently under restructuring) and, in more serious cases, via email as well. Many customers on LET and other forums rely on us to host important websites and services, and we take that responsibility seriously.
We don’t claim to be perfect, but it’s also not accurate to reduce everything to “things only move when there’s a public thread.” Critical feedback is useful, and this discussion proves that, but our goal remains the same: to improve our service and support without shifting responsibility or making promises about things that are not entirely under our control.
That said, I want to say that all your criticisms will not go unheard. I'm taking note of them and I'm sure I can make support one of our strong points in the short term, especially since new people will soon be joining the team.
Understood. I won’t turn this into a back and forth either.
Your feedback is appreciated. We understand it’s not meant to attack or single out anyone, but to draw attention to areas that, from your experience, didn’t meet expectations, especially around network reliability.
I’m not going to argue your conclusions or try to reframe your experience. Feedback like this, when it comes from someone who clearly doesn’t contact support lightly, is valuable to us and helps highlight where improvement is needed.
Appreciate the context on support load and improvements, but the latest ticket update from a new rep (Lorenzo) crosses into gaslighting territory, so the 48-hour "normal process" test is off, no more waiting. Here's the full, unedited ticket exchange for complete transparency (IPs redacted where private;some hops were removed for making it shorter, VPS IP as [VPS_IP])(Tried to keep it as short as possible so some details and contents may have been left out). Judge for yourselves if this is "high load" or basic reading failure.
Original Ticket (My opening message)
Alessandro Fiorenza (first rep, multiple asks for "server IP")
Lorenzo D'Ercoli (new rep, "misunderstanding" claim)
My response highlighting the quotes
Exactly as I said: they asked for "server IP" twice despite it being front-and-center (subject, body, MTR). Now it's retroactively a "misunderstanding" about needing my source IP? My opening ticket already explained VPN works but home ISP doesn't complete with MTR showing the drop. No gaslighting needed; just read the ticket and swap the IP if it's a known routing hole. Additionally, asking me to provide “the affected IP” as if this were one clean source IP. In reality, that would be hundreds of addresses from multiple ISPs. And even then, handing over a pile of residential public IPs to a company that can’t properly read a single ticket doesn’t exactly scream “good idea” from a privacy or competence standpoint.
Ticket ID: #YGW-160709. Public thread pressure got a response faster than the ticket did, which proves the point. For a hosting company, this level of back-and-forth on a simple reachability report risks real business loss, glad mine was low-stakes.
Hello,
I just saw your ticket and now I understand the overall situation much better.
I want to clear up the context properly, because there seems to be a wrong assumption forming here.
First of all, we do acknowledge that the very first phase of the ticket was confusing and that this part was on us. Re-asking for information already present in the ticket and requesting VPS credentials for a routing-level issue was not appropriate and should not have happened.
That said, the idea that things are moving faster because of pressure from LET is simply not accurate. What is actually happening right now is that our network technicians are actively working with our upstream/transit provider. This is not limited to a single ticket or a single customer, we’re in a phase where multiple routing paths are being reviewed one by one, correlated, and fixed together. That’s why several routing-related cases are progressing at the same time.
Regarding the request for the IPv4 source, the diagnostics provided in the ticket (ping and MTR) were performed over IPv4. IPv4 and IPv6 routing are independent, and an MTR is a snapshot of a specific path. To properly validate and escalate a routing issue with an upstream, the source IPv4 used for those tests needs to be confirmed, otherwise you risk analyzing a different path or subnet altogether. That’s the technical reason behind that request, not an attempt to stall or shift responsibility.
We understand how, from the outside, the timing can look suspicious, but this is the result of upstream-level work currently in progress, not forum visibility. The ticket remains the place where the investigation is tracked and resolved, and that’s where updates will continue to be posted.
Post or no post, we don't care, we'll keep working and doing our best.
This isn’t about dismissing criticism. The initial confusion was real, and we’re addressing that internally. This message is simply to explain what is actually happening now and why, Improving and making our support even more efficient remains our top priority.
I will ensure that situations like this remain isolated cases.
The source IPv4 context was already in the ticket, attached to the MTR/ping outputs you reviewed. That makes this retrospective clarification a bit odd,perhaps it should have been the first response, rather than the credential request that came instead.
Confusing how? Plain English: reachability dead, traces dying at specific hops, multiple confirmations. Unless "confusing" means "didn't bother reading past the subject line."
Right, and it has already been established that this is a widespread, known routing issue affecting multiple users, as you and others have pointed out yourselves. In that context, after reading the ticket, the response should have followed whatever standard process you supposedly have for dealing with this type of routing problem (if such a process exists at all). Instead of improvising with irrelevant requests.
Since other customers are affected too, were they also asked to hand over their VPS root passwords for an upstream routing issue, or was that privilege reserved just for this ticket?
The core criticism still stands: the ticket clearly outlined the symptoms and observations. A competent technical support flow for a routing/blackhole problem is: confirm the path, confirm the test source if needed, escalate to the upstream, and keep the customer informed. What actually happened was: ask for VPS IP and root password for a network‑level routing fault, and even ask for IPs of the customer’s own clients (affected IPs are in hundreds ). Lorenzo’s explanation here is closer to what should have been said from the start, instead of the earlier gaslighting attempt and credential‑fishing detour.
Hey, I’ve also experienced connectivity issues with Deluxhost. Most of the time, after opening a ticket, it takes a couple of days for them to resolve the problem. Today I’m facing a new connectivity issue with OVH, so I’ve opened a ticket and hope it gets resolved soon. Overall, I’m satisfied with their services.
I'm a bit torn because on the one hand I'm perfectly happy with my (rather old, 'F' series I think) @DeluxHost VPS but on the other hand there obviously seem to be some problems. My guess is that DeluxHost (the boss) is in the "support techies" trap as well as in a way a victim of their sales success/rapid growth.
Let me explain (but again, what I say is based on but my guess): It's probably an unhappy "marriage" of two problems, (a) good support techies aren't dirt cheap, and (b) with growth comes a need for more support techies.
I don't have the slightest idea about DeluxHost's financial situation, or in other words, their ability - and will - to employ good support techies and in growing numbers. Another factor is that (just my guess) DeluxHost seems to grow in waves and rapidly which causes a problem with each wave (promo) because support requests are not equally distributed over time; the first time after sales is support intense while after a while support load significantly decreases. Plus, to make it worse, DeluxHost (to the best of my knowledge) isn't a big player yet which boils down to that each promo brings a rather huge number of VPSs in relation to what they already have. Counter-example to make my point clear: if a large provider like say, Leaseweb with hundreds upon hundreds of nodes sells VPS on say 10 or 20 new nodes, the support requests wave rolling in is but a "hiccup", but with a (still) small and young provider the same wave is almost drowning the support.
IMO DeluxHost should focus on solidifying his operations, ironing out any kinks, develop a good support strategy (incl. psychological considerations like e.g. responding in a way that looks canned and/or bureaucratic to a new customer brings a high risk of pissing off customers) - rather than selling, selling, selling ever more.
Btw, DeluxHost, I also think that your strategy isn't smart. Don't get me wrong, it obviously was good and quite successful for the start (it made you "visible"), but in the long run "cheap, cheap, cheap!" isn't a good strategy (unless you have loads of money and can and do hire plenty enough and plenty experienced and good - read: not cheap) support techies, etc.)
IMO you should think and think hard about the right "balance", the sweet spot that is "what's my current retention/renewal rate and would my customers accept a somewhat higher price but be more satisfied overall?".
When you require customer intervention to diagnose every problem you create a positive feedback loop in your number of tickets.
Recommend to make it your goal to solve problems with as little customer intervention as possible, and verify your solutions have worked before you present them.
If you continue to ask the client "provide more information" and "try it now" every ticket will multiply 3 and 4 fold increasing the workload for your techs and the dissatisfaction of your clients.
My VPS was all good, and connectivity was excellent for what I needed. But since this post, my VPS has been having upstream connectivity issues as well. Not saying the two are related. Upstream connectivity to a server in the Netherlands is impacted.
I created a ticket (GZT-07376), which was promptly put on hold. I replied to move the ticket back to the working queue, and I got the AI Manual Review email again. Please, @DeluxHost, look into the issue. All details (including MTR reports) are provided in the ticket.