Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Gravitl (YC W22) – VPN Platform Based on WireGuard
209 points by afeiszli on Jan 5, 2022 | hide | past | favorite | 109 comments
Hi HN, this is Alex and Dillon from Gravitl, based in the mountains of Asheville, North Carolina. We built Netmaker (https://github.com/gravitl/netmaker), a virtual networking platform for cross-cloud computing and Kubernetes. It’s secure, automated, and extremely fast.

Networking across environments is hard and slow. WireGuard can solve this, but it’s tough to run at scale. WireGuard is a fast and efficient VPN protocol that is growing quickly in popularity. Linus Torvalds called it a “work of art,” and it was added to the Linux kernel in 2020. It now runs on most major operating systems.

We created Netmaker to automate WireGuard-based networks at scale. It opens up a bunch of use cases that are otherwise infeasible. With Netmaker, our users are managing edge networks, connecting fleets of unmanned aerial drones, and cloud-bursting k8s clusters for machine learning.

Alex got the idea for Netmaker while he was in New Mexico, staying in the desert to escape the pandemic. We were trying to run a distributed Kubernetes cluster. Our goal was to create a cloud provider with no infrastructure, using compute provided by users. To start, we bought a couple raspberry pis and some cloud VM's, hooked them all together, and ran a k3s cluster across them using WireGuard.

We realized we needed a mesh VPN to do this at scale. None of the existing options gave us everything we needed, so we built Netmaker. We put it on GitHub, and it became so popular that we decided to work on Netmaker exclusively.

Netmaker works on a client-server model (https://docs.netmaker.org/architecture.html). A central config server tells each machine where its peers are and how to reach them. The local client automates network settings and DNS on each machine. The result is a flexible virtual network that stays in sync whenever machines are added, removed, or there is a change in state.

Without Netmaker this is challenging, because WireGuard requires reconfiguration whenever any peer in the network changes. In addition, the network can be blocked by factors like NAT, firewalls, and port availability. Netmaker anticipates and solves for these factors, while being compatible across Mac, Linux, Windows, and FreeBSD.

There are other solutions out there with similarities, but we’ve got some key distinctions. After all, we created Netmaker out of necessity, because the other solutions didn’t meet our requirements. First off, Netmaker is super fast because it can use kernel WireGuard. There are some other WireGuard-based solutions like Tailscale, but they use userspace WireGuard, which is much, much slower.

Second, Netmaker is tailored towards the cloud and Kubernetes. Stuff like OpenVPN was built before the cloud became a go-to deployment strategy.

Finally, Netmaker is fully self-hostable. A lot of existing options are SaaS, but our users want control of any servers that are routing their traffic or managing their virtual networks.

As for what’s next, with Dillon at the lead, we’re putting in a lot of work to overhaul the code base, implement community-driven features, and pull Netmaker towards a “pure WireGuard” vision. We're planning an enterprise release in the coming months which will have a few features that businesses need at scale, without taking away from the free community version. In the meantime, we have a simple support subscription for the existing community edition: https://gravitl.com/plans.

We’re always looking for ways to do things better. If you have thoughts, we’d love to hear them, and if you’re doing anything cool with WireGuard that could be relevant to our project, we’d love to hear that too. We’ve also got a community on Discord you’re welcome to join at any time: https://discord.gg/zRb9Vfhk8A

Thanks for reading, and Happy New Year!




Congrats on the launch!

A couple questions from me, if you don't mind.

I currently use Tailscale for my home lab. My current model is similar to old-school road warrior VPNing, where I have my router as a node that routes to the LAN using the internal (non-meshed) IPs. Does your solution support that? How easy is it to deploy and configure it in that way?

Another feature I use is "exit nodes", i.e. my router as a gateway to the Internet, similar to what consumer VPNs (Mullvad, PrivateInternetAccess, etc) do. This offers me 2 things: more security when I'm on insecure networks (airport or other public WiFi, etc); and allows me to access things as though I'm at home when I'm traveling abroad. This is a one-time configuration and I can easily switch it on and off on demand via the desktop or phone app. Is this an option in your product?

Edit: s/customer/consumer/


This is probably the #1 use case among our users, so yes it is totally do-able. Depends a bit on the router, since we don't support the full range of OS's yet, but if it is FreeBSD-based or OpenWRT you should be good to go. Otherwise, any Linux computer in your home network can act as the router to the LAN.

I believe we actually had a feature like exit nodes before Tailscale released theirs :) Our is called an "egress gateway" and it acts in pretty much the same way.


My router is indeed OpenWRT-based, but even if that was not directly supported I can run LXC containers on it.

Thanks for your reply, I will try to deploy Netmaker alongside Tailscale and compare for my needs!


Sounds good, let us know how it goes! And be sure to do a speed comparison too :)


What about routers that support wireguard natively, such as Mikrotik?


Routers are hard because they all have their custom OS's, and we need to do system level stuff besides just WireGuard. We're open to expanding the range where needed, and will happily support anyone in the community who wants to port the client to a new OS, but for now we're sticking to OpenWRT and FreeBSD as the supported routers.


Does "FreeBSD" include pfSense and OPNsense, especially in terms of UI integration?


do you have a write up or blog post on your setup?


Not really, but it was very simple and easy.

The "hardest" part is managing the tailscale installation on the router, since the OpenWRT packages seem to be quite old. I went old-fashioned and just download the ARM tarballs and uncompress them.

I lifted the init.d script from someone else's blog post [0] and adjusted the path to the binaries.

After that I've pretty much just followed the official docs to implement LAN routing [1] and the exit node [2], then set the router's cert so it doesn't expire, which is done on the Tailscale GUI.

Install the app on the devices, connect everything to the tailnet and Bob's your uncle.

[0] https://willangley.org/how-i-set-up-tailscale-on-my-wifi-rou... [1] https://tailscale.com/kb/1019/subnets/ [2] https://tailscale.com/kb/1103/exit-nodes/


I don't think we have one specifically for a setup like that, but we have lots of tutorials here: https://gravitl.com/resources


https://netmaker.org/_images/node-details.png

Shown on the marketing pages, the controller supports pushing configurations which include commands for `postup` and `postdown`; does this mean that it implicitly has root code execution on every participant in the network? I don't think it would be designed like that, but I'm a bit confused how this could be working without introducing that as a concern.


You're right, and that's definitely a concern for a lot of users. The idea is you should be able to set any WireGuard configuration file setting from the server, including PostUp and PostDown, which are just arbitrary commands.

However, we're adding a switch for this pretty soon which will allow disabling the edit-ability of those fields.


It should probably be loudly default-disabled or outright removed, that's a very, very unexpected feature. It's an unprecedented tool for moving laterally and gaining gigantic amount of access within internal systems. Nobody could possibly build a secure network around a VPN where the controller can bypass all isolation, containerization, and all access controls through a web interface on another machine.


Totally fair. You've convinced us to put that into our next release. While that's a big flaw it's a simple fix, and it should be in the code base by the end of the week.


Well done.


Agreed. That's a bit terrifying!


The contrast on that image is really low, so it’s hard to read.


The Linus "work of art" quote is slightly misleading. Here it is with more context:

Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn’t perfect, but I’ve skimmed it, and compared to the horrors that are OpenVPN and IPSec, it’s a work of art.


Apologies, didn't mean for that to be misleading. Still, he got it into the kernel in record-time for a new feature, which has got to be saying something.


Yes, Linus said, compared to a turd, it's a work of art. Very misleading quote.


Congrats on the launch! Could you expand a bit on how you differentiate your product from other products in the space like Tailscale and Nebula?

Edit - I see you mention that Tailscale uses userland WireGuard. Is that the biggest difference between the two? Do you foresee yourselves running into issues by not using the userland implementation?


The biggest differences with Tailscale are that you can use the kernel version (speed) and that we are self-hostable. We actually noticed a major contributor to the speed difference between us and them was a lot of times, they'll route traffic through their relays which can eat up a good amount of time.

With Nebula, they're a lot closer on speed, but also we've got a management GUI which makes things a lot easier. We were very close to using Nebula in our early days. The main thing that stopped us was, we decided WireGuard was going to be the standard in the future, and wanted to be based on WireGuard.

That leads to a bit more fundamental of a difference which is a bit harder to quantify. Our aim is to really be a "WireGuard controller." You should be able to shut down our server and agents and your network should still run fine, and you should be able to manually modify all your WireGuard interfaces if necessary. We're getting close to that vision but aren't quite there yet.

That last point leads back to the kernel thing. We use kernel by default, but really, Netmaker can use any WireGuard implementation. If users are scared of the security implications of using kernel, they can use the userland version, and Netmaker should be able to pick that up just fine. They can even run it in a docker container on their machine.


(coauthor of Nebula)

We briefly considered building something atop Wireguard in the early days of Nebula, but decided not to do so because of scaling. Wireguard's protocol necessitates that all nodes have existing keypairs for each other ahead of time. At Slack's scale, that means every time a fresh node is launched, you would have to tell 50,000 other nodes it exists.

Obviously you can smarten this up and tell only hosts it might talk to. But this adds complexity. Using PKI eliminates this key distribution problem and means that you don't have the same scaling limitations as something built on WG.

Wireguard is a very very good VPN, but I cannot imagine trying to run something on the scale of tens of thousands of nodes when you need such complex coordination systems to exchange keys/trust, especially in a dynamic environment where nodes are coming and going all the time.

I totally get that it solvable overall, but Slack has had 4 years of nearly perfect uptime on Nebula, whilst using it to pass >95% of all backend traffic. These considerations may seem simple to address, but there are fundamentals that mattered and led us to writing Nebula. We didn't want to create something new, but to do what Slack needed, we had to.


This is great! Can you also compare to Headscale and Zerotier?

How do you handle NAT compared to these other options? I've run into issues with WireGuard when both sides are behind residential NATs (or AWS EC2 IGW); as you know, Nebula solves this with "lighthouse" servers (which are self-hosted but externally accessible), and Tailscale uses its third-party intro devices.

Do the Gravitl servers have to always listen on an exposed port?


It is way, way faster than Zerotier. Headscale I am less familiar with, and they do make Tailscale self-hostable, but they're a community-driven project I'm not sure how reliable it'll be long term (can't speak for the author).

On the NAT side, we provide 3 layers of traversal options:

#1 (default) port forwarding: This actually works in a surprisingly well, for about 90% of environments, but does require an exposed port.

#2 UDP Hole Punching: The server acts similarly to a Nebula "lighthouse" and will tell clients where to reach each other. This covers that small situation of dualing NAT's, and doesn't require the exposed port.

#3 Relay: In situations where neither works such as CGNAT, you can set a public node as a relay to route traffic to the "hidden" node


> but they're a community-driven project I'm not sure how reliable it'll be long term

Don't take this the wrong way, but subtly/implictly implying that some software is not going to be reliable in the long run because it only has a community behind is low-key FUD.


Nahh you're right, that's not a fair criticism at all, and we rely on tons of community-driven stuff. I only meant that as a differentiator because to some companies, they need to know there's a company behind the project for support purposes or they're not gonna use it (whether or not that's fair of them).


Tailscale has some functionality to automatically determine what flavor of NAT traversal is necessary, this isn’t a big deal but do I have to configure the nodes to use these methods or will your client figure this out itself?


Right now you need to choose your own option. We're planning to automate this in the next couple of months. I will say, this isn't always a bad thing. We have a lot of users who switched from Tailscale because it was frequently falling back to relay, often via public relays that were hundreds of miles away from them, causing big increases in latency. We want to give people the automation, but also the choice.


Good idea! I’ll have to give this a spin, I like the idea of “nebula but wireguard”.


Awesome, thanks!


> You should be able to shut down our server and agents and your network should still run fine, and you should be able to manually modify all your WireGuard interfaces if necessary.

This is excellent.


Can you compare to innernet from tonari?


Mainly we give a lot more configuration options as well as a GUI. I'm also not sure if they run on anything other than Linux (I think not?). We can run on Mac, FreeBSD, and Windows. If you're just looking to create a pure mesh network with linux-based devices, they're definitely comparable and I think you'd just have to try out both and see what you like more.


Pretty exciting stuff! This looks really interesting. I have a similar with setup hosts in the cloud, in the office, at home, and on UAVs with cellular internet. It was important that the hosts 'see' each other and it works on IP level in any direction.

When I set it up, I have chosen ZeroTier instead of WireGuard. It does the following: (a) Hosts discovery and initiating handshake between clients with the help of a server from ZeroTier, (b) NAT hole punching, (c) pushing centrally managed routes to hosts, (d) network ACL rules. I primarily have chosen it because it is easy to setup by anyone (e) and I do not have to manage a server (f).

- Can you tell a little bit how Graviti compares to it. I guess WireGuard itself does not have the features (a) to (f). I guess the Netmake server replaces the ZeroTier servers and provides some of these features.

- Are you inclined to install Netmaker client on any host or use one node in a LAN as a router?

- Is this more geared to servers/professional managed hosts or also for laptops?

For my usecase with ZeroTier I found the following currenlty missing features useful:

- Easy setup of a node as a router (or virtual switch) to connect a local network to the virtual one without installing it on all devices (hardware like GPS receiver do not allow to install new software). Of course, you can do it with the normal Linux tools.

- Installing it only inside a Docker container and not on the host. But I guess that will not be possible because it has to live in the kernel.


For your points: a) We handle host discovery via the Netmaker server b) We do NAT hole punching with our own implementation on the server c) Yup, we do this too d) No ACL's yet, but this is coming in the Enterprise version e-f) We don't have a SaaS version at this point, but server deployment takes about 5 minutes, can be run on a $5/mo VPS, and uptime has been production level in our tests.

Router is obviously preferable when routing to LAN but is harder to support. If it's FreeBSD or OpenWRT, go router, but otherwise a client on a Linux node works fine as a router.

This is definitely geared more towards servers/VM's etc, but does work on Laptops as well. We have Windows support and you can even loop in your phones.

We do actually have a docker image for the client. We're not strictly tied to the kernel version of WireGuard, and you can use userspace wherever it is a necessity.


Thank you for being a real company working on something interesting and not some god-awful NFT thing


don't worry, we're saving that for v2.0 (jk)


Congratulation on the launch!

Quick question, does Gravitl plan to become a company donor to Wireguard in the near future[1]? I think it would be great if companies which, as is their right, profit from FLOSS, also give back to FLOSS, not just with code.

Again, good luck with your adventure :) .

[1] https://www.wireguard.com/donations/


We would love to become a sponsor once we have the resources to do that. You're totally right in all regards about this. Without Jason and WireGuard, we'd be nothing. You just convinced me to send a donation but obviously at this stage it can only be a drop in the bucket.


That's great! I fell in love with Wireguard after using OpenVPN for years and donated a small amount. Sure they're drops in the bucket, but they add up if more people get out of the mindset that their contribution is negligible. What's more is the author can get some form of feedback.


Very true. I could see WireGuard turning into something at the level of Kubernetes, where there is a gigantic ecosystem built around that core piece of technology, which everyone needs to support.


This looks interesting, but I don't think I can legally use it for my use case if I'm running it on Linux? (Small VPN shared with a few friends - right now we use Tinc, which is nice but a bit of a pain to configure.) It looks like I'd have to provide Linux under the terms of the SSPL if I let anyone besides myself connect to a VPN running this, which I obviously can't do because it's GPL.

I'm not expecting that I'd actually get into trouble for running a small network with my friends, but I prefer not violating software licenses. :)


I am not a lawyer, but the only point of the SSPL at this stage is to prevent direct competition from companies who would just take the project and sell it as their own. It's the same license used by MongoDB. That said, it's on us to make this as clear as possible, and we'll work with our lawyers to do that. We want people using this wherever they have a need for it, and they shouldn't feel threatened by the license.


Yeah, the big difference between this and MongoDB is that MongoDB is typically only ever used on the backend of an application. You generally wouldn't give someone else direct access to your MongoDB instance, but you might give them access to your VPN, at which point as far as I can tell the SSPL distribution requirements would kick in. (Because you're "enabling third parties to interact with the functionality of the Program ... remotely through a computer network.")

This is probably fine for internal usage within a company (as the whole company is legally the same entity) but for individual use it's concerning. Although it might also be problematic if you ever want to give a contractor access to your VPN too.


That's a very fair point. I'll note again that I'm not a lawyer, but our intention is definitely not to limit those sorts of use cases. If it does, we need to make some changes. I'm going to make sure we figure out a clear way that allows people to do this. We went with SSPL because it's a lot easier to start restrictive and switch to more open than vice versa, but we're definitely open to making a change if it's going to prevent regular usage.


Would you be giving everyone in your network direct access to your management gui? If the clients are just running wireguard and their own copy of an interface, would you be fine? Your friends are interacting with your copy of wireguard not Netmaker. (This comment applies to their future roadmap moreso than their current offering.)


If the clients were really only interacting with Wireguard, then... yes, I think you're right. But yeah, their current offering has the clients connecting with the server via a gRPC API, so at the moment I think it's still an issue. Unless you're using external clients[0] for almost everything, but that eliminates a big part of the reason for using this.

Covers the contractor use case I think (provided the contractor isn't running services they intend to expose to you on the VPN), but not my hobbyist use case (both me and a friend share services with each other via our VPN).

[0] https://docs.netmaker.org/external-clients.html


Nice! I was just building a similar (but more specialized) tool for https://aenac.dev

There's a few offerings in this space, some geared toward edge, some toward orgs. For example:

- tailscale https://tailscale.com/download

- Innernet https://github.com/tonarino/innernet

- wiretrustee https://wiretrustee.com/

Care to differentiate from those above?


I've commented on a few of these elsewhere in the thread. Each one has a couple differences like self-hostable, having a GUI, various configuration options, but the main thing I'd like to add is how we're moving the project for the long term (and this is again copy/pasted from another comment I added):

Our aim is to really be a "WireGuard controller." You should be able to shut down our server and agents and your network should still run fine, and you should be able to manually modify all your WireGuard interfaces if necessary.

This isn't something that any of those options allow you to do and I think is a fundamental difference in how we're viewing the scope and role of Netmaker.


I'm a Sysadmin / DevOps / Cloud Whatever and I find the solutions for this problem space seriously lacking.

Most companies choose between not securely connecting their stuff correctly or having a complete mess of an internal network.

So congratz and all the power to you.


Thanks! I came from the DevOps world too and noticed the same thing. There seems to be a disconnect since most people on the developer side never want to touch networking. Beyond what we put in the post, I think there's a big need for more stuff that brings networking up the stack into a space that is digestible to developers.


I know that this is a bit meta but you’ve expressed a thought that had been lurking at the back of mind very succinctly :)


This is a space that's surprisingly ripe for disruption. Cloud providers push 'hybrid cloud' by allowing you to integrate your own machines with their networks- but they maintain the upper hand in that relationship because they own your network.

Tools like this allow users to own their network and avoid that lock in. All that's needed here is auto-scaling integrated w/ various cloud providers, and some canned templates for creating K8s clusters and common services. At that point- we've got a self hosted cloud w/ 80% of what the big guys offer.


Agreed entirely. I used to work in the "hybrid cloud" space, and networking was always conspicuously absent from solutions that are supposed to be cross-cloud. I view it as the missing link in a lot of hybrid/multi/edge cloud solutions.


I'm not sure how the networking works as-is, but OpenNebula (unrelated to Nebula) might give you that sort of thing.


Welcome to Ycombinator :)

I am a user of this solution for my company, and also for my homelab. It works great! Just wanted to say that, and thank you for the open source free as in libre license.


Thanks! Glad you're enjoying it. Feel free to reach out on Discord if you've got any feedback.


In the Enterprise version it would be nice to see:

- Named groups/subnets for a single NetMakerServer (lets say [Users] and [Servers])

- Access control capability: Allow/disallow inter/intra group connectivity. For example, using the previous groups : [Users] can connect to [Servers] only (not other [Users]) and [Servers] can connect to other [servers] only (not [Users]). Basically, for this case, the peer list returned to NetClient's only contain the [Servers]. More generally, it is the concept of public vs private - not sure if this is needed on a group/subnet or individual netclient level.

- MFA requirement for certain Groups. Example: [Users] who have not connected to the network in the last X hours/other criteria will need to MFA (provided by NetMaker+TOTP or other IDP like Okta). Server-server connections will never need to MFA. This is one of those Enterprise security check list items in security reviews.

- Ideally: Ability to run the NetMakerServer on Windows (IIS, Nginx, Apache) without having to launch containers/install VM's.

Congratulation ons on your launch. Will keep an eye on things.


I think you'll be happy with the Enterprise version based on your list, we've had very similar thoughts. One question on the final point, where do you see the need to install the server on Windows? We've had one other user ask for this, but not sure if I see the need.


Company uses Windows exclusively and there are no in-house Linux ops/admin skills. We have good ops/admins resources for Windows and we need to leverage that. A native solution (even if running behind Apache/Nginx) is preferable. In addition this would be a critical part of the infrastructure so we would want that piece to be somewhat familiar to the ops/admin resources for debugging (access the box, restart a service, troubleshoot networking issues, etc).

Edit: This is a requirement for self-hosted but if your enterprise solutions offers it as a highly available service that would by-pass this issue. It would need to be HA and spread in such a way that a single cloud provider going down does not affect things.


I think until we get more users requesting this, it will probably stick on the back burner for some time. We've designed several server components assuming it's deployed on Linux, and it's streamlined for containers. However, if there's an org interested in pursing this (and has some golang + ops skills) it should be do-able with a bit of effort, and we can provide some advice. It might make for a good community project.


> One question on the final point, where do you see the need to install the server on Windows?

Can any client be an egress node?


Currently just Linux machines can be egress nodes.


What is an 'egress node'?


An exit node; if node a is an exit node, node b can route its traffic through a - which among other things can allow access to resources whitelisted to node a's public ip from b.


Really cool to see a Ycombinator start based out of my old hometown of Asheville! Congratulations on the launch, I will keep an eye on the project!


Thanks, and cheers from the Blue Ridge Mountains. I'll save you some white duck tacos.


Haha nice! I’m in Greenville SC now, luckily we have White Duck as well. Even got our own Rocky’s Hot Chicken this year :)


Oh dang, Greenville is great too.


Search for 2fa and two factor return nothing (relevant) on the support page. You want me to serve a web page to administer my VPN without 2fa?

This does look fantastic and like something I dreamed about making a few months ago otherwise. Good work.

*edit: clarity


Currently auth is limited to OAuth integration with Google, Azure, and GitHub, but we'll be building this out in the coming months.


Will the enterprise version be subject to the https://sso.tax/? (Please say no!)


we've actually already got OAuth support in the community version for Google, Azure, and GitHub. The enterprise version may add some extra features, though we haven't determined all of what that will be yet.


As you are making a security product, you may want to remove all references of sudo wget | bash if you want to maintain any credibility.


Why? What can you do with that that you can't do when a user downloads your software via some other means, verifies its hash ... and then runs it as root?


Thanks for providing quite good context in the post itself!

I was just about to ask about differences with Tailscale, which is solving a lot of the challenges outlined in the post, but you answered it:

"First off, Netmaker is super fast because it can use kernel WireGuard. There are some other WireGuard-based solutions like Tailscale, but they use userspace WireGuard, which is much, much slower."

Good luck!


Thanks! That does miss one other key difference, which is that you can self-host our server. Also, we won't route your traffic through our relays, which can make stuff quite a bit slower.


Been using Netmaker for about 6 months now. It is a really fantastic tool. Congratulations and looking forward to see it grow.


Thanks! I appreciate the long-time users who stick with us through the upgrade process (or lack thereof).


Impressive, I am new to coding, but I will definitely test this on a digital ocean server today, and take it for a spin.


Let us know how it goes!


Thank you for posting it here and congrats. Have been wanting basically this ever since WireGuard got merged into the kernel but never found anything suitable. Good luck and happy new year!


Glad to hear it, let us know your thoughts!


So happy for you guys! It's awesome to see a fellow startup from the Asheville-area kicking some butt. Wish you all the best and hope to see you around town more.


Thanks! Asheville FTW. I think I can guess who you are, in which case, I hope all is well!


I’m intrigued but I see nothing about iOS (iPhone). I use Zerotier and it’s iOS app constantly. Without that I couldn’t switch.


One of the nice things about NetMaker (at least that I've seen), is that it supports the vanilla WireGuard iOS app, just without the mesh capabilities and other automation.

I have my iOS client set up with a egress node on Netmaker, it gave me a vanilla WireGuard config and then I passed that to my iOS device.


Thanks, that's great. I'll check it out then. (I use Zerotier as it's the easiest I've found to set up, but even that seems more complicated than necessary).


Very cool. I remember recommending you to switch from nginx+certbot to caddy for an easier deployment :)


That was a fantastic recommendation, and it definitely did make deployment 10x easier. If you ever want to chat, reach out on Discord!


"A central config server tells each machine..."

So single point of failure?


We have a few supported ways to deploy the server in an HA configuration. We've also got additional backup/failover mechanisms in the roadmap, though those will take a couple months.


How do you pronounce your company's name?


gravit-all


How does this compare to tailscale?


Main differences are: #1 Speed #2 It's self-hostable


What makes it faster. #2 I get.


Tailscale uses userspace WireGuard as opposed to kernel. This on it's own can be up to ~50% slower. They also will frequently fall back to public relays, which depending on distance can add on substantial additional latency.


I have a few qualms with this app:

1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

2. It doesn't actually replace a USB drive. Most people I know e-mail files to themselves or host them somewhere online to be able to perform presentations, but they still carry a USB drive in case there are connectivity problems. This does not solve the connectivity issue.

3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the service, is it reasonable to expect to make money off of this?

/s[1]

In all seriousness, congrats on the launch. It looks like you're solving an interesting problem. Having done at least little work on multi-region platforms I can attest to how painful it is. Hopefully your product will help solve this.

[1]: See https://news.ycombinator.com/item?id=9224 if the above doesn't make sense.


1. Our system is only compatible with Windows XP so I don't think this is relevant.

2. USB's aren't a viable long-term strategy. With supply chain issues they are likely to cost $3000/gb this year.

3. This is actually an NFT-based platform. So-called "money" is not a concern for us.

Hopefully the "/s" isn't necessary for this one but I better add it anyway. Thanks for the good words!


I almost paraphrased it to meet your launch a bit better, but then I thought that might be a bridge too far with the sarcasm.

Very glad you're going down the NFT route, solves so many problems.


You had me there for a second. I was about to link you to that comment. :)


I think it's almost a tradition now to reference that comment on any launch.


@afeiszli congrats on the launch.

@vertis, if you are looking at multi-region or multi-cloud, you may be interested in how Ozone solved this for private k8s https://ozone.one/blog/ozone-zitifies-private-kubernetes-dep...

disclaimer: i am founder of a company which builds saas on the openziti open source which Ozone used in their solution as well. however, doesn't seem competitive with this solution from vertis - openziti being built for different use cases.


It's a past life at the moment. Hopefully one day it will be a problem for me again (pre-launch startup currently).


Meh, why would i use your service when i can already self host everything with a simple docker file, in the cloud environment of MY choice

If it was 2004, i would have understood, but this is a problem already solved decade ago

"private slack channel" won't be enough to justify 70 dollar a month


A good portion of people are all-in on deploying everything to a single cloud. We're not really targeting those people/orgs. But there's also a large number of people who, for whatever reason, need to deploy stuff in multiple places.

The existing subscription isn't really what we're looking to sell. We started offering it because some users asked us for extra support, so we created it for them, but really the main product will be the enterprise version in a couple months.


[flagged]


User name checks out.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: