Why Helm and not a NAS?

I’ve been very intrigued by Helm pretty much from the day v1 launched. Now with v2 and its reduced price I’m even more tempted to preorder. But the one nagging aspect I can’t shake is how is Helm any different, really, than a NAS with email/calendar/file-sharing capability? Arguably there are some stellar NAS options that can do everything Helm can and a lot more.

I realize Helm might have the edge in terms of ease-of-setup as far an email server goes, but from a functionality and bang-for-my-buck perspective what makes Helm a better option?

Thanks

The biggest challenge for me in setting up the email server is conditioning the IP address so that my outbound emails do not end in the recipient’s spam folder. This is the major reason I pre-ordered the v2 Helm.

2 Likes

I have been using a NAS since before I started Helm so I didn’t think the existence of NAS products obscures the value of Helm. I would never expose my NAS to the public internet.

A NAS is more of a DIY approach like building your own server. As @doodoonut points out, you will need to provide a trustworthy IP address, along with reverse DNS, so outbound emails are accepted by email service providers and make their way to the inbox of your recipient. But there’s more to it than that. NAS vendors historically have not taken security seriously, having been compromised repeatedly and subjected to a variety of ransomware attacks. As I dug into NAS devices, their architectures and the software that runs on them, I saw they lacked a security-first design approach.

With Helm, we start with security from the silicon up, utilizing a hardware root of trust for secure boot and an encrypted file system. Solving for IP reputation with our service and doing automated offsite backups encrypted with keys only the customer has also handles some other pitfalls with NAS devices.

1 Like

Absolutely agree. More importantly - NAS devices are best suited or file storage/access and streaming. They have not been optimized for applications like mail/calendar/contacts. it can be done but I believe the optimal approach is Helm and then use NAS as the “cloud” back-up and file storage. Then you can have everything hosted internally. I put no documents on external clouds.

All good points, thanks everyone.

After an absurd amount of research I finally took the plunge and recently ordered a Synology NAS primarily for media streaming and device backups, though the email aspect certainly factored into my decision as well. I chose Synology in large part because their DSM / OS software seemed particularly well designed.

Having no prior experience with Helm, NAS, Synology, or configuring email servers I’m in unfamiliar territory so I appreciate everyone’s insight.

I am a long time user of both Synology and Helm. As others stated above, I would never expose my NAS to the internet and trying to condition your IP (if your ISP will give you a static address) for outbound email is not as easy as it may seem. I chose Synology after being a Qnap customer because of DSM and have been very satisfied with the experience. Helm has been such a peace of mind solution for me after having run my own servers off and on for years. I was frankly tired of maintaining my own server and all the hassles that entailed but didn’t want to have to trust a “free” service for my important correspondence. Hence Helm. It has been a perfect balance of owning/hosting my own data and having someone else maintain and host the server OS and outbound infrastructure.

2 Likes

Has anyone who’s done the ‘both’ solution used the NAS (particularly Synology) to host a website on their (Helm email) domain? Several comments indicate no (e.g., ‘I don’t expose my NAS to the internet’), but I was wondering if there was a double NAT or pinhole solution someone is using.

I have for very specific purposes and for short periods of time hosted an external website on my Synology. Get a model with at least two network ports, setup the VM Manager, spin up a VM and host it on dedicated hardware (eth1 for example) on it’s own DMZ so that the network port and VM are tied together and then logically segmented on your router/firewall in a DMZ to isolate the traffic. Then configure DNS for your internal hosts to resolve the destination if you insist on allowing internal clients to reach it as well so that they traverse your FW for access to the DMZ as well.

BUT I would still recommend against it unless you know what you are doing from a security point of view and understand the tradeoffs.

“ With Helm, we start with security from the silicon up, utilizing a hardware root of trust for secure boot and an encrypted file system. Solving for IP reputation with our service and doing automated offsite backups encrypted with keys only the customer has also handles some other pitfalls with NAS devices.”

I like the above but without any firmware updates in what is likely nearly or more than a year and knowing that many Linux components that make up email servers have had vulnerabilities I worry. Next month will be 2 years with my Helm and I’ve pretty much written off all the promised features. :frowning:

I hear the disappointment and frustration. We didn’t do as good of a job communicating as we should have. Helm’s firmware is pretty minimal - email, for example, runs in a Docker container. We have monitored and addressed CVEs that have the potential to affect customers in updates over the past year. We haven’t done a good job of communicating this to customers but we will be more transparent about this going forward.

Quite a few updates will be coming to Helm V1 customers shortly after we begin shipping V2 which I’ve covered previously in another thread here on the forum.