I'm not understanding how this supports Tailscale's initiatives and mission. That isn't to say this isn't a useful feature for a business, but it feels like a random grasp at "build something, anything, AI related." As a paying customer I'm concerned about the company's focus being blurred when there are 3.8k open issues on their Github repo and my company has been tracking some particular issues for years without progress.
Corporate/enterprise networks have nightmarish setups for centralizing access to LLMs. This seems like an extremely natural direction for Tailscale; it is to LLM interfaces what Tailscale itself was to VPNs, a drastically simplified system that, by making policy legible, actually allows security teams to do the access control that was mostly aspirational under the status quo ante.
Seems straightforward?
I think if you don't have friends working at e.g. big banks or whatever, you might not grok just how nutty it is to try to run simple agent workflows.
Another reason they could have built this was by listening to their users. I do believe lots of people are spinning up agents in their workplaces, and managing yet another set of api keys is probably annoying for Tailscale's customers. This feels like a great solution to me.
I realised I wasn't Tailscale's target customer when I reported a 100% reproducible iOS bug/regression over a year ago. It was confirmed, logged, and forgotten.
This seems quite useful to me, especially for a larger org.
If your dev's are working on LLM features, they'll need access to the OpenAI APIs. So are you just gonna give all of them a key? the same key?
No idea how this is solved at the moment, so seems like a smart step
There's actually a mass acquisition game going on right now in this space. Companies want to use genAI, but don't necessarily want to hire people to run their own models in-house. It may not be obvious to startup-y employees, but keeping data in-house is huge for big companies. LLM traffic is a lot different from established traffic that firewalls have been built up for. You can't block data leaks as easily as shutting down access to google drive. When you can't trust all of your employees, genAI presents a lot of new attack vectors.
> As a paying customer I'm concerned about the company's focus being blurred when there are 3.8k open issues on their Github repo and my company has been tracking some particular issues for years without progress.
I feel exactly the same way.
So many open issues, the majority thoroughly deserving of a resolution.
I would rather they get their house in order on the core product first before rushing out shiny new things .... because the shiny new alpha/beta things will only exponentially increase the number of open issues.
I like tailscale itself but a lot of basic stuff (such as dynamic routing) or ephemeral node auth are very lacking, wish they would concentrate more on their core product we all like and want to see improve
A huge chunk of the open issues are feature requests with many of those already being implemented years ago but not yet marked closed. And a vast majority of the bugs are repeats, they clearly need someone to clean up their issue tracker.
> my company has been tracking some particular issues for years without progress
Sounds like something your Account Manager or similar would need to work through. Development roadmaps are often driven by the largest, or loudest customers.
[Tailscale CEO here] I see a lot of comments asking why Tailscale would branch away from our "core product" and build this thing that seems unrelated at first. One answer is that just about every single Tailscale customer (or homelab user!) is dipping their toes into AI right now, and they often come to us and ask how to integrate their stuff into Tailscale. Aperture is our answer to that.
A separate goal I have personally: demonstrate that anyone can build really neat stuff directly on top of the "Tailscale platform." One of my rules for the Aperture team was, you're not allowed to change core Tailscale, you have to build entirely on top as if you were some partner company. So this is a demo of how anybody can make pretty slick, easy-to-use, and yet highly secure stuff by building on Tailscale (the open source packages, or the commercial product, or both).
Not trying to diss or anything but a capable engineer could spin this up within their organization in a day or two. So I’m not sure how useful this is going to be to the average customer. Perhaps to the largest customers who have sophisticated security and compliance needs but even for them this would need to be very very competitively priced to be worthwhile (cheaper than the salary of 2 devs for a year).
The true moat of Tailscale is the core product. That can’t be easily replicated (still). Perhaps some product to simplify controlling what resources agents in the organization have access to and having 100% visibility + audatability for them will be way more useful.
I built a similar gateway for my own stack and thought it would be a quick project, but the complexity is hidden in the details. A basic proxy is simple enough, but getting accurate token counts for streaming responses turned out to be a huge pain since every provider handles chunks differently. You also end up spending a lot of time writing adapters to unify the schemas so your application logic stays clean. If you care about precise billing or logging, it is definitely not a two day build.
> By collecting usage information into a single place, engineering and IT leaders can get a complete picture into both user and agent token efficiency across the organization and providers.
Oh man. Not saying this is not needed or anything, but it feels like Tailscale needed to pivot to something something AI… What a shitty time to be alive, companies doing good products that actually work well need to appeal to investors and do random things like that.
Wellp, looks like it's time for me to downgrade from Personal Pro. Don't think Tailscale needs my five bucks anymore if they're suddenly swinging into AI rentseeking.
unrelated, but what's the path of least resistance to expose a couple of localhost-bound services to the tailnet, ideally with each having own hostname entry as the browser sees it?
they're not containerised, just plain old daemons.
Tailscale services will do that. You can do the proxying with tailscale serve, services gives you the MagicDNS name and virtual IP address bound to it.
This should work out of the box with Magic DNS (part of tailscale features). If machine A is named larrys-laptop and is running a service on :8080, then from sandras-laptop just navigate to http://larrys-laptop:8080 and it should work, provided both machines are on the same tailnet.
frenchtoast8|1 month ago
tptacek|1 month ago
Seems straightforward?
I think if you don't have friends working at e.g. big banks or whatever, you might not grok just how nutty it is to try to run simple agent workflows.
stopachka|1 month ago
dbushell|1 month ago
sauercrowd|1 month ago
No idea how this is solved at the moment, so seems like a smart step
scottyah|1 month ago
traceroute66|1 month ago
I feel exactly the same way.
So many open issues, the majority thoroughly deserving of a resolution.
I would rather they get their house in order on the core product first before rushing out shiny new things .... because the shiny new alpha/beta things will only exponentially increase the number of open issues.
preisschild|1 month ago
I like tailscale itself but a lot of basic stuff (such as dynamic routing) or ephemeral node auth are very lacking, wish they would concentrate more on their core product we all like and want to see improve
nunez|1 month ago
wildzzz|1 month ago
notepad0x90|1 month ago
esseph|1 month ago
Sounds like something your Account Manager or similar would need to work through. Development roadmaps are often driven by the largest, or loudest customers.
_pdp_|1 month ago
apenwarr|1 month ago
A separate goal I have personally: demonstrate that anyone can build really neat stuff directly on top of the "Tailscale platform." One of my rules for the Aperture team was, you're not allowed to change core Tailscale, you have to build entirely on top as if you were some partner company. So this is a demo of how anybody can make pretty slick, easy-to-use, and yet highly secure stuff by building on Tailscale (the open source packages, or the commercial product, or both).
sheepscreek|1 month ago
The true moat of Tailscale is the core product. That can’t be easily replicated (still). Perhaps some product to simplify controlling what resources agents in the organization have access to and having 100% visibility + audatability for them will be way more useful.
storystarling|1 month ago
nojs|1 month ago
> By collecting usage information into a single place, engineering and IT leaders can get a complete picture into both user and agent token efficiency across the organization and providers.
What exactly is “user token efficiency”?
suralind|1 month ago
kotaKat|1 month ago
Netbird time?
ddtaylor|1 month ago
SSLy|1 month ago
they're not containerised, just plain old daemons.
JayWS|1 month ago
Tailscale services will do that. You can do the proxying with tailscale serve, services gives you the MagicDNS name and virtual IP address bound to it.
timwis|1 month ago
lkosewsk|1 month ago
*edited; I initially pointed to Funnel which would be used for sharing outside your tailnet.
unknown|1 month ago
[deleted]
cratermoon|1 month ago
totetsu|1 month ago