I've been looking forward to this launch for a while.

I've used Bytemark for about five years now (I've got a couple of dedicated servers and a few VPS's), and their technical support is second-to-none. I'm looking to implement my own private cloud, and I trust Bytemark; the last time I had some problems booting one of my servers, I was exchanging tech support emails with the MD. You can't ask for more than that!

Same here. Excellent company - have dealt with them a few times. Can't say enough good things about them.

Interesting, though only Debian support for the clients at the moment. I will begin porting that over to RPM based systems later on tonight. Starting with CentOS.

As a current Yubikey owner, I would prefer if they didn't require a BigV-specific Yubikey with a custom configuration.

Their reasoning: "Yubikeys are a great product, but they trade off the best possible security they could offer for convenience. Instead of demanding that their customers manage their own keys, Yubico program them for you, so that they can verify them later over the internet, and save you the bother of setting up your own servers. That means Yubico keep a giant database of every key they've ever manufactured. They also have the albatross round their necks of keeping the giant database online at all times; if it goes down, none of their customers can log in. Worse, they also need to keep it secure from hackers. The more successful Yubico becomes, the more hackers will be interested in their database. If a hacker got a copy of Yubico's database, he could fake any Yubikey that was ever issued."

More here: http://blog.bytemark.co.uk/2011/07/23/one-last-feature

What gmac said, though his headline could have been better :) We call them V-Keys instead of Yubikeys, because the latter would imply you can use them on any Yubikey-supporting site. And with ours, you won't be able to.

It's a while since I was looking into how they work and my memory is a bit foggy, is there no way to configure them in such a way that they could work for your services and for my own, but without using the official central server?

For example, I use it for SSH authentication, if I had a server with you it would be nice if I didn't need one key to access the control system, and a different one for SSH.

The security of Yubikeys (and RSA tokens, and most other two-factor authentication devices) rely on a shared secret between the authentication server and the devices themselves.

If you wanted to authenticate your own VMs with your V-Key, we'd need to either share the programming secret with our customers, or provide an authentication service that we pre-configure the VMs to back onto. The former would compromise the security of the keys. The latter is a possibility, but not a high-priority one at the moment :)

The keys do have a second authentication slot into which you can program your own fixed password, or another two-factor secret from which you can do your own auth on your own server (to use the second configuration you hold the button for about 4-5 seconds so it's not as convenient).

Perhaps you might some day be able to put your configuration in the second slot? (Again I'd assume, not exactly a priority.) Since I'd expect to be logging into my own stuff (e.g. servers) far more often than the control panel for those servers.

Anyway, looks great overall, will certainly be trying it out as soon as I can, see if a switch from Linode is required :)

Yes, I traded accuracy for recognisability, but I was struggling a bit to work out BigV's #1 USP for HNers. Maybe you could think about that a bit for the front page. To me, "Servers that grow" doesn't immediately distinguish you from Linode et al. -- even if the claim is true to an impressive extent when I read on.

(Also -- hi Matt! We should catch up if you're ever in London.)

It would be interesting to hear about what kind of APIs they are planning, à la Slicehost.

You can download the client and take a look if you want :-) It's nothing particularly surprising, we map most resources to URIs and let you GET/PUT/POST/DELETE them. But it's not documented yet, because we are still changing it, and we're concentrating on improving the command-line interface first.

I think we're actually providing the largest virtual machines of any service in the world - is anyone else doing 120GiB VMs? Probably not. Am cranking up the PR in the next month <g>

Does "1 processor core" mean a dedicated processor core to the VM?

No, they're virtual cores, currently 16 Opteron cores between a maximum of 120 machines. Right now you will get 16 dedicated cores for a 120GiB VM.