Is Docker Building the Best AI Stack?

This is DevOps and Docker talk, and I am your host, Bret Fisher. This was a fun episode this week. Nirmal Mehta is back from AWS and our guest this week was Michael Irwin of Docker. He is a recurring guest if you've been listening to this podcast for any length of time, I think we had him on earlier this year, and he's been a friend for a decade, former Docker captain, now Docker employee advocating for Docker everywhere.

He's all over the place and, I always have him on because he breaks stuff down to help us all understand what's going on at Docker. And there is a giant list of things we had to talk about this week, all AI related, all separate pieces of the puzzle that can be used independently or together. So in this episode, we will be covering the Docker Model Runner, which I've talked about a lot on this show over the last four months, for running open or free models locally or remotely on servers or on your machine, wherever.

Basically you get to run your own models and Docker will host them for you, Docker will encapsulate and allow you to use the Docker CLI to manage it. Then we have the hub model catalogs, so you can pick one of the dozens of models I guess, that are available in Docker Hub and we talk about Gordon ai, which is their chat bot built into Docker Desktop and the Docker CLI. We then get into MCP toolkit and the hubs MCP catalog, and how to bring all our tools into our local ai or like, using some other AI and you're just wanting to use your own MCP tools.

We talk about how Docker manages all that and it uses the MCP gateway that they recently open sourced to front end all those tools and to help you manage your MCP tools. We also then get into compose and how you add models and the MCP gateway plus MCP tools, all into your composed files. Then we talk about how to use that for building agents a little bit And then Offload, which allows you to build, run containers, run Docker models, all in Docker Cloud, and they call it Offload It actually is a pretty unique name.

Most other people just called it Docker Cloud, but they call it Docker Offload. Great name. You just toggle inside your Docker UI and you're good to go. Everything's remote.

And then we at the very end talked about Compose Now works at least the YAML files of Compose, now work inside of Google Cloud Run. Probably coming to other places soon. So we go for almost 90 minutes on this show because for good reason, we talk about the use cases of all these different various AI parts of the puzzle. And I'm excited because it paints, I hope for you a complete picture of what Docker has released, how it all works together, when you would choose each part for problem solving, different problems and all that.

So please enjoy this episode with Nirmal and Michael Irwin of Docker. Hi! Hey, Awesome. I'm doing all right.

we have a special guest Michael, another Virginian. Hello. Hello, we all have known each other a decade. So Michael, tell us who you are so I'm, Michael Irwin, I work at Docker.

I'm in our developer success team, and do a lot of teaching, training, education, breaking down the stuff, trying to make it somewhat understandable. I've been with Docker for almost three and a half years now, so it's gone pretty quickly, but, it's fun to spend time with the community and just help developers out. Learn about this stuff, but also how do you actually take advantage and do cool stuff with it? That's awesome.

I mean, this is like a new wave of, essentially development tooling and, it's pretty exciting. Yeah. we've got a list people. I only make lists on this show a couple of times a year.

Yeah, it does seem like every time I'm on the show, there's a list involved. yeah, that's a pretty decent list. let's break it down because we got a lot to get through and we realize that on Docker's channel and on this channel, They've been talking about all these fun features. I've talked at length about Docker Model Runner.

Hub Catalog, I don't have a bunch of videos on MCP or the MCP tools, but actually we've had streams on it before. But, I think the MCP toolkit and the MCP gateway I'm most excited about that. So we're going to get to that in a little bit. I think, technically, the first thing out of the gate was Gordon AI.

this to me is. From a user's perspective, it's a Docker focused or maybe a developer focused AI chatbot, essentially similar to ChatGPT, but it's in my Docker interface. if I'm staring at the Docker desktop interface, there's an ask Gordon button. And if you've never clicked that, or if you clicked it once a couple years ago, it has changed a lot.

There have been enhancements so o now we have memory and threads and it saves me from having to go to ChatGPT when I'm working, specifically around Docker stuff, but anything it feels like I can ask it developer related stuff Can you tell me now, is this free for everyone? How does this play out in terms of who can use this Yeah, so everybody can access it right now. The only limitations may be some of our business orgs. those orgs have to, enable it.

We're just not going to roll out all the AI stuff as most organizations are pretty cautious about that. but yeah, Gordon's available to everybody. it started off actually mostly as a documentation help of just help me answer questions and keep up with new features and that kind of stuff. But, as you've noted, we've added new capabilities and new tools along the way.

I was doing some experiments just the other day of Hey Gordon, help me convert this Dockerfile to use the new Docker hardened images. And it would do the conversion, find the images that my organization has that match the one that I'm using this Dockerfile. you're starting to see more and more capabilities built into it as well it's a pretty fun little assistant there. Yeah, highly recommend folks that are listening that if you've not touched Docker and you just open it up, check out Gordon and ask those questions that you probably have, compose all the things you could probably put that in there and Gordon will probably try to compose all the things.

you know what one of my common uses for this is I need to translate a docker run command into a compose file or back and forth like, please give me the docker run equivalent of this compose file or please turn these docker run commands or this docker build command into a compose file and it saves me. It's not, I mean, I've been doing this stuff almost every day for a decade, so it's not like I needed to do it for me, but it's still faster than a pro typing it in from memory, I'm at the point now where I rarely need to refer to the docs, but it's still faster than me at writing a Compose file out and saving it to the hard drive.

You know, because sometimes we debate around whether AI tools are useful for senior versus junior and blah, blah, blah, and I don't know, as a senior, it saves me keystrokes, it saves me time, unlike when it first came out a couple years ago, I have Tracked it, given feedback to the team and it no longer makes Compose files with old Compose information. Like it, at least in the the version tag. Yeah. Cause it, the version tag.

Yeah. I was a big proponent of Hey, this hasn't been in there for five years. Why is it recommending it? and they fixed that.

So, I'm very appreciative of it. We're going to save it, we're going to talk about MCP tools, and then we're going to come back to this, because it gets, it's gotten better, and one of the reasons it's gotten better is it can talk to tools. So I don't want to really spoil that, But yeah, I love the suggestions because sometimes when you're staring at a blank chat box, it feels kind of like being a writer and staring at a blank document. It's like, I know this is supposed to be a cool tool, but I don't know what to do with it.

do I start? Yeah. analogy there's even some cool spots, like if you go to the containers tab, You'll see on the right side a little like magic icon there, and then you can ask questions about that container. So if you have a container that's failing to start or whatever, you can basically start a thread around the context of why is this thing not starting.

Interesting. I have not tried that. it actually reminds me of the little star we get for Gemini that's in every single Google app that I'm opening. I guess we're all, slowly converging on the starlight AI icons now, I would have thought it would have been a robot face, but we chose this vague collection of stars and pluses.

I and that is pretty cool. I, so is there more, is it like an images as well? So yeah, anywhere you see that icon, you can start a conversation around that thing. I'm going to start clicking on that more often to see what it tells me.

Like, Hey, what's the, what data. Ooh, How do I back up this volume? That's, that is pretty cool. So they're that is the number one question I love that they're context aware.

Like they know that this is a volume, or at least the prompts. it's like prompt suggestions, which This feels a little meta. Is the AI suggesting prompts for the ai? It's not in this case, but it certainly could.

All right. so that's ask Gordon, Woo! Alright. And that is what you said.

that is available to everyone running Docker Desktop. Is that, to be clear, that's not available for people running Docker Engine on Linux, right? That is not There is a CLI to it, isn't there? There's Docker AI.

but that's part of the Docker Desktop installation. that's a CLI plugin and it's going to talk to the components that are bundled in Docker Desktop there. Yeah. so we have our, this is an AI that's outsourced to Docker.

It's not running locally. it's just calling APIs from the Docker desktop interface. So then if I don't want to use Gordon AI, but I want to run my own AI models locally, which I feel like this is pretty niche because a lot of people I talk to, their GPU is underwhelming, and they don't have an M4 Mac or a NVIDIA desktop tower with a giant GPU in it. granted, I guess there are models that run on CPUs, but I am not the model expert here.

I've been trying to catch up this year because I actually do have a decent laptop now with an M4 in it so I can run at least some of the Apple models. But this Docker model runner. it's a pretty cool feature, but you can pick your models, so you can pick a really small one. On Windows, it has to be an NVIDIA GPU on Windows to work.

Is that right? So it supports both NVIDIA and Adreno, so if you've got a Qualcomm chip, it'll work there. Okay, and on Mac, it just uses system memory because that's how Macs work. They have the universal memory, right?

And I mean, for me, it's been great because I have a brand new machine with 48 gig of RAM. I know that is not normal. but these models, Mac, it can be a little problematic because it's like, if I have a bunch of browser tabs open, I can't run the full size model that I want to run, because that's one of the problems is like, it's all using the same thing. So I have to do like we did back with VMs, I have to shut all my apps down and then run, because I always want to run the biggest model possible.

So I have this like 40, 46 gig model. I think it's the Devstral new model that's supposed to be great for local development. So for those of you listening, if you want to go in depth, we're not going to have time for that, but it is, Docker Model Runner lets you run models locally. you can technically run this now on Docker infrastructure, right?

Which we're going to get to in a little bit. dun dun. Okay. yeah, there is this thing called offload.

Michael's going to know way more about that. Cause that's a really new feature, but you don't have to actually run these models locally now. Like you could offload them. Right.

Okay. What are you seeing? are people coming to Docker, like trying to run the biggest models possible? They got like multiple GPUs or are you just seeing people kind of tinkering out?

What's some analogies there? there's a little bit of everything. I'd say a lot of folks are still exploring the space and figure out what's the right ways of doing things as well too. So, one of the interesting things is, and one of the things to keep in mind is that Let's break outta the AI space.

when you say, for example, a database. Okay. I'm using Postgres database. If I'm using a Postgres database, a managed offering out in the cloud.

Okay. Let's just say RDS. Okay. during development I can run a Postgres container and yeah, it's a smaller version and it's not a managed offering.

and that works because all the binary protocols are the same. I can basically just swap out. My connection URL, and it just works. But models are a little different.

And so, I've seen some folks that have been like, I'm going to use a smaller version of a model during local development, but then when I deploy, I'm going to use the larger hosted model that my cloud provider provides. Okay, so maybe it's a parameter change, I'm using fewer parameters so it can actually run locally, and then use the larger version. The analogy of, okay, me running a local PostgreSQL container and me running a local model, if it's a different model, it's a different model.

And the results that you get from that model are going to vary quite a bit. And so that's one of the things that we have to kind of keep reminding people if you use for example a four billion parameter, So, we're going to talk a little bit about how you can use this model during local development. Yes, it can fit on your machine, but then if you deploy and you're using the 32 billion parameter version in production, those are very different models and you're going to get very different interactions and different outputs from the models there.

So, it's something to keep in mind as folks are looking at building their applications. So, where are we seeing folks use this? Well Of course, if you can use the same model across your entire software development life cycle, then that works out pretty well. but we're also starting to see a little bit of a rise of, using basically fine tuned use case specific models or folks training their own models.

and using those for the specific application. and again, that's tends to be a little bit smaller, more use case specific. And then, yes, that makes sense to use there. okay, I need to be able to run that on my own.

et cetera. again, I think a lot of folks are still feeling out the space and figuring out exactly how should I think about how should I use this? and of course, the tooling has to exist kind of before you can actually do a lot of those experiments. So, in many ways, we've been building out that tooling to help support that experimentation.

but I think in many ways, folks are still figuring out exactly what this is going to look like for them going forward. Yeah. I'm trying to imagine what enterprises are doing and building out and I'm imagining it's not like this, but one of my imaginations is reminding me of 20 years ago, buying a Google box, which I don't remember the name of, they called it, but it was this appliance you would put in your data center that was, it was yellow. Racked search appliance.

you go. Yeah. And I don't know if Nirmal, if you had any customers back then with, if you were a consultant back then, but that, I can't name those customers. so I can, I was in, the city of Virginia beach running the IT and the data center there, or at least running the engineering groups.

And those were back in the days where we didn't want Google indexing our internal infrastructure. You don't want your internal data to be. accessed or used potentially by this big IT conglomerate. Yeah.

And so you bring, they, they sell you a, on prem box and you put it in your data center and it would scan and have all access to everything you could give it, back when apps didn't really have their own search, Google was providing that for us, and they would index our email and index our file servers and databases if we wanted to give it access to them I'm not sure that's around anymore, but, at a time, Google wasn't going to give away their software and we didn't all know how to run it.

And, I'm sure it was running on Linux. And at the time in the mid 2000s, we weren't yet Linux at the city. For different reasons. This kind of feels like the same moment for enterprise where.

They're going to have to buy GPUs probably for the first time if they're going to run it on prem, they're going to want to keep it separate. They're going to either buy something for the first, probably GPUs if they're not training models, they just want to run things internally to access their internal data, or maybe they're doing it in the cloud and Nirmal's company, AWS, is providing them the GPUs and then presumably because they're getting dedicated hardware, they won't have to worry about OpenAI or Anthropic having access to all their stuff so with respect to ModelRunner and again, just a reminder, these are my own opinions and not that of my employer, Amazon Web Services.

There's still a lot of use cases. what Michael was talking about with respect to choosing lots of different models for different types of tasks, I think there's probably a hybrid model at some point where folks are using different fine tuned niche models for specific tasks that they're doing locally, and then as hardware improves, and hopefully, you know, maybe your 3 year old developer laptop that you get at your corporation has enough, or the models get, you know, Get, optimize it enough that they can run on CPU or the GPUs that you have on a corporate laptop, but there'll be some tooling, probably embedded into the development tooling and, or you can choose your own models.

and then those, there'll be other models where you need to reach out to the hyperscalers for those that just you're not going to get the depth of reasoning you're not going to get the depth of knowledge that you will from something like Claude in the cloud versus something like deep seek running a quantized deep seek running on your mac but again this is all changing very very fast and Right now, we're in a different state where folks have to spend money to access those larger models, which hasn't been the pattern with respect to software development in a long time, right?

Not everyone has that advantage, right? I mean, if you want to use Claude Code and, not hit any major limits, then you got to pay 200 a month, which, not everyone's going to be able to afford 2, 400 a year, to do software development, there's also edge use cases, right? So IoT devices, just trying to figure it out. Also just kicking the tires.

I think that's probably the main, like Michael said, I think that's just, everyone is just trying to kick the tires as cheaply as possible. model runner feels like a gateway, like it feels like a gateway drug to get me Hooked on like the idea, cause I, I mean, I wasn't paying attention to, I wasn't a machine, I wasn't an ML person or I wasn't building AI infrastructure, but Docker model runner and, well, and, you know, to a lesser extent, Ollama, Ollama always felt like it was more for those people that were doing that, but bringing this capability into a tool that I'm already using actually felt like, Okay, this is meant for me now, like this is, I don't have to be, I don't have to understand weights and all the intricacies of how models are built and work and the different, I don't have to, I don't have to understand the different file format and whether that works on my particular thing.

it just all kind of works. It's Docker easy at that point for me. think that's the key point here of just, let's try to increase the access to these capabilities and let folks start to experiment and I think Again, we, as an industry, are trying to still figure out exactly how to use a lot of these tools and, okay, what is the right size model for the job at hand? and so, again, in order to be able to do that experimentation, you have to increase the access to it.

and so, but that's still kind of, you know, Where we are in many ways. So did we check off another thing on the list? about to I'm gonna have to keep saying this We're not a news podcast. We don't talk about the latest things like in general in tech but you know, I got to give a shout out to Fireship because I have Between that and a few other channels, I've really learned a lot this year about models.

And I was, there's this little, diagram of sort of the state of a lot of the open, waiter open, or free, I'm just going to say free models. They're free in some capacity, that you can download. And, I was using Devstral. We talked about it a couple of times on this show already, which is a model that came out in May.

I actually had a newsletter on that. Shout out to, Bret. news, there's this guy, Bret, he makes a newsletter, Bret. news, you can go check that out.

and I talked about this, that maybe this was the sweet spot because it was small enough, you could run it with a modern GPU or modern Mac, and it wasn't the worst, nothing like the frontier models that we get with OpenAI and Anthropic, but it was something that was better. And, that's called Devstral. And then we had Quinn three just come out, I don't know, a week ago or something that is I think it was earlier this week. Oh, see, time warp of AI, I think it three days is like three weeks.

It was two days ago. Yeah, Oh gosh. I always assume that I'm seeing a Fireship videos late, but, yeah, one day ago, so yeah, that's true. One day ago, there's a newer model coming out from Alibaba, right?

And it is even better, although it does take more GPU memory, I that's hard to run like on a laptop. I don't think you can, so that's a perfect encapsulation of like why Docker model run is there, but also why it's going to be a mix of models going forward. so we've, we have an AI that helps you use Docker and get started. We have a tool that helps you run models locally, and understand that what's the next step in this journey?

by the way, you go to Docker Hub to look for models, or you can do it in Docker Desktop, or you can look at things in the CLI. there's many ways to see the models. you can pull things from HuggingFace now. That's pretty sweet.

Can we build, can we make our own yet? Or do we have that? We can so, you can package, but you would have to already have the gguff file and all that kind of stuff. So we don't have a lot of the tooling there to help you actually create the model itself.

Although a lot of folks will use container based environments to do that. we don't have any specific tooling around that ourselves. So is there, you're saying there's a doc, oh, there, there is. Oh, I didn't realize.

So there is now a Docker model package CLI for creating, basically wrapping the GGUF or, other models or whatever, into the Docker OCI standard format for shipping and pulling and pushing essentially Docker. models that are in Docker hubs that are in the Docker format. OCI format. Yep.

So when we look at agentic applications, step one is, you need models. It's kind of the brains of the operations. and then you need tools. And so you've got highlighted here the MCP toolkit.

That was kind of the first adventure into the MCP space. And that one was focused a little bit more on how do we provide tools to the other agentic applications that you are already running on your machine. So Claude Desktop or using VS Code Copilot on my machine or Cursor, etc. How do we provide those MCP servers?

And containerized ways, secure credential injection, etc. Basically manage the life cycle of those MCP servers. Again, in the use case of connecting them to your other agentic applications. And so, again, this is kind of where we started our MCP journey.

if you see flipping through a couple of these, actually we just released a Docker Hub MCP server that allows you to Search for images on hub or, you know, those within your organization, which is super helpful for like maybe a write me a Dockerfile that does X. Well, cool. Let's go find that the right image that should be used for that. so again, starts to open up some of these, additional capabilities here.

Yeah. And inside the Docker desktop UI, there is now a beta tab, essentially, that's called MCP Toolkit. And it is a GUI that allows me to explore and enable one of, 141 different tools and growing that Docker has added. So like a lot of the other places on the internet that either they host models like Anthropic or OpenAI, or They're a place where you can create AI applications and all those places have started to create their own little portals for finding tools and they may or may not, I mean, most of them all now settle on MCP, but before we had really MCP as the protocol standard, they were already doing like OpenAI was doing this before, but they were very, it was proprietary.

You don't know how Evernote or Notion got, showed up as a tool feature in ChatGPT, it did. But we just assumed that was their custom integration and now we have this standard called MCP that everything should interact with everything properly the way that they should. At least right now it's the one that's winning. We don't know whether we'll still be talking about MCP in five years, but it's here now.

It's what we're talking about now. And this lights up a lot of capabilities. In other words, you turn on an MCP tool. And that sits behind something called MCP Gateway.

So tell me, what is MCP Gateway? Yeah. So at the end of the day, the toolkit is a combination of several different things. the MCP gateway is actually a component that we just open source at WeAreDeveloper.

So you can actually run this gateway directly. In a container, completely on its own. And the MCP gateway is what's actually responsible for managing the lifecycle of these MCP servers. it itself is an MCP server.

think of it more like an MCP proxy. it exposes itself as an MCP server that then can connect to your applications. But when you ask that server, Hey, what tools do you have? It's really delegating, or I mean, it's using cache versions of, okay, what are the downstream MCP servers?

And so it's acting as basically a proxy here. so when requests come in and say, hey, you know, from the agents at GAP, if I want to execute this tool, go do a search on DuckDuckGo at that point, the MCP gateway will actually spin up the container, that DuckDuckGo MCP server, and then delegate the request to that container, which then does the search, and then the MCP gateway returns the results. So kind of think of it as a proxy that's managing the lifecycle of all those containers, but also, you know, injecting the credentials, configuration.

it also does other things like actually looking at what's going in and out of the prompts going through the proxy to make sure, you know, secrets aren't being leaked or, that kind of stuff as well too. and we're even starting to do some further explorations of what are other ways to kind of secure those MCP servers? You know, for example, a file system one should never have network access. Cool, so let's, when that container starts, you get no network access, or, the GitHub MCP server, you know, it's talking to the GitHub APIs.

Let's only authorize those host names that it can communicate with. So, you know, start to do a little bit more of a kind of permissioning model around these MCP servers, which is where a lot of people are kind of most cautious and nervous about MCP servers, because it's, they're completely autonomous for the most part, and you have to trust what's going on there. this exact feature is both necessary and also Solomon Hyke's prediction from a month ago. He was on this show and was saying that we're going to see all these infrastructure companies and all these tooling companies that are going to offer to lock this shit down.

I think it's the quote I have to get from him. that sounds right. he compared the origin of containers and how it started with developers. And then eventually it took it and sort of managed it in the infrastructure layer and provided all the restrictions and security and limitations and configuration and all this stuff.

And the same thing's happening to MCP. Where it started out as a developer tool to empower developers to do all these cool things with AI that they couldn't do and let the AI actually do stuff for us. And now very quickly in a matter of months, IT is coming in and saying, okay, we're going to lock this down. It's crazy.

You can, you know, your prompts can delete your, drop your databases, your, as we just saw happen on the internet recently this week. I want to, on this gateway topic though, it can sound complicated. And maybe the internals are a little, and there was obviously code built into this program. But for those of us that aren't maybe building agents yet, or like really getting into building apps that use AIs in the app, this just appears as kind of magic.

Like it, you go into the Docker desktop UI, I enable, I go through the toolkit, there's all these suggestions, everything from, the MCP server for GitHub itself to an MCP server that could give me access to Grafana data to accessing the Heroku API and you're looking at all these things and you're just like, I'm enabling them. it's like a kid in a candy store. I'm just going check, check, check. Yeah, I want Notion.

I want Stripe. I get them in a list, they're enabled, which means they're not actually running, right? they're waiting to be called before the gateway runs them in memory. That's all transparent to me, I don't realize that's happening.

And if I choose to use this toolkit with Gordon, if I just go into Gordon, And in the Gordon AI, if I don't want to run a local model myself, or I'm not using Claude Desktop or something that gives me the ability to enable MCP tools, I can just go in here and say, enable all my MCP tools, all 34 of them. I've got get ones and I've got, and so now what that means is the Gordon AI can now use these tools, which makes this free AI even smarter. And I can say, is there a Docker hub image NGINX?

I don't know if there is. Let's see. I've never even tested this. So it's kind of a, what could go wrong?

let's use Google live on the internet and see what happens. yeah, I was just saying, look at it, going out and checking, using the Docker, the newly created Docker hub, MCB, tool That you had, just, released. so is this going through a, MCP gateway or is this not with the MCP gateway yet? when you and Gordon AI flip the switch to say, yes, I want to use the MCP toolkit, basically what that's doing is, in the Gordon AI application here, it's enrolling the MCP toolkit as an MCP server.

And so then it's going to ask The MCP toolkit, hey, what tools do you have available? And so when you saw that list of tools, that's again coming from the gateway. Gordon is just simply treating the MCP toolkit as An MCP server, which in itself is going to launch MCP server. So that's kind of why I mentioned, it's kind of thinking of it like a proxy there.

Yeah, it does feel like one. Yeah. And this, for those watching, like it didn't actually work because I don't actually have access to hardened images, but, I just wanted to see what it would, what it'd say, but it, the, the UI Which is the right answer? Which is the right answer for did the right thing.

it didn't expose a vulnerability in the MCP server. But yeah, so it basically, I can give Gordon AI more. And I can do a lot more functionality, more abilities to do things without having to run my own model, without having to figure out Claude Desktop. But I will say, because I'm in love with this toolkit so much, because I love this idea of one place for my MCP tools, for me to enter in the API secrets so it can access my notion and my Gmail but I don't want to have to do that in Claude Desktop and then in warp and then in VS code and then in Docker and then in Ollama and like every place I might run.

A tool that needs MCP tools or access to an LLM. So I did it in Docker Desktop. I enabled the ones and set them up the way I wanted. And then inside of my tools around my computer that all support AI MCPs, they all have now added MCP client functionality that lets me talk to another MCP, any MCP server that speaks proper MCP through their API.

And in this case, what I've done in the warp terminal, because it does support MCP, is I just tell it, the command it's going to run is docker mcp gateway run. And it uses the standard in and standard out, which is one of the ways that you can use mcp. And then I suddenly have all 34 tools that we enabled in my docker desktop. Available in Warp, just as long as Docker Desktop's running, that's all I gotta do.

And then, because Warp is using Claude Sonnet 4, or whatever I told Warp to do, Docker doesn't care about that, because I'm not asking it to use, think that, we talked about this it's called bring your own key, I guess that's what everybody's talking about. Uh, bring your own key is when you want to bring your own Model to whatever to access, you're a key to access the model. Yeah, but in warp in particular, like this is nuanced, but in warp, you can't usually, you can't yet access your own models yet.

I think they're going to make that an enterprise feature or something. But if I open up VS code, I could do the same thing. If I opened up a ChatGPT desktop, I could do the same thing. And, Aider or like any of the CLI tools, although anything that accepts MCP so far, I've gotten to work this way.

And it's been awesome because all these, all these different IDEs and AI tools all set up a little bit different. Goose you set up differently than Claude Desktop. So Client. they're all, and all they, all of them have different knobs and, ways of controlling MCP servers and at varying degrees of control and flexibility.

So this is really nice because then you can also just have all those tools running if you right. They look like one giant MCP server. Yeah, because normally I would have to add each MCP tool as its own server, I think, it feels like some of the tools are all standardizing on Claude Desktop as, that config file, which I the mcp. json, Yeah, it feels like that, like everyone's settling on just using that one file.

Which is, I guess it's kind of feels kind of hacky, but I guess it's fine. it feels like every editor using my VIM settings. It's like, no, no, no, no. Calm down.

I don't necessarily want you all to use the same file. I don't want you all overwriting each other and changing the same file. so you're bringing up a really important thing, which is, since we're new to this, the number of MCP servers is not too many yet, even though it does feel like there's probably like a lot of MCP servers. I've been using 10 new MCP servers since we've started this conversation.

But it's still like a number of tools that we can still rationalize about. But probably in another month or two at this rate, there is a limit to how many MCP tools One single client, I guess you could say, or one instantiation of a task that you're using like Claude Code or Cline, it's context window can only use a certain amount of tools. And so, is there some ideas about breaking up in the MCP gateway, like having maybe like sets of tools that have like specific supersets or tools or something like that?

Yeah. Good question. And so that's a good call out. And so I actually want to, zoom in on that just a tiny bit there, because for folks that may be new to this, they may not quite understand that the way that tools work is basically, it's taking all the tool descriptions.

Okay, here's a tool name. Here's when I'm going to use this tool. Here's the parameters that are needed to invoke this tool. And it's sending that to the model on every request.

And so the model's having to read all that and basically say, hey, based on this conversation, hey, here's a toolbox of stuff that I may or may not be able to use. But as Nirmal just pointed out, like that takes context window there and granted yes some of the newer models have incredibly huge context windows but depending on the use case, it's going to affect your speed, it's going to affect the quality, and so yeah, you do want to be careful of like, okay, I'm not just going to go in there and just flip the box on all the MCP servers.

Now you have access to everything. Like, you do want to be a little conscious of that as well. in fact, I found it funny in a, I was playing in Cursor not long ago, and you know, they have even just YOLO mode, just go crazy with it. But even they have A warning once you, I think it's after you enable the 31st tool of like, hey, heads up, you're getting a little crazy.

So like, I'm like, for the one that has YOLO mode to call me out for being crazy for too many tools, like it was, it's again, kind of a reminder of just, okay, you do want to be conscious of the number of tools that you're using. so to actually answer the question. Yeah. It's been something that we've been exploring and kind of waiting to just see what the feedback is gonna be on that.

Are there separate tool sets that, clients can connect to. you know, that's certainly a possibility as well, since this MCP gateway is an open source container, when you run this for your application, not only can you say, these are the servers I want, but then you can even further filter through, these are the tools from those servers that I actually want to expose. So, for example, I think the GitHub official one is up to 72 tools now or something. It's a crazy number.

but most of the time, I only need maybe three or four of them. So, I want to filter that. And that's why you see, Cloud and VS Code and many of these others. Even though you're pulling in these MCP servers, many of those provide client side functionality to kind of filter that list as well, Yeah.

I wonder if we get to a state because the MC, this is getting a little bit meta, but everything when you talk about agentic AI gets meta really quickly. So, I wonder if the MCP gateway itself is an MCP server, so it can rationalize about itself, I wonder if we get into the pattern of, okay, there's this new task that I want this agent to do, and the first thing, after it comes up with its task list, the steps it wants to take, is go through that list and then, ask the MCP gateway to reconfigure itself on each task and turn on Only the ones that it identified as likely the ones that it needs for that task.

And just dynamically, at any given time, don't have anything more than five running. So figure it out. You can choose whatever five you want, but only have five. We've done some experiments with that, not quite to that full dynamicness, but I've even done some ones of a Okay, here's a tool to enable other tools, is basically what it is.

And, okay, and give me parameters of, okay, do you need, GitHub? Do you need, Slack? You know, tell me what it is that you need, and then I'll enable those specific things. And then what's cool then is, as part of the MCP protocol, there's also notifications.

So the MCP server can then notify, The client says, hey, there's a new list of tools available, and then the next API request to the model then has this new set of tools. I think we're almost capability is there, but, I think that's likely the next step. but it's also kind of like a, yeah, how do you safeguard that? So it's, Yeah, it's an interesting time period, for sure.

we got an interesting question, is MCP Gateways intent to replace an API Gateway or in parallel to it? Great question. Michael, you want to take that one? yeah, great question.

I'd say in some ways that there's similar functionality, but they serve very different purposes. So an API gateway, I'll just take the most basic example, but I know there's lots of different ones, An API gateway, single endpoint, and I may have lots of different microservices. Let's just pick a catalog. Okay, so for product related ones, it's going to go to this microservice.

Users, it's going to go to this other one. Cart, another service, whatever. And the API gateway is routing all those different requests and rate limiting, etc. In many ways, like this MCP gateway serves in a similar fashion in which it's going to be routing to the right MCP server to actually handle the tool execution and whatnot.

But again, it's only for the MCP protocol. So it's not going to be replacing an API gateway because it's not doing normal API requests, etc. It's only for MCP related workloads and requests. different protocols at play here.

I think that's probably the best way to describe it. otherwise, you could also say that MCP and API Gateway are likely going to be running in parallel. and so probably what I would see would be, I have an API gateway that routes a request to an endpoint, and then that particular application, let's just say it's an agentic application, can then have its own MCP gateway to satisfy whatever agentic flow it needs to use there. I wanted to, while you guys were having an awesome conversation, I was trying to draw up, just a visualization to try to represent, okay, so just so people understand, because this MCP, we could make a whole show on MCP tools, honestly, from an infrastructure perspective, how do these things talk?

How do they integrate? The fact that you're talking about that they're just really adding to the context window is a fantastic fact that, A lot of people could go months or years using MCP tools day to day and never know that, right? a normal non engineer could use MCP tools, not understand how these things are all working. for those that are into this, are playing around with MCP tools elsewhere and understanding a little bit of MCP server functionality and client versus server versus host and all that stuff.

Before Docker's gateway, the MCP gateway, you would have like an MCP client That whether it's your IDE, your terminal, or AI, chat, desktop, or whatever you've got, that is acting as an MCP client. Assuming it supports MCP servers, you can add them one at a time. So I would add GitHub's MCP server, then I would add DuckDuckGo's MCP server. I might add Notion's MCP server, since I'm a big Notion fan.

And each one of those servers has One to infinity, tools, which are, I look at as like API routes. and each one has its own very niche purpose. depending on the tool, and this is part of the frustration with the ecosystem right now is we're only months into this, but it's amazing that all these tools are all starting to support each other, tools have different ways where you manage this. Some of them you can disable and enable specific servers.

Some, you can actually choose the tools individually, which is like choosing API routes. And to me, it's you're always trying to get down to the smallest amount of tools that you need to prevent confusion. Cause I'm, my biggest problem is I enable all the tools because I get tired of managing them. I just want them to work.

I just want them all to work when they need to work. And then I, so I enable them all. I end up with 50 plus tools. And then when I'm asking AI to do things, it chooses the wrong tool because I wasn't precise enough in my ask to trigger the right words that are written in the system prompt of that MCP server.

So actually, maybe an easier update might be to put another layer on top of the MCP server and kind of an in between. so I'm connecting the MCP gateway now to multiple other MCP servers. So I get, yeah, you're right. I need another layer here.

That's actually MCP servers. so, there's now this gateway in the middle, and it, the only negative of this approach is for right now, because we don't have this futuristic utopia yet, is that to my terminal, or my IDE, it all looks like one giant list of tools. And in one MCP server, which is just the nature of proxy, right? But behind one IP address is a whole bunch of websites, like you don't realize it, right?

So it is, the analogy still works, I believe, there. But in this case, because it's connecting all of them together into one proxy, and the nice thing is, it's, I can see in the memory usage and the containers. In fact, when Michael was on weeks ago, We saw the MCP gateway spinning up servers dynamically and then shutting them down and you could see the container launch run, you know, run the curl command or whatever, and then close. And it was so quick, we couldn't, capture and swat toggle windows to see the tools launching.

And, I mean, it's beautiful. It's exactly what containers were for. It's, it's ephemeral, it's wonderful. But, if your IDE or if your chat desktop or whatever is acting as your MCP client, the agent thing, if that doesn't let you choose individual tools, then this approach is a little hard because the only way from my IDE that I can, I have to turn off all of Docker or none of Docker.

It I think. This gets us to a conversation of eventually we will have this. I'm thinking of it as like the model, the plan model before the model that will go, okay, you used all these keywords. I'm going to pick out the right tools and I'm going to hand those off to the next model, which is going to do the actual work.

That's probably already here. Solomon predicted it a month ago. Yeah, I'm sorry. What?

so that's what Michael and I, while you were drawing this Oh, is that what you were just talking about? that's what Michael and I, we were talking about. So the gateway itself has its own MCP server that controls itself. And so we're a few months away from exactly what you were just talking about.

Bret, because of context windows, because there's too many tools, because of all the things that you did, all the challenges you just mentioned, Bret. the first step might be the client going to the MCP gateway, MCP server first and saying, hey, these are the things I'm about to go do. Out of the list, check your MCP gateway and tell me the list of, MCP tools that I actually need for that. And then only turn those on for the next task.

Yeah. and then it'll just repeat that cycle again. and then winnow down that list of MCP tools to the only things that are needed for that task at hand. So there's another layer here, which we're, and Michael and I, we were discussing while you were building that beautiful diagram.

It's, people are experimenting with that. All the pieces are in place, but that this pattern isn't quite there just yet, but it will likely be, I'm pretty sure this is what we're going to be doing pretty Nobody wants to go manually choose every MCP server that they're going to need before every AI request. almost feels like it takes away the speed advantage of using the MCP tool to go get the data for me. if I have to do all this work in each tool independently, Because I often will have an IDE accessing AI, acting as the MCP client, and then I'll have a terminal acting as an MCP client.

At the same time, I've got ChatGPT desktop running over here, also while VS Code, I think a lot of us, eventually evolve to the point where we've got two or three tools all at the same time managing MCP tools. We've got, I guess we have multiple IDEs, I should say. and trying to understand how all this comes together is only interesting right now, but in six months, we're not going to want to be messing with all this stuff. We're just going to want this part to work so we can work on building agents, All right.

So Compose, my favorite tool, a lot of people's favorite Docker tool, other than the fact that Docker exists. you announced at, we are developers that Compose is getting more. There's functionality in the YAML specifically, where I guess we're talking about the YAML configuration that drives the Compose command line, that in just three months ago, you were adding model support, and that was like an early alpha idea of what if I could specify the model I wanted Docker Model Runner to run when I launch my app that maybe needs a model, a local model, and I use the example and I have a An actual demo over on GIST, that people can pick up that you simply, you, you write your Compose file, you use something called open web, open, what is it?

Open web, web, open web UI, I think. Yeah, horrible name. Extremely generic name for what is a ChatGPT clone, essentially. the open source variant, which can use any models or more than one model.

It actually lets you choose it in the interface. And all you need is a little bit of compose file. So, I created a 29 lines, and it probably needs to be updated because it's probably outdated, but, 29 lines of Compose that's half comments that allows me to spin up an open web UI container while also spinning up the models or making sure, basically, that I have the models locally that I need to run it. And this gives me a ChatGPT experience without ChatGPT.

Thank you. And you guys, you enable this. Now you're not creating the models. You're not creating the open web UI.

you're simply providing the glue for it to all come together in a very easy way locally. Yeah. as we agentic apps need three things. They need models, they need tools, and then the code that glues it all together.

What the Compose file lets us do now is define all three of those in a single document. here's the models that my app is going to need for MCP gateway that I'm just going to run as another containerized service. And then the code, the custom code, can be really any agentic framework. this example is, Open web UI, but that Compose snippet what we've done is we've evolved the specification now models are a top level element in the Compose file, which is pretty cool.

This just dropped in the last couple of weeks, so this is brand new. Gotta update my gist. yep, and so where before, yeah, you had to use this provider syntax, and that still works. now it's actually part of the specification.

defining a model, This is going to pull from Docker Hub. again, You can have your own models and your own container registry. It's just an OCI artifact. You can specify that anywhere.

then we've got the services, And then the app itself. What's cool about the model now is with the specification evolution, you can now specify, hey, this is the environment variable I want you to basically inject into my container. to specify what's the endpoint, where's the base URL that I should use to access this model. And then what's the model name as well.

So the cool thing then is I can go back up to the top level model specification, I can swap that out and the environment variables will be automatically updated and as assuming that my app is using those environment variables, Everything just works. So again, think of Compose as, it's the glue that's making sure that everything is there for the application to actually be able to leverage it. Yeah. the gateway part here was pretty cool to me.

That I can add in my tools, my MCP tools inside of the YAML file. when I saw that part, I was like, yes. that is like my vision, my dream is that I can pass a composed file to someone else and it'll use their keys. Presuming, my.

Team is all using the same provider that we would have the same. Because open, well, open AI, base URL, open AI model, and then open AI API key or whatever. if you're going to use ones in the SAS, like those are all pretty generic. Even if you're not using OpenAI, they're all pretty generic, environment variables.

So I guess this would work across teams or across people well, and that's a good point to call it. One of the things that OpenAI did when they released their APIs was basically, hey, here's a specification on how to interact with models that pretty much, Everybody else has adopted and used. and so the Docker model runner exposes an OpenAI compatible API. And so that's why you see these environment variables kind of using the OpenAI prefix.

Because again, I can use now any agentic application that can talk to OpenAI or use the OpenAI libraries. And it's just a configuration change at this point. All right. Now, the coup de gras.

Piece la resistance. I can't even do my pretend French, All this stuff has been running locally. Like when we think of Docker desktop, we think of everything locally. And then a year or two ago, Docker launched, Docker build cloud, which was like getting back to Docker's roots.

I almost feel like of providing more a SaaS service that essentially is. Doing something in a container for me. And in that case, it was just building containers using an outsourced build kit. So it was better for parallelization and multi architecture.

it was sweet. And I love it for when I need to build like enterprise tools or big business things that take 20 minutes to build. None of my sample little examples do that, but anything in the real world takes that long and you need to build multi architecture and generally it's going to be faster in a cloud environment. So you provided that.

Now it feels like you've upgraded, like it's beyond just building, and it does any image or any container I want to run, any model I want to run, I guess, not maybe any, I don't know if there's a limitation there, but, bigger models, then maybe I can run locally, and then, also builds. So it can do building the image, hosting the container, running the model endpoint for a, QIN3 or whatever. I can now do all that in something called Offload. So tell me about that.

Docker Offload, the way I explain it to people is, hey, you need more resources? Burst into the cloud. And so it's basically, I'm going to offload this into the cloud, but yet it's still, everything still works as if it were local. So if I've got bind mounts, okay, great, we're going to automatically set up the synchronized file shares.

And so all that's going to work the way using mutagen and some of the other tools behind the scenes to make that work. Port publishing that still works as you would expect it to. So again, it gives that local experience, but using remote resources. I'm just offloading this to the cloud, but yet it's still.

My environment. and so, yeah, to make it clear, like, this is not a production runtime environment, I can't share this environment out, or, I can't, you know, create a URL and say, hey, check this out, colleague, or whatever, it's still for your personal use. Now, of course, can you make a, Cloudflare tunnels, and I'm going to make it production, sure, but I wouldn't could hack that. but yeah.

Yeah. So what is the intent? so what is the use case? the big should I use Docker offload for first?

Yeah, so, okay, great. You're wanting to play around these agentic apps and, you know, we were talking about not everybody has access to high end GPUs or, you know, M4 machines and whatnot. great with the flip of a switch, and you had it there in Docker Desktop, but at the top you just flip a switch, and now you're using offload. and so now you've got access to a pretty significant NVIDIA GPU, and additional resources, and so yeah, as you're, We see the use case, especially more for the agent applications, because that's where those resources are needed.

It does open up some interesting doors for, maybe I'm just on a super lightweight laptop that I'm using for school and I don't have the ability to even run a lot of my containerized workloads. Great, I can use that for offload, you know, offload that to the cloud. it does open up some interesting opportunities for, Use cases beyond agentic apps, but that's kind of where the big focus is right now. So if you're like a Docker insider, or if you're someone who's used Docker a while, it's the Docker context command that we've had forever, augmenting or changing the environment variable docker underscore host, which we've had since almost the beginning, and it allows you from your local Docker CLI, And even the GUI works this way too, because I could always set up a Docker remote engine and then create a new context in the Docker CLI.

That would use SSH tunneling to go to that server, and then I could run my Docker CLI locally, my Compose CLI locally, and it would technically be accessing and running against, the remote host that I had set up, but that was never really a cloud service, like it was never, no one provides Docker API access as a service that I'm aware of, and, the context command, while it's easy to use, and you can actually use it on any command, you can use docker run dash dash context, I believe, or docker dash dash context run, I can't remember the order, but, you can change that on any command.

these are all things that existed, but you made it, stupid easy. It's just, like you said, it's a toggle, it's so easy. You just click that button and then the UI changes, the colors change, so now you know. You're now remote.

Yeah, and so I'll go ahead and say too, behind the scenes, it's using context. It's using those exact things. The tricky part is, because I've done similar, development environments where, I'm going to work against a Raspberry Pi at home or, whatever else it might be. the tricky part is when you want to get into bind mounts, file sharing kind of stuff, or port publishing, and I want to be able to access that port from my machine, like automating all those different pieces.

That's not trivial. I mean, it's possible. a separate tool, yeah, you gotta download ngrok or something, And so this brings all that together into a single offering here. That's pretty amazing.

Like there's a lot going on underneath the hood that, switch is hiding a lot of different functionality. Like it's. To make that very transparent And this supports builds too, right? So like.

When I toggle this in the UI, or is there a CLI toggle? Yeah, there is. okay. So if I toggle this, it's, yeah, you're like, you're saying it's a context change, but it's UI aware, and it takes in all the other little things that we don't think about until they don't work.

And then we're like, oh, yeah, it's not really running locally anymore. So now I can't use localhost colon. Well, that all just, I'm going to show you how this works and you don't even have to know kind of like the rest of the Dockery because you don't really have to know how it works underneath. but if you think it's too much magic, I like to break it down and say, it's just really the Docker context.

I don't actually look anything at the code. I don't know really how it's working. But to me, when I went and checked, it does change the context for me. It actually injects it and then removes it.

I did notice it from the CLI. I could change context. And it would retain the context, but if I use the toggle button, it deletes the context and then re adds it. Regardless, it is in the background, it's doing cool things.

I think the immediate request from the captains was, can I do both? Can I have, Per workload or per service offload so that just my model's remote and maybe that really big database server and then all my apps are local. I don't know why I would care, but like it, that's something that people ask for. I'm not sure that I care that to that level.

I think I'm fine with either or, but I can understand that if I'm running some things locally already and I just want to add on something in addition, it would be neat if I could just choose for one service. Yeah. So as of right now, it is an all or nothing. you're doing everything local.

You're doing everything out in the cloud. there's not a way to. Split that up yet. it's something that we've heard from a couple of folks, but again, it's that same thing of, tell us more about the use cases.

So if that's a use case you have, feel free to reach out to us and help us better understand, why you might want to split runtime. hosting, split environment, hybrid environment. That's the correct term. Why do you say it like that?

and just to be clear, offload has its own cost. like this isn't free forever for infinity. You can't just take up a bunch of GPUs. I was asking the team a little bit and without getting too nerdy, it sounds like it isolates, it spins up a VM or there's maybe some hot VMs.

And I get a dedicated. OS essentially it sounds like so that I can get the GPU if I need. And you kind of get an option of, do I want GPU, servers with GPUs or not? do I, am I going to run GPU workloads or not?

And that affects pricing do we get anything out of the box with a Docker subscription or is it just an, a completely separate So actually it's a. Kind of private beta, but yet people can sign up for it and that kind of stuff. folks will get the 300 GPU minutes, which isn't a ton, but it's enough to experiment and play around with it. and then, start giving us feedback, etc.

Yeah, if you spin up the GPU instance and then go to lunch, by the time you get back, you'll have probably used up your free minutes. It's a long lunch, hey, that's my kind of lunch. but yeah, so we went an hour, and we barely scratched the surface, do we cover it all? did we list at least all the announcements of Major features and tools.

I don't even want to say we've covered all the features because there's probably some stuff with MCP we missed. So you open source MCP gateway, but we should point out you don't actually have to know, like you can just use Docker desktop and MCP tools locally. But the reason you provide an MCP gateway is open source is so we could put it in the compose file and then run it on servers. think about it this way.

the MCP toolkit bundled with Docker Desktop is going to be more for, I'm consuming, I'm just wanting to use MCP servers and connect them to my other agentic applications. And the MCP Gateway is going to be more for, now I want to build my own agentic applications and connect those tools to, Those, those applications that we're running there. Yeah. Do you see people using MCP Gateway in production?

Do you see that as like a. Not that you provide support or anything like that, but is it designed so that We've got a couple of folks that are already starting to do so. stay tuned for some use case stories around that. Yeah.

Awesome. well, this is a lot. I feel like I need to launch another 10 Docker YouTube uploads just to cover each tool specifically, each use case specifically. there's a lot here, but this is Amazing work.

I mean, I don't know if you have a fleet of AI robots working for you yet, but certainly feels like a lot of different products that are all coming together very quickly that are all somehow related to each other, but also independently usable. And, I'm having you on the show as usual is a great way to break it down into the real usable bits What do we really care about without all the marketing, hype of general AI hype, which is always a problem on the internet. But this feels like really useful stuff.

Um, Eivor, another podcast. I don't know, Eivor, what's up? Are you requesting yet another podcast? Um, a whole new show about Compose provider services?

Oh, yes. Also, you can now run Compose directly from, well, you can use Compose YAML from directly inside of cloud tools. The first one was Google Cloud Run. So I could technically spin up Google, which I love, Google Cloud Run is fantastic.

Um, it would be my first choice for running any containers in Google if I was using Google. Um, and so now they're, accepting the Compose YAML, spec, essentially, inside of their command line. So this is like, this feels like the opposite of what Docker used to do. Docker used to build in cloud functionality into the Docker tooling.

But now we're saying, Hey, let's partner with those tools, those companies, and let them build in cloud or compose specification into their tool. So we can have basically file reuse. YAML reuse. Is that right?

yeah. So this is the first time exactly in which it's not Docker tooling that's providing the cloud support, but it's cloud native. They're the ones building the tooling and consuming the Compose file. yeah, it's a big moment.

And as we work with Google Cloud on this, yeah, you can deploy the normal container workloads, etc. But they already have support for Model Runner to be able to run the models there as well, it's pretty exciting And I know, the provider services this is how we started with models. having support in Compose, where That was another service in which the service wasn't backed by a normal container. the old method.

yes, but what's cool about this is, so first off, these hooks still are in place. So that a Compose file can basically delegate off to this additional provider plugin to say, hey, this is how you're going to spin up a model. But it starts to open up a whole ecosystem where anybody can make a provider or, okay, hey, I've got this cloud based database, just as an example. And, okay, Now I can still use Compose and it's going to spin up my containers, but also create this cloud based container and then inject environment variables into my app.

again, it starts to open up some pretty cool extensibility capabilities of Compose as well. I think we, yeah, we need to bring Michael back just to dig into that because, it's essentially like extensions or, Plugins Yeah. for Yeah, so Compose is about to get a whole lot more love. It feels like it's already, I mean, it's been years since we've added a root extension or like a, top level, top level build.

it's not every day that Docker decides there's a whole new type of thing that we deploy. Now we have models, we'll see if providers someday become something. that'll be cool. and this is all due to the Compose spec, which now allows other tools to use the Compose standard.

And that's just great for everybody, because everybody uses Compose. it's like the most universal YAML out there, in my opinion. great. Well, I think we've covered it all.

Nirmal and I need, another month to digest all this, and then we'll invite you back on. do it. but yeah, we've checked the box of, Everything Docker first half of the year, stay tuned for the second half of the year. I actually sincerely hope you don't have as busy of a second half, just because it's, these are a lot of videos I got to make, you're putting a lot of work into my, inbox, We're helping you have content to create.

I know, yeah, there's no shortage of content to create right now with Docker. I am very excited to play with all these things. I sound excited because I am excited. This is real stuff that I think is beneficial and largely free, largely, Like almost all of this stuff is really just extra functionality that already exists that in our tooling without adding a whole bunch of SaaS services we have to buy on top of it.

yeah, so congrats. People can find out more docker.com. docs.

Docker.com, dockers got videos on YouTube now they're putting up YouTube videos, so check that out. I saw Michael putting up some videos recently on LinkedIn. it's all over the place.

You can follow Michael Irwin on LinkedIn. he's on BlueSky. I think you're on BlueSky. I think you're on BlueSky.

Um, or, or, where, yeah, figured out where I'm hanging out. Thanks so much for being here. Thank you, Michael. Thank you, Nirmal, for joining and staying so long.

I'll see you in the next one.