I never understand why people think having your files physically in their homes is somehow more secure than a data center.
- You run the risk of hardware failure, which would take days to recover. When your warranty expires, it'd cost you, too.
- Disk failure may lose all your data.
- Fire, theft, or hurricanes may destroy it.
- You still give access to your data to a company, which controls software updates and the EC2 proxy (in this case).
- Many home ISPs have shitty upload connectivity, so your email won't work that well on the go.
- Internet and power outages mean you won't send or receive any email.
- You lose the knowledge email providers get from scale, including ever-evolving spam filters, and a guaranteed clean outgoing IP.
If you really want to control your data, just spin up something like ownCloud (not sure if that's the best solution, just an example). Companies like DigitalOcean make it as simple as point and click.
I'm the first and biggest investor in Helm and I'm on the board. I created email-based Posterous previously (YC funded) and was a YC partner for 5 years. I funded this team because they're high integrity software engineers first, and we built this out of need— a company like this needs to exist because for this to work, you need both great user experience as well as great software.
Helm actually solves this exactly - they already have continuity of service coming in the pipeline, and the product as-it-ships will support encrypted backup/restore out of box, similar to how your iPhone supports iCloud backup.
I've run my own mail servers for Posterous before and it was probably 2 to 10 hours a month of maintenance, software updates, etc. And that's not something normals can do.
The company itself is run by folks who are committed to running this as a sustainable long term business that takes are of its customers and is super responsive to the community. As a board member I promise you we'll do that.
> I funded this team because they're high integrity software engineers first, and we built this out of need
I looked for the founders bio, a company contact info. There is nothing on their site. All I saw was a letter in the "About" section by the founder.
You might have gotten to know these guys after various meetings and due diligence process. There is nothing on their website that sells me on trusting them or the company.
I had to go the "Careers" section to see the location of the company.
When you're in the business of selling trust, you really need to focus on selling trust first and not technology (maybe they're connected ultimately) but I just don't feel I can trust this company based on the materials provided on their website.
What other way is there? Have a button to “let the CEO call me and pinky promise me that the website info is truthful, complete and correct”? Would you believe it then?
That's obviously not what he's suggesting? He's just saying (and correct me if I'm wrong) that, for a company whose business is based in no small part on trust, it's a bit weird to not have any information about any of the people involved in the project.
Hey, since you're here already, I have some questions (in case you're able/allowed to answer them):
What's the base operating system and hardware architecture the box is based on? It says "Linux" on the page but doesn't go into specifics.
Why not just use regular hardware, e.g. Intel NUCs, or even allow people to run your software on their own hardware (like OwnCloud does)?
In Germany there was/is a startup, Protonet (https://protonet.com/), that had almost the exact same idea a while ago. They went bankrupt though and one of the reasons was that it cost a ton of money to design and produce their own hardware, which also looked very cool (orange hexagon!) but didn't provide much added value beyond what a normal, boring-looking compact PC could provide (at 500 € less than their box for the same specs). They also marketed their own OS, which was based on a modified Linux distribution, modified open-source software and a shiny management layer on top as well. They found out that developing and maintaining a Linux fork isn't so easy either, so they eventually canned it. So what's different about Helm in your opinion?
We are using an ARM-based SoC from NXP. We chose this to ensure that the device can only run signed, trusted code by implementing secure boot and signature verification of software updates. We will make a developer program available in the future.
I didn't use Protonet so I shouldn't speculate about what's similar or different about the products. I think we are in a time right now where people have a strong desire to own their data and are looking for a viable alternative to the cloud. They key, beyond building something very private and secure, is in nailing the experience and we're excited to share more about that.
Cool, thanks for sharing that info! While I think your approach is a bit extreme I hope you'll succeed, we need more solutions that put privacy, security and transparency first. It would be awesome if one could run your software on regular hardware though, as I really prefer a securely hosted server at a local data center to a computer sitting in my living room. Also, one year of limited warranty seems rather short for a product that is supposed hold my most important data.
From the technical specs, it's almost certainly the i.MX 8, which as far as I know is not affected or listed on any of the errata for that vulnerability.
You say Helm solves or will solve all these problems.
But if I don't actually need to be able to reach the box in order to use my email - if it will work even when the box is offline, powered-down, stolen, or destroyed - then what, exactly, is the point of the $500 box itself?
It's not privacy, it seems. If it were private, how could it work when the box is offline?
I'm not opposed to a "pay for your email instead of it being ad-and-surveillance-supported" model. I just don't see the point of paying $500 for a box that you're telling me the service will function just fine without.
For $1000 I get 2 boxes I can't use for anything else right now (and still not very reliable inside my home), whereas with Fastmail (for example) I can get an email service for 20 years @ $50/yr that is very reliable. I'm not sure of the value proposition for this thing.
Why do I need to buy a physical box? Cant they give me a dedicated EC2 Micro instance instead? Solve the ISP issue, and the speed/ connectivity/ power etc?
I like the idea as I run my own home server for about ten years now (Nextcloud (calendar, address book, file-sync), DynDNS, XMPP, NFS, IMAP, ...). At first, I thought how you are going to send emails from consumer IP-ranges, but then I read that you are using a gateway with a static IP address. Cool.
I think it is a great idea to have a device which is as simple to use as a router but focused on typical cloud services. As security is a critical aspect of the whole idea, the subscription service is a smart move too. Maybe you should offer a monthly subscription too (consumer friendly).
Are there any plans to start shipping to Europe in the near future?
Thanks for your comment! Yes - we are working on making the product available in Europe early next year. Please sign up for our mailing list on our website and we'll keep you posted!
I like the idea. But can it handle multiple domains? Also, if I put one in my brother's house, can it connect the two and use them as fail over? That will eliminate my worry about outage and backups.
If I can trust someone to do off-site cloud backups of my e-mail, why can't I trust the same person to run a Fastmail-like service so I don't have to have a $500 server in my house to get e-mail?
But that's completely orthogonal to owning a piece of hardware. You could run a managed cloud e-mail service where only the users hold the encryption keys, too. How is this a hardware problem?
> You could run a managed cloud e-mail service where only the users hold the encryption keys, too. How is this a hardware problem?
This is the key question, in my mind. There's only one reason I'd want to own the hardware—to manage/add/create my own services and handle my own backups because I don't trust a company's involvement in these[0].
If this is so tightly controlled that I can't add my own services and I can't restore a backup without Helm's involvement, why do I even want the hardware?
[0] I don't mean that I don't trust them in a privacy sense. I mean that I don't trust them to make sure the backups are actually working and able to be decrypted and restored. Or be able to be restored without their software/hardware. There doesn't seem to be any transparency wrt/ these concerns.
This is a valuable and useful criticism and we're going to talk about this at our next board meeting.
How do you know who to trust? You surely have to trust someone. It feels generally true that we can trust Apple since we pay them for hardware and their ongoing business interest is in protecting their revenue streams through their hardware and iOS app store, which means you are aligned.
Generally for Helm that's a good case. That's why we charge money for this hardware and software: it aligns interest.
Free cloud services are not truly free and that's what most people seem to be OK with... but not all people.
This is the classic trade-off. Open source software you can read the code but usability suffers. For the people on HN, most people can run their own servers, but for normal people that's not an option.
Apple has managed to create a computing environment that is highly usable for normal people. This is what Helm is trying to do too.
I don't see how we should automatically trust them because we "own" the hardware. If its not open source and able to be verified by third parties, what does it matter if we have the "keys"? $500 for proprietary hardware just seems odd considering the goal here.
What’s the intersection between people without the know-how to run their own servers and the people who understand what tech companies do with data well enough to feel that this is a big enough need?
In my experience, the average person doesn’t really understand what GMail or Facebook or whoever do with data or the extent of their knowledge about individuals. Even basic things like lookalike audiences or retargeting across the web regularly blow people’s minds.
I hope this project is successful, partly because that would show that people do understand these things enough to view Helm as solving an urgent need. I wonder if we’re there yet.
We use duplicity for backups so there's nothing proprietary in our approach. There will be more transparency coming in a series of technical posts about how the product works, what open source software we use, etc. Appreciate the feedback - we'll keep this in mind as we move forward.
I understand that this is a new product launch and you can't have all answers to all questions front-and-center on the website on day one. With that in mind, kudos to you and garry for being so active in these threads.
One key principle for Helm is that you always hold your encryption keys to all your data— Helm and outside parties should never get access to that. So the backups are encrypted, and the Helm device itself stores your data in an encrypted fashion on its storage, and has a secure enclave such that those keys never enter user memory space.
Hosted services like protonmail (great option) support some key management but that's rare. Most everyone stores all your data in the clear, and that sets you up for Facebook-style hacks where people just steal a database en masse, and/or leave you open to warrantless wiretap which has been a problem for email services broadly in the past.
I want to point out that email is just the first part of what Helm wants to do. What is super valuable is that Helm can run its own software and add things like distributed anonymized VPN, or file sharing, and these things are all federated in a way that wasn't possible before.
Not everyone is going to care about this, but enough people should. People reading this thread should care: decentralization and federation of this sort is the way we maintain an open Internet. You can take down individual nodes but you can't take down millions of them. That's the ultimate goal of Helm.
Remember, there's no such thing as a cloud, it's just someone else's computer.
> You can take down individual nodes but you can't take down millions of them.
This statement indicates a lot of passion (and I side with it in spirit), but it feels irrelevant and out of place wrt/ this product.
My data is only (available from) my own private Helm server. If mine gets taken down, the existence of millions of other "nodes" doesn't help me. Helm the company can help me with new hardware and my backups, presuming that they're allowed to—but what if they aren't. Then we're back in the same place.
I mean, assuming we’re talking about a government trying to shut down or snoop on an email service –
They’re probably not going to go door to door confiscating millions of devices; the cost to do that would be astronomical. You’d still be at risk if they were targeting you personally, but not if they were targeting all Helm users en masse. That’s a big improvement. And even if you were targeted personally, you’d at least be in a position to defend against surreptitious snooping, assuming that took the form of agents physically entering your home to hijack the device.
Of course, there’s a lot of counterfactuals baked into that scenario. Helm does not currently have millions of users, for one. For another, the EC2-based proxy service run by Helm is a single point of failure that someone could take down, though supposedly Helm will release tools to replace it with your own server. And most problematically, the closed-source software could be silently subverted by Helm in an update, with no reasonable means for the user to detect this, even in theory.
Still, it’s a lot better on that front than most cloud email services.
Then the keys are on the premises of the cloud company. Also data has to be at one time unencrypted in computer's memory. When there is a physical access to the computer you can't do much to ensure your data's safety.
I may not understand how things work, but how can a SMTP server function without private keys? How can it pass the hand shake? Does parent describes different scenario?
Hey cwyers - this is a good question. Our offsite backups use keys that only a Helm customer has access to. They are created during the setup process and stored on a USB thumb drive we include in the box as well as your phone. We will be publishing how this is done using duplicity so people can see the details of how it works.
I don't understand why you're so upset about this. If you don't think the product is a good value for your time and money, that's fine: don't purchase it.
I think Helm comes with some obvious trade-offs, but the product looks nice and I think (judging from other HN comments) there's a market for it. I don't know if it's a large market for this to be a success, but it seems interesting at least, and at first blush the product looks well-made.
I don't think this product is exactly for me as my main email, but it could be interesting as a side email service, or one for really sensitive emails. Depending on the price point, I'd consider purchasing. If the price point is too high or the maintenance costs are too large, then I won't. What's the big deal? That trade-off not working for you or me doesn't mean the product shouldn't exist.
Because it bothers me when someone sells a "secure" product where the security measures are unrelated to the threat model. The Helm server is connected to the open Internet, which means that physical possession of the Helm server is not the only or even main thing necessary to secure it from compromise. Because of how it works, the server still has a dependency on cloud providers -- you need cloud backups and the public endpoint for the ssh tunnel to get around ISP packet sniffing. Since I still need to trust other people's servers for this to work, why the focus on owning your own server?
How would you realistically completely remove the need for the relay server while still allowing the customer to run the server on a typical home internet connection?
Would it be possible to elaborate more on the problems pointed out by the OP of this thread? Like clean outgoing IP?
Moreover what happens exactly when the box melts? Because sooner or later some box will crash. Where will the service run in case of disaster? How long will I stay without email?
It's hilarious how solvable most of these problems are, and yet they aren't even closed to be solved.
Like, backups. Everyone knows how this can be done. Have automated scheduled backups. Encrypt them. Send to offsite storage. This should be handled through a generic backup protocol so you can choose your provider and be sure the app doesn't siphon your personal data.
Users should not need to manually fuck around to set this up for every computer and every app they use. This should be absolutely standard. Preferably built at OS level. I know Ubuntu had something of this sort, but IIRC it wasn't based on an open standard where you could choose your own storage provider. Windows? Hah.
Instead, developers strip users of all control over their data claiming it's for their own good, and push everything to a myriad proprietary cloud solution through random protocols with dubious security implications.
Same thing with file transfer. You'd think it'd be a solved, easy thing by now--a gigantic datacenter/cellphone network is not the optimum solution to allow two people or two businesses to transfer a file between them.
You say Helm literally does this. But what the grandparent was asking for wasn't just backups. They suggest (as I see it) an open standard for backups, ubiquitously implemented so it's easy to switch your provider and easy to set up new devices.
Does Helm use one of those? I suspect not, because I don't know of any such ubiquitously implemented open standard for automatic encrypted backups.
So: is Helm going to put in the effort to define such an open standard and push for it to become ubiquitous?
Even if Helm implements automatic encrypted backups, it's still contributing to a fragmented world siloed into incompatible apps and platforms. Making your siloed service better than others won't fix that problem.
>I don't know of any such ubiquitously implemented open standard for automatic encrypted backups
Here is a question for the parent poster and anyone else. Do you think it would be worthwhile to gather some people and try to design such open protocol? Without having an implementation first? Or would that be just a waste of everyone's time?
Redundancy redundancy redundancy. See e.g. Unison, rsync, sanoid or https://syncthing.net - runs on anything, does a good job.
> You still give access to your data to a company, which controls software updates and the EC2 proxy (in this case).
Because you read all code changes every time you `pkg upgrade` or `dpkg dist-update`.
> Many home ISPs have shitty upload connectivity, so your email won't work that well on the go.
Is that really an issue? I probably use <100kB personnal email per day anyway. Even in the US, 100kB/day upload is not unheard of.
Also, the "on-the-go" issue is DL speed: from your device to your server. How long your server takes to send the mail is mostly irrelevant - instantaneous transmission should be done by phone.
> Internet and power outages mean you won't send or receive any email.
More comments around here about sending servers that MUST retry, and fail only after a few days.
> You lose the knowledge email providers get from scale, including ever-evolving spam filters, and a guaranteed clean outgoing IP.
That could be a real issue, but the ever-evolving filters at my ISP clearly can't spot (nor stop) the spam I receive anyway.
The outgoing IP shouldn't be a problem if you've registered it in your DNS, and it matches the SMTP or whatever subdomain.
> Also, the "on-the-go" issue is DL speed: from your device to your server. How long your server takes to send the mail is mostly irrelevant - instantaneous transmission should be done by phone.
Not commenting on the rest: you download incoming mail from your server, i.e. your home uplink. If someone sends you a photo or zip file, that’s the bottle neck.
Not to mention syncing email with the brain dead protocol that is IMAP…
The cloud ultimately is someone else's computer, abstracted away to feel good. Data loss occurs in the cloud too and it sucks.
It's also dangerous to say because you don't understand or see the value in something, that there possibly can't be any.
Today's home connectivity + LTE fail over is reasonable to rely on. One could put a vps proxy in front of it if you really wanted.
Running a home appliance is not out of the question or unreasonable. I have a Mac mini server that is coming on 8 years of age and zero issues.
Today, the combination of Ubuntu, docker, and ready to go setups make it super easy. Offsite backups are not an issue anymore. Running owncloud is good for files locally, but email is worth it in some cases.
We own a lot of appliances at home that have a lifecycle to maintain already.
The reality is the above issues have a much lower chance of happening than 10-15 years ago.
Hardware is far more reliable and than it was, my 15 year old servers pulled from my data center were still working when I virtualized.
A discovery I made was owning a PDU (like an APC Masterswitch) cleans the electricity so much enough that attached equipment don't seem to fail. I ran my own email server in a datacentre for clients for a long time because it was the norm.
With Home Automation adoption increasing I suspect a home appliance of some kind will become a reality anyways. If personal data became a feature of it, that would be useful.
So what happens when you are traveling and there's a power issue or maybe some other connection issue that knocks this box out of service? Looks like you'll be stuck without email until you can physically get back to this box. This isn't a scenario you worry about with regular email.
The challenge with email is that once you give out any mail address to people, you are on the hook to ensure that it's a functional address. Not something you can just try for 6 months and then easily move on from. And if you decide to move on from this service, will the average person be able to easily migrate that custom domain to a different email provider? (Yes, technically this is possible, but can normal users do it easily? Is it part of the service that Helm provides?)
Not sure if you have spent any time around data centres, but they have to deal with power outages just the same. My power doesn't go out often, how about you?
Backup batteries (UPS') are trivially cheap as well, especially for equipment that sips electricity. Everyone should have one on their internet connection and wifi anyways. A $200 ups can give a few hours of power.
Your offsite worries could be alleivated by mirroring 2 devices, or mirror one to a cloud. Realistically, incoming email is queued for redelivery from 24 to 48 hours until it can be delivered. Beyond that, outgoing email can be sent thru a third party temporarily (migadu, etc). Next question?
Migrating email isn't hard. Most services have import feature. I suspect you may not have done this before.
Yeah, there is no convenient backup policy that doesn't obviate most of the purported benefits of this device. You have to store your backups somewhere off-site to have any kind of data safety, and unless you're dumping out to tapes or some other physical media and stashing your backups in a safety deposit box, that's going to be a server somewhere.
Developers and devops folks can certainly do this, I know I have had to do that before for my production data.
Part of the point (and the impressive software that has been built here) is that backups happen transparently, and if anything ever happens to the Helm you can get another one and get back up and running by restoring from online backups. It's the same principle: things can happen to your iPhone but you can get up and running with a new one easily.
I'm skeptical of this device, but don't follow your reasoning. One of the device's concerns is security and privacy -- what security or privacy am I giving up by giving my backups to Tarsnap?
This was my first thought as well. My email IS very important to me which is exactly why I will never host it locally. The only content I host locally-only is stuff I would be annoyed to lose but could replace, the only content I host locally with online backup is stuff I can do without for a couple of days while I recover. Email falls into neither of those categories, I need it to be up all the time. I have considered fastmail or similar but I will never trust my home connection.
I've been running my email on Helm for the past month with no dropouts of service - it's worked with no issues this whole time, and we use Comcast in SF, so it's not the best upstream there is.
Mind sharing your domain? I'd love to peek at what they do DNS-wise. lvh at latacora dot com if you don't just want to hand it to all of HN :) The e-mail in your profile is hosted by Google, which makes sense because it looks like work email.
Not necessarily.
Incoming email: port 25 is blocked on many residential connections.
Outgoing email: If you send email from a residential IP block you're likely going to be flagged as spam.
I wasn't debating your point; I was pointing out how this service accomplishes it without tripping over that problem. FWIW: I'm not sure that's actually how it works.
The device talks to an AWS EC2 proxy IP that Helm makes sure isn't on an IP blacklist. All traffic that goes through that is TLS encrypted using Lets Encrypt keys.
Elsewhere in the thread, Giri says it uses a VPN connection. Is it TLS + something else?
helm.garrytan.com:3333 for example responds with a self-signed localhost cert, not LE keys. IMAPS (still not sure why that’s there but I asked that in a different comment so let's have that thread there) and 8443 do answer with LE though :)
I think the only times I lost data in the last 10 years or so was because someone accidentally deleted stuff on a shared Dropbox (luckily I had a local backup, so only the most recent changes got lost). Oh and I lost some photos that I uploaded to a Facebook clone because they more or less shut down.
Data loss is more or less a solved problem. You don't need Google for that. ;-)
On the other hand, even without putting my tin hat on: I get customized ads best on my email contents, WTF?! Everybody can see based on the browser ads what kind of sites I'm surfing to.
> Internet and power outages mean you won't send or receive any email.
Except if you have a charged battery and LTE. ;-) In fact just a charged battery is needed when network is down to read old mails.
The original post was about the perils of hosting your mails at home. I'm not clear what your answer is about.
For example, in a power outage, Helm won't work. You say it's not a problem with a charged battery and LTE. I think you're talking about a cell phone and I don't understand how that's related. Sure, one could run Helm on a UPS with LTE backup. But then that's extra infrastructure against the promised simplicity.
Also I don't see how encryption prevents the device from being physically destroyed.
> LTE backup. But then that's extra infrastructure against
> the promised simplicity.
There are low-cost routers with USB ports that allow plugging in an LTE stick.
> Also I don't see how encryption prevents the device from
> being physically destroyed.
You can create a backup and store it on an untrusted storage (cloud for instance).
I'm surprised these devices didn't take off 5 years ago already, as this is technology wise almost a step backwards into the 90s. But I think it's worth it, and in fact you don't need helm to set up a system like this yourself. Get a Raspi, stuff an LTE stick and a juicy USB storage into it together with external USB-battery in passthrough and you even have a superior device.
You are introducing a lot of moving parts to go from 99% to 99.5% availability. And you can't get much better than this at home. In that vein, for most people, the availability of a Raspi solution would be 0%. They just can't handle it.
If you can accept the bad availability Helm looks like a fine solution to get your mail out of the cloud.
Agreed. For a service that is about security, it honestly leaves me feeling very vulnerable, and I wouldn't consider it for that reason. I'm concerned about my emails being delivered, increased spam, a thief (or government employee) walking out of my home with my email server, my modem needing a reboot while I'm on vacation and not being able to send or receive emails, and my neighbor accidentally burning down my apartment, taking my email with it.
I'm a Fastmail user and pretty happy with the service. But, what's the real world benefits of Helm over an encrypted email service, like ProtonMail?
Using a hardware root of trust, secure boot and a Secure Enclave for managing keys used for full disk encryption, it will be very difficult to extract decrypted data from a Helm server. The keys never leave the Secure Enclave, they aren't available to the application processor or memory.
Most cloud-based email services hold email in the clear - we believe this means you don't really own your data. Encrypted email services have challenges around search, access via proprietary protocols and the risks of running highly sensitive operations in client-side javascript.
I mean, sure? You can use encryption to get security and privacy features but "FDE" isn't it. FDE is more important for Helm but that's a problem of their own design: suddenly the e-mail is in a box in my kitchen and it's a lot easier to walk out with a box in my kitchen than it is to walk out with a drive from us-east-2a :-) For anything in the cloud it's a belt-and-suspenders/compliance thing.
How many people have access to drives in us-east-2a? Do you know? Can you verify?
Assuming the software works flawlessly (if it doesn't, it doesn't matter where it runs) you'll need RAM and storage access to recover the keys and the data. If you're in the cloud, you won't notice when insiders or state agencies take a peek. If the device is in your home, you can set it up so you notice.
> How many people have access to drives in us-east-2a? Do you know? Can you verify?
AWS, like every non-clownshoes provider, is transparent about the security controls on its datacenters. It has those verified by independent third parties and auditors (for relevant compliance standards). They have published whitepapers and compliance/audit reports, and continue to.
The odds that someone compromises a Helm update and the odds that someone walks out of us-east2a with a drive are not in the same ballpark.
To reiterate, because somehow I'm in the "FDE is an important threat model!" corner: it is not. Walking away with a Helm is not the easiest way to read e-mail on that thing, especially not for an organization capable of dragnet surveillance in general.
> The odds that someone compromises a Helm update and the odds that someone walks out of us-east2a with a drive are not in the same ballpark.
Sure, but why are you comparing a software compromise against physical access? There are attacks that work against cloud providers which don't work against Helm. If somebody can compromise a Helm update they essentially got root. And that is a step up from just read access to storage.
Here's how I see it: There is a provider that runs my mail infrastructure. They can either run it on AWS, or host it at my home. If the data is in my home I don't have to trust Amazon. I still have to trust my mail provider ultimately, but using AWS doesn't improve on that.
I'm curious about how you arrived at the conclusion that we are capable of dragnet surveillance. Connections to/from the Helm server use TLS end to end.
I mean, the risks exist in the sense they are not absolutely zero, but can you seriously compare an average home to a data center in terms of physical security, connectivity, fire suppression, etc.?
- You run the risk of hardware failure, which would take days to recover. When your warranty expires, it'd cost you, too.
- Disk failure may lose all your data.
- Fire, theft, or hurricanes may destroy it.
- You still give access to your data to a company, which controls software updates and the EC2 proxy (in this case).
- Many home ISPs have shitty upload connectivity, so your email won't work that well on the go.
- Internet and power outages mean you won't send or receive any email.
- You lose the knowledge email providers get from scale, including ever-evolving spam filters, and a guaranteed clean outgoing IP.
If you really want to control your data, just spin up something like ownCloud (not sure if that's the best solution, just an example). Companies like DigitalOcean make it as simple as point and click.