Secure Dragon P512VZ DDoS Protected in Portland, OR.

[shovenose]

I was having some problems with my four shared hosting nameservers getting knocked offline.

I moved three of them to DDoS protected providers. One of them being on SecureDragon.net.

Uptime and Stability

My SecureDragon VPS has not had any extended outages. I don't monitor nameservers so often, only like every 5 minutes, so I wouldn't notice any minor blip. I don't know if it's ever actually gotten DDoSed ever since switching the nameserver over to them but if it hasn't, they did a great job filtering it.

Performance

I do not care about benchmarks. However, the VPS is responsive whenever using SSH, the WHM DNSOnly interface always loads promptly, the load is always very low or nothing, and I remember that WHM DNSOnly installed quickly initially.

Support

I have had several queries. Both times, Joe responded promptly, courteously, and was helpful even though the service is unmanaged. 

Other

Secure Dragon LLC. has clear, understandable, fair terms and policies. They just got new ones I think, which I read, and I was not confused or put off by anything.

I typically use PayPal but according to their site they accept credit cards (Stripe) and bitcoins (BitPay) which is nice.

Oh, and it's cool they have their own control panel. It's called Wyvern and it's sort of like ModulesGarden's SolusVM in WHMCS module. No separate login required. It's not super flashy or sexy but it's functional and professional.

Conclusion

Secure Dragon VPS hosting is solid, secure, and highly recommended.

 

[sv01]

I was having some problems with my four shared hosting nameservers getting knocked offline.

please left hosting business completely.

 

[HalfEatenPie]

please left hosting business completely.

No need for this.  

 

[texteditor]

I'm glad I'm not the only one who thinks dd/cachefly tests aren't terribly helpful.

I really, really wish SecureDragon's pricing scaled in a more linear way for resources, it's hard for me to justify the prices on the more 'premium' services compared to RamNode/BuyVM when included bandwidth is always locked at 500g with increases billed at $1.5/100GB; maybe this is indicative of less overselling but idk.

It's a shame because I really like them as a host

 

[shovenose]

I'm glad I'm not the only one who thinks dd/cachefly tests aren't terribly helpful.

I really, really wish SecureDragon's pricing scaled in a more linear way for resources, it's hard for me to justify the prices on the more 'premium' services compared to RamNode/BuyVM when included bandwidth is always locked at 500g with increases billed at $1.5/100GB; maybe this is indicative of less overselling but idk.

It's a shame because I really like them as a host

I actually started out with a 256MB and then upgraded to a 512MB for a bit more headroom.

I don't understand why the 512MB is exactly double the price, when it only has 5GB more disk, a tiny bit more bandwidth, and the same amount of CPU cores. That said, I didn't really care because price and benchmarks don't tell the whole story.

 

[KuJoe]

I'm glad I'm not the only one who thinks dd/cachefly tests aren't terribly helpful.

I really, really wish SecureDragon's pricing scaled in a more linear way for resources, it's hard for me to justify the prices on the more 'premium' services compared to RamNode/BuyVM when included bandwidth is always locked at 500g with increases billed at $1.5/100GB; maybe this is indicative of less overselling but idk.

It's a shame because I really like them as a host

Bandwidth has always been my biggest concern because we don't buy 1Gbps commits at a time so overages are a real thing for us especially with 95% billing. One day we hope to be half as big as RamNode or BuyVM and have much larger commits with excessive amounts of bandwidth but the truth is that we see overage fees more often now than before (luckily the overages aren't enough to warrant a bandwidth upgrade yet).

I actually started out with a 256MB and then upgraded to a 512MB for a bit more headroom.

I don't understand why the 512MB is exactly double the price, when it only has 5GB more disk, a tiny bit more bandwidth, and the same amount of CPU cores. That said, I didn't really care because price and benchmarks don't tell the whole story.

The resources used to scale properly when we had the 128MB of RAM plan available but instead we lowered the price for the 256MB plan and dropped the 128MB plan and the 256MB plan was 1.5x the cost of the 128MB plan so it made sense. We opted to lower the price of the 256MB plan and keep the resources the same instead of scaling the resources down.

 

[shovenose]

Bandwidth has always been my biggest concern because we don't buy 1Gbps commits at a time so overages are a real thing for us especially with 95% billing. One day we hope to be half as big as RamNode or BuyVM and have much larger commits with excessive amounts of bandwidth but the truth is that we see overage fees more often now than before (luckily the overages aren't enough to warrant a bandwidth upgrade yet).

The resources used to scale properly when we had the 128MB of RAM plan available but instead we lowered the price for the 256MB plan and dropped the 128MB plan and the 256MB plan was 1.5x the cost of the 128MB plan so it made sense. We opted to lower the price of the 256MB plan and keep the resources the same instead of scaling the resources down.

So if everybody on this forum buys 1000x VPS prepaid for a year, you can expand and give everybody more bandwidth?

In all seriousness, I understand what you did. Another thing, what's with the small number of CPU cores? I don't have a problem with it, but there must be some logical explanation...

 

[KuJoe]

So if everybody on this forum buys 1000x VPS prepaid for a year, you can expand and give everybody more bandwidth?

In all seriousness, I understand what you did. Another thing, what's with the small number of CPU cores? I don't have a problem with it, but there must be some logical explanation...

We're actually planning on renegotiating our contract in our Tampa location where the bulk of our clients are so hopefully we can make some changes to our bandwidth allocation in the future.

We've been talking about changing the number of CPU cores for a while and I just finished a new script to prevent CPU abuse (it will throttle people who use 100% of their cores for 4 hours) so we'll see how it plays out. A lot of our nodes still only have 8 cores total and some people like to buy multiple 64MB VPSs and max out the CPU cores which leaves nothing left for everybody else which is why I wrote the new script to automatically throttle people who abuse a shared resource.

 

[shovenose]

We're actually planning on renegotiating our contract in our Tampa location where the bulk of our clients are so hopefully we can make some changes to our bandwidth allocation in the future.

We've been talking about changing the number of CPU cores for a while and I just finished a new script to prevent CPU abuse (it will throttle people who use 100% of their cores for 4 hours) so we'll see how it plays out. A lot of our nodes still only have 8 cores total and some people like to buy multiple 64MB VPSs and max out the CPU cores which leaves nothing left for everybody else which is why I wrote the new script to automatically throttle people who abuse a shared resource.

I was not complaining you have your reasons for it all.

The Portland location is awesome as it is.

Sounds good, though!