I’ve been using VPS.NET as my hosting provider for two years now (since October 2009). Here’s my experience, the good and the bad.
The building block of the VPS offering is a node: a discrete unit of CPU time, RAM, storage, and bandwidth. These nodes can be deployed as separate servers, or combined together to create a more powerful server. Servers can be upgraded or downgraded by attaching and detaching nodes from them. The CPU/bandwidth changes can be applied without rebooting, but to apply RAM and storage changes, the VPS needs to be rebooted so that the RAM reassignment can happen and so the VPS root volume can be rebuilt. You can bill nodes per month or per day. The daily option is more expensive, but allows you to throw an extra node or two at a server that’s being slashdotted until the traffic subsides — much cheaper in the long haul then monthly nodes. Daily nodes are also a good choice for a throwaway server you’re going to test something on and then scrap. The math suggests that if you’re going to be using the server for longer than two or three weeks, monthly nodes are a better deal.
To further sweeten the deal, nodes are portable across any of their data centers. While you can’t easily migrate deployed VPSes, you can destroy a server in one data center and create a new one in another using the same node. I look forward to the day when we’ll be able to live-migrate running VPSes across the country. Hopefully someone at VPS.NET is working on that…
Initially I had one node and this blog was about the only thing running on the server. Since then, I’ve expanded the services I host to my personal email server (hosting a few domains for friends too), a Git-based personal software forge, some services for Wikimedia, and a few odds and ends. While not a feature unique to VPS.NET, having root on your own server is really nice. Need some software? Install it. Want to tweak the firewall? Go ahead. I’m a hacker, so it’s nice to be able to use my server to just try stuff out and see what works.
Each VPS has CPU and network usage graphs so you can pinpoint busy times and optimize accordingly. There’s also a console for each VPS that connects directly to the offline OS terminal, allowing you to recover from a botched network or ssh config without involving support. While I’d like to claim that I’ve never had to make use of this feature, that would be a lie. I don’t often need it, but it’s there when I do.
Uptime has been pretty good all-around. I’ve had a few outages here and there: a SAN failure that the staff were not properly prepared for, causing a few hours of downtime; a bootloader issue with Debian caused by upgrading to squeeze (arguably not VPS.NET’s fault, as Debian decided to change the boot volume path); and most recently, volume corruption caused by upgrading my node, which the support staff remedied within minutes, but ideally should have never happened. (This makes me a bit reluctant to upgrade again without someone over there babysitting the box to make sure it boots up correctly.) However, these occurrences were not frequent. That’s three distinct issues I can recall since late 2009, two if you attribute the bootloader problem to Debian. This isn’t 100% uptime, but it’s pretty darn close to it, and support is usually quick to respond when problems happen.
I resell a few nodes to some friends and former business partners, and they’ve had very little issues getting started. It takes about 10 minutes to go from purchasing a node to having a running server. When a friend wants another server, I can deliver them their login credentials to a running server within about 15 minutes. That’s pretty cool.
There are a few network-level filtering things one should be aware of. VPS.NET monitors outgoing SMTP (port 25) connections and applies their own spam filtering, rejecting mail if it’s too spammy. Some people might like this since it can protect them from being listed on a spam blacklist if their server gets compromised. Since I run my own mail server and do my own filtering, I wasn’t pleased when this was deployed, especially since it was done so without any communication on their part. Once I figured out what was going on, I was able to opt-out of this filtering by filing a support ticket. I would have preferred more transparency about this change. Finally, as with most hosts, IRC ports are filtered bidirectionally. As I was wanting to use my VPS to run a service that collects data from Wikimedia’s real-time change notification IRC server (essentially just a data stream delivered via IRC) this was a bit of a bummer. They will not budge on this policy, which is disappointing.
Overall, I am a happy customer. Things don’t go wrong often, and when they do support is quick to respond. I’d suggest trying a daily node or two if you want to see if they are a good fit for your hosting needs; they’re only a dollar per day.