dsamy

why?

sorry about that. it's true our doc is so so... we're working on it.

Especially when scaling beyond one server. The next Tau release will include `spore-drive`, a tool for deploying and updating on thousands of servers with a single command.

It's a different approach. Coolify is a container management platform with CI/CD integration. Tau is meant for developers, and Git is the only way to make changes. Moreover, Tau can handle compute, storage, pub-sub, and more. Note that, besides CI/CD, Tau cannot orchestrate containers currently.

So, being fully featured truly depends on your intended use case.

Scaling using p2p is something that some of the big Silicon Valley giants use internally. It scales very well. Tau uses a combination of techniques on top of the DHT to ensure response time is quick. Unfortunately, our documentation is not that great (working on it), but we have three services that accelerate discovery and routing: Seer (keeps tabs on nodes' health and offers a DNS interface as well), Gateway (a load balancer that forwards traffic to nodes it keeps tunnels with), and TNS (a replicated registry of resources: what is what).

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.

have you tried https://github.com/taubyte/tau? it's easy to deploy and it's comparable to CF.

Not really open source, plus it does not scale beyond one VM! tau (https://github.com/taubyte/tau) is a real alternative, to cloudflare & vercel and others, that is open source and actually scales -> https://taubyte.com/blog/be-competitive-in-few-minutes/

"Taubyte eliminates the need for DevOps and platform engineering" was used in https://taubyte.com/blog/introduction-to-taubyte/ to trigger the reader. What it means is best practices of DevOps were built-in and will always be + it's already a platform so no need for built from scratch platform engineering.

Running an app on a VPS would work but it's hard to scale. This is what justifies kubernetes and alike.

I talked to a lot kube-lovers, and yes, they all love k8s because it justifies their wage!

I think the big problem is cost and time to scale. And that's what talks to managers.

Howdy! I’d like to introduce you to what we’re building: Tau, a solution to a problem every developer faces: making local code work at scale without breaking the bank.

Tau is an open-source platform designed to make your development life easier. It scales your projects seamlessly from local to production, sidestepping the usual high costs and complexities of traditional cloud providers.

Tau has been built to be simple to use and mighty in performance. It’s your coding experience, supercharged for the cloud—no Kubernetes nightmares here.

We're continually improving Tau and would really value your feedback to make it even better.

Samy (https://github.com/samyfodil)

I took a look at Nvidia Triton Inference server, and it might be a good option for production especially as it has c++ api.

Amazing feedback, Thanks!

It's true other engines like vLLM are way faster and more optimized. I started with Ollama because its codebase is Go. In reality Ollama does not even take full advantage of llama.cpp itself as it does not implement concurrency plus adds latency using json in a CGO call. I discovered that building the wasm plugin, I was disappointed, and it's not on the ollama priorities to solve that see https://github.com/ollama/ollama/issues/3170

Another advantage of Ollama is it can easily run locally, so does the wasm plugin. Accomplishing the goal of local development environment which uses dreamland.

That's great feedback. I was thinking about fixing the concurrency issue myself, but creating a vLLM wasm plugin is a better idea. The user code won't need to change as long as the plugin exports as the same wasm host module.

Yes. Check 8bit.ws. Code for LLAMA plugin using GPU is here https://github.com/samyfodil/taubyte-llama-satellite