Tau: Open-source PaaS – A self-hosted Vercel / Netlify / Cloudflare alternative
github.com
github.com
Right now as I understand it, if you want to connect Vercel securely to a database with more than a password, you need to “contact sales” about “enterprise” (no self service option for demos and MVPs)
Might be a tech issue but imho needing to contact sales about enterprise level deals just for basic security stuff is not the best move since it forces people to expose their stuff or wait around and pay a bunch of money.
Dunno about you guys but I don’t ever click “contact sales” I just go to something else where my dev work isn’t gated by salespeople (even if it’s significantly more complicated) and I say this as a big proponent of Vercel, I wish I could use it more, but expecting users to wait around for sales to invoice them just to have a secure database connection is a dealbreaker for my use case regardless of my opinions or preferences of liking their stuff.
Sources
[1] https://github.com/orgs/vercel/discussions/42
Having put stuff through production though, I'm a bit skeptical about how well it works out in the wild, though I am interested in learning how well it does and what its failure modes are. If it works well-enough, it has the potential for democratizing production apps.
I'm not sure how they are going to make money with their enterprise offering though.
Between Seer and Gateway, the system handles resiliency. Internally, CRDT is used for replication, which: * allows nodes to still work offline or if the network gets partitioned * prevents split-brain
The cons of CRDT are when it comes to orchestrating services like databases; we could end up with multiple instances of a master node, for example. This is why we plan to add a cluster mechanism that will allow the formation of dynamic clusters to facilitate the orchestration of stateful containers and VMs.
For the money part, we have a managed offering, enterprise support, a web console, and are building more.
From the quick look it seems like coolify is more fully featured?
[1]: https://coolify.io/
I’m evaluating some of the options for toy projects so I’m curious to read people’s experiences.
I reccomend you try it but I also think you'll realize you could host that hobby project with half the hardware requirements and half the effort with something like docker-compose or swarm.
And for that it worked remarkably well
My toy server (64ram, ryzen 5600G 60tb HDD, 4tb NVMe) is currently running fedora/caprover, though I've been considering just putting truenas scale on it, as it added custom deployments as well...
It's mostly just for the *arr stack, various self hosted services like vaultwarden, seafile etc and my personal toy projects. I.e. a pwa book reader along with the occasional dev tool I wanna experiment with.
The 6x6TB were previouly in a Synology NAS (roughly 8yrs old now) and I was planning to slowly migrate everything over to 12TB disk's as things start failing
So, being fully featured truly depends on your intended use case.
Some suggestions for this to be able to succeed:
- Documentation, documentation, documentation, the only place where I could that the three supported ways to write a serverless function are with Go, Rust and AssemblyScript is somewhere hidden in a tutorial. It all has to compile to WebAssembly so I guess that's the limiting factor.
- Examples?
- Using git as source of truth for the configuration/state of a system is cool. Please link to sample repos so I can see what a system with a website, some functions that touch DB and files, and the configuration etc looks like.
- How does the database part work? Client SDKs?
- There are lots of protocols with unclear names that are only briefly mentioned here but then seen in random places in configuration: https://tau.how/01-getting-started/01-local-cloud/#protocols
- The Concepts part of the documentation is buzzword soup, it's impossible to derive any meaning from it other than that the author dislikes Kubernetes and probably used some generative AI for the content.
- Roadmap, plans, versioning, plans on how Tau version upgrades should go, ...
https://tau.how/02-concepts/03-one-binary/#the-genesis-of-ta...
"By emphasizing ease and simplification, Taubyte aspires to transform cloud computing into a catalyst for creativity and innovation"
Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected. That 10k bill is roughly $50 dedi from hetzner, but the problem with that is that you need a distributed system, for that you need something more advanced that tau, let's say kubernetes, then you need multi-site storage ok so ceph and then you realize you need a degree in openssh and bluestack to continue on and realize that the hassle from all of that and instead just hire a sysops employee that costs 10k a month and spend $1000+/month on hardware for geo-distribution.
Take this from personal experience. I've personally seen someone go k8s with very little experience and their general consensus was that they just want to go "managed" hosting instead.
Still better than 10k bill once your app becomes large enough, but it's simply not something devs that just want to get something out there want to bother with. In the end even with the insane hosting costs compared to the revenue they bring in is tiny. $10/month service user only racks in around $1 of api usage a month, heavily depends on the app though.
No. There are two pieces to those platforms. The first is a platform that supports git commit as a deploy method out of the box. That’s the big one.
The second is auto scaling. That’s where not having to self host is actually a big deal. But that’s also where the bills come. A lot of smaller builders are right now looking to have the same deploy experience but on their own cheap hetzner/DO server without crazy bandwidth and scaling bills that they can get hit with the moment they let their guard down.
A decent sized player in this field right now is Coolify. They offer a hosted version of their PaaS but without the servers. So the PaaS part itself, coolify, is managed by them but it deploys to hardware that you control. The existence and usage of this plan is evidence of the needs of this market imo.
Git history deployments is a simple k8s controller, pretty sure there's a helm chart for that.
Autoscaling is what I mean by kubernetes so yes totally agree.
Coolify seems pretty neat. Still has the overhead of management when dealing with clustering and multi-site.
Firstly the git history managed via a controller / helm chart. That’s sufficiently complex. The mindset of k8s/cloudnative doesn’t translate easily from the pet vps control server which comes with its own disk and persistence. So conceptually a management layer like cooling is objectively easier.
But that’s a nit really.
I think the idea of management being time consuming is more interesting. It’s true. And I think it’s true no matter what you do.
Time consuming management applies to any sufficiently complex infrastructure or team. No matter what you have these questions to answer.
How is access ma aged?
How does debugging a broken build work?
How does secret and config management work?
How does disaster recovery work?
If you are storing config as code, how are you managing deployment of that?
If you use k8s, how do you manage feature deprecation across versions? Even a managed version won’t help you resolve having to move from some kind of resource/v1beta to resource/v1.
I don’t say this as a slam dunk against anything. I think there are different levels of comfort with certain paradigms depending on what you’ve been exposed to over your lifetime. And the solution that feels most convenient to you is what you’ll want to work with. And for each type of preference we are going to see different solutions. All of which will be time consuming to manage in their own ways at a sufficient level of complexity or scale. Basically I prefer talking in these terms because it shifts the conversation away from broad comparisons to something more tangible which is “where does the time complexity lie for this particular approach”. Teams can put that down on paper and decide which one is more palatable and then go with that.
I definitely do have the experience when it comes to geo distribution and multi-site deployments, but it's something that took me 2 years to build up to and I genuinely think that it's also not something most people have patience for or freedom for. I am lucky that I can afford to experiment with all of these things on my personal cluster and then turn that into something I deploy when dealing with customers.
There's also a third way, which we're trying to do at stacktape[1].
We've built a PaaS platform on top of AWS, running in your own account. So you get all of the stability, flexibility and reliability of AWS, yet the deployment process is easy as using something like Heroku.
Also, compared to Vercel, the pricing is just a % on top of AWS fees, and not a sudden $10k bill, or $550/TB Netflify egress costs.
Can you tell me more about IPFS - I've never used it before. How has that been working, and can you tell me what you've observed when you have many nodes which need to coordinate?
It’s a self hosted Cloudflare.
It uses nats Jetstream , as a work around to Nat having bog / anycast , like how Cloudflare does its magic.
https://github.com/synadia-io/nex
You have to run it on bare metal or any cloud that supports next virtualisation.
I use nats Jetstream listening to git repo web hooks to deploy.
When it comes to scale, ipfs basic discovery mechanism (the dht) does not do that well. This is why we have services like tns (which is a replicated registry) that allows it to scale.
who is actually behind this?
"Samy Fodil"
for the `/tb` folder, I see your point, i would love to discuss it further if you can open an issue on github.
looking at https://www.hetzner.com/sb/:
- you can build a beefy cloud for less than €150/mo!
- plus you can run LLM inference (check https://github.com/ollama-cloud) for another €150/mo per node
not bad!
Why would anyone target Tau serverless, then? What am I missing?
The appeal of serverless for me is simplicity. It abstracts the server away. Less to think about, more brain capacity focused on unique business logic.
That's interesting, because serverless is far from simple and Vercel is about the same distance from simplicity as the sun is from the edge of the observable universe.
Basically a small OS that will prop itself up and allow you to create/adopt into a Kubernetes cluster. Seems to work well from my experience and pretty easy to get set up on.
I also love the single binary in Go. That's on my todo list for a few things.
Well done!
dream allows you to run tau locally and even write E2E unit tests.
we always try to have cool names :)
and if you dont have scale-to-zero, you cant claim a vercel alternative.
Isn't the whole point of platforms as a service (from the customer perspective) that you don't need to do the hassle of self hosting.
There are pros and cons to using an external service and to self hosting. And just throwing all these words at me together makes me feel like there isn't a coherent mental model of what this is trying to be, or if there is it isn't clearly communicated.
If this is some sort of CDN software or attempt at running Lambda-like code Snippets on your own distributed cluster that's cool. But a description of that would be nice.
The GitHub read me jump straight into how this is just a single binary and how deploying it is easy, but not what the hell it is. CloudFlare can do like a million things, which features from cloudflare is this competing with? I just really want to know what the pros and cons of this are compared to other ways of rolling my own servers or renting out someone else's platform?
I like the ideas they are trying, so I wish the best of luck to them. Hopefully, they'll find a business model that is better aligned with the product.
If it works as well as described, then the underlying technology (and the constraints they have) allows it to be self-hosted while having some of the benefits for a managed platform.
Would be nice if READMEs opened up with what the thing was and maybe a one or two sentence problem and solution description.
The initial marketing word usage such as "amazing" put me off at first ("Show me, don't tell me"), as well as how the author(s) poo-poo'ed on Kubernetes. (I've worked on both good and bad usage of K8S, so it isn't always a fairy tale, nor with a bad ending). However, it also read like someone who seemed to have a deeper understanding of infra writing about this, not just a vapid reinvention by someone who works mostly on the front-end, so I kept going with the README.
Having said that, while I am a big fan of IPFS, I know there are performance issues with it. (Maybe Tau set up a private IPFS that is only used within the cluster, which may help it work faster). It also sounds like they are working on general container support, not just Webassembly. Overall, if they keep iterating and improving things based on how things work in production, then they'll end up with a fairly robust system.
Imagine a workload where a client does their own compute, by provisioning worker components locally and retrieving only shared data from your systems - how much cheaper would your hosting costs be?!
There was a different, recent HN post about scoped propogators, which I find to have a lot of good potential for people to write and apply local customizations for their own apps.
I don’t know if those are the killer use case for this, but I think ideas along these lines takes it further out of alignment with incentives for business models.
Having patterns to deploy & ship software, that also can bring up & manage other resources along the way (databases, load balancers, geo-reicatikn, etc etc).
Having CI taken care of by just installing a single package on your own server is compelling.
The main think that they take care of that this probably can't on bare metal is redundancy and uptime and scaling.
I just took a deep dive into the documentation- which is comprehensive - and I feel the complete opposite; the author has a very well refined mental model of a PaaS and has created a modularized source-code expression of that model that I found very interesting. The CI module is called “patrick”, which gave me a chuckle.
You have some good feedback in your post, but I feel like the author may not be trying to replace hosted PaaS; they are essentially using tiny-go to build small distributable wasm modules that can interoperate in a distributed network, which aligns very closely with the localfirst ethos that brings compute and storage out of the datacenter. Does it feel a bit silly to even SAY “client-side CI”? Objectively, yes, but if a future architecture might need to safely deliver code to clients in a mesh this is a really interesting way to experiment with solutions.
I don't know much about NodeJS/React world but to compare with PHP, this is the equivalent of self-hosting an open source CPanel instead of creating a LAMP setup on VPS and working with Linux and PHP directly?
Maybe with such tooling as original post it will be useful in smaller scale.
because a well-configured k8s cluster nullifies the need for this project. also hi!
It's really hard to fault k8s these days, all the original problems are solved and all that remains is necessary complexity that can't be abstracted without lowering power.
That doesn't mean you can't abstract over it, you can and should but you should do so in the scope of your team or organisation where you already know which pieces of power you need/want or otherwise know the way you which you want to leak those capabilities.
So much saturation in this space of people trying to create one off solutions, which on some level I admire. However the further off the main path you go the more you lock yourself into problems you can't troubleshoot or edge cases that aren't supported.
Abstraction these days is alluring, and it's cool! However you want something well known, well supported, (from multiple companies ideally) and documented. The hate for understanding kubernetes is just hate for having to understand layers of orchestration, or worse the layers behind the application.
If it's too complicated then you might not need it. Any platform you use will have those same layers, it just depends on how much is assumed or exposed to you. If you don't want to see any dials or options then use a managed solution, not a roll your own platform tool. That's of course assuming a few virtual machines managed by hand doesn't satisfy your needs, but if that's the case you don't need a platform solution (and hopefully it's not production).
I still think that projects like this one come from necessity. Folks want to have an alternative for vendor lock-in.
I'm building something like that too (https://github.com/pier-oliviert/sequencer) for Kubernetes, and it's also out of necessity.
Vercel, Heroku and others have a lot of helpful tools that are empower developers, and I think people want to have those without being locked-in.
It goes without saying that I'm totally bias :)
It's not like netlify does better in terms of rightizing nodes.