AI-assisted coding needs more than vibes; it needs containers and sandboxes

Hello, and welcome to the Stack Overflow podcast, a place to talk all things software and technology.

I'm Ryan Donovan, your host, and today we are talking about containers and how they are

adjusting to the new AI era. This episode is sponsored by the fine folks at Docker,

and my guest for it is the president of Docker, Mark Kavich. So welcome to the show.

Thanks, Ryan. Great to be here. Before we get into all the container news,

let's get to know you a little bit. How did you get into software and technology?

I originally started college as an aerospace engineer thinking I'd want to work on airplanes,

took a programming class, and then learned, no, actually, I like this better,

and so transitioned very early on, and been in the industry for a while. My first job was

Norteil Network, so if you remember that, back in the 90s, and where Friday the M for a while

was fortunate to be very early at AWS, built some leadership positions at a startup,

and then ultimately went to Oracle for a while and built Oracle Cloud infrastructure,

ran engineering at Heroku for a while, held leadership position at Stripe, did another

healthcare startup up and around for a while, so. Yeah, but it took a lot of fingers and a lot of

pies. Docker and containers have been one of those foundational technologies to the cloud

and infrastructure of code, enabled a lot of things, but we are at another inflection point with

technology, the whole AI, AI agent revolution. How's the doctor adapting to that?

One, I would say at this point, containers are ubiquitous, and so I think everybody knows

there's something like 90% of companies are running containers in production at this point,

so that's de facto. Docker for all intents and purposes equals containers,

we're in the very privileged position of, we get to see this across the board and talk to everybody,

and I largely hear the following same three things from almost everybody, whether they're a startup

or a Fortune 10, which is, well, of adopted containers, I'm on the path, I either have zero pipelines

or 50 pipelines, and I'd like them to be better, and be great if we could actually have trust and

security and what we're actually running a production, if that's a pinpoint, in particular,

as AI agents are generating a lot more code, and simultaneously, well, we're trying to figure out

how to run agents safely, so this is kind of the same three things I hear from everybody across

the board, in which case, what are we doing? The sort of pithy one line, or I guess, if we were

focused on something is, I'd say, cloud code, and cursor, and everything else allows you to easily

10x the lines of code generated, those things are going to need to run in containers, but I don't

think most companies or most developers are yet 10xing the number of ships. Some people are, but not

everybody, and that old gap comes down to trust, and that's actually what Docker's super focused on.

So that trust gap is, I think, with the code generation is huge, because a lot of people are generating

code that is full of hulls. It's not a great written. How are you enabling the better security,

better trust with that code in deployments? So we put out a market last year, a product called

Docker-hardened images. It does what it says on the tin. Effectively, whether it's a human or an agent

is generating code and getting a lot more, they're pulling in more dependencies, they're pulling in

more dependencies faster, attack services blow out, and at the end of the day, containers are an

artifact of the describes replication and let's you get it from point A to point B.

And so we've been focused on this problem. We've seen a lot of companies adopt it, and ultimately,

what I'll snarkly describe is they watch their scanner wall of red go to green, but more importantly,

actually in December, we actually made this pretty bold move in a pretty big change in the market

to make that available for everybody on earth to go start migrating their applications and adopt

this new way of hardening their applications so they can start secure. So we put it out, effectively,

the entirety of the catalog, which I can get into and explain what that means for free, actually,

an open source. So vector one for us has been focusing on helping everybody run their containers

in production safely and giving them a baseline to go do that on. That's what DHS were.

I definitely want to get into the open source aspect, but first, what does it mean for a container

to be hard and what is different? There's probably a couple of things I'd say when there are actually

our standards on this, basically in layman's terms, you want to minimize the attack surface,

you want to strip out any unnecessary packages, any necessary tools, like for example, when you

want our own production, you don't need a shell in the container. So you strip all those things out.

You want known provenance of where they come from. It's important for you to not have malware

injected in, like there's been a lot of very prolific attacks on very supply chains in the ecosystem

that ultimately inject bad code in. So you want provenance of both where everything came from

and what it was built on. And we'll get into this a little bit of the free versus not free.

You want some level of call it an SLA or service level agreement on patching and

monitoring for CVEs or vulnerability. And you want full transparency around called the S-bomb,

the software of materials, and effectively the vulnerability feed. So all those things together

make up a hardened container. How much of that is sort of automated and how much takes a little

bit of work from the person building the container? There's two questions that build the container,

two people to build the container. So Docker puts an inordinate amount of work in to go build

those base images that looks like a lot of process of automation of integrating with vulnerability

feeds in which there's 20 or so that we integrate with and adding more every day. There's a lot of

automation to go work with what's called source available patching when vulnerabilities are

disclosed. And some researcher somewhere puts a patch out on the internet. We have to be able to

quickly detect that and turn that around and get that integrated. And ultimately Ron and this

is the hard part, the full compatibility suite of testing. So you want to know if you got Postgres,

for example, that Postgres version minus one and version plus one work the same. That'll

requires a lot of automation. And separately, you need a lot of human work to go make sure that

actually, you know, as you strip these things down and you strip out all the unnecessary dependencies

and harden the configurations like things like running not as rude and default ports, there's a lot

of details in there. That all looks like effectively the Docker engineering work's job. Now,

the question, as you say, when someone wants to build a container, if you're the end user that

wants to get your container to production built on top of those base images, it's a little bit of work.

We try to make it as little work as possible, but I think that looks like you migrating from,

you know, an Alpine or Dev, most people in the world are built on top of Alpine and Devian

bases. We know this. We've made it very easily and drop in for them to migrate from, you know,

say Postgres on Alpine under something like a Docker official images to a Docker hardened images

that is stripped down. They'll often have to go through some of the validation because, you know,

you may have inadvertently put a shell script dependency in, you may have dependent on some

library that got ripped out for the surface area. So there's some level of validation to be sure,

but we tried to make that as minimal as possible. And you said you're making this open source

free. That's great for the ecosystem, but it sounds like you're putting a lot of work for these.

What's your angle mark, right? Why would we do that? So they're trying to be very transparent about

this. There's no angle. There is a business we have to pay for it somehow, but a few things to

describe. The entirety of the catalog that we've put out as open source, like there are some

exceptions, like FIPS and regulated things and commercial software and so on, but for the vast

majority of people, things like Node.js, Java, or, you know, OpenJDK and Python and Postgres,

like all the popular things you'd expect. There's hundreds of them in there. Those are all out

there. They're out underneath an Apache 2.0 license. So there's no ifans or butts about it. It's

there and the tooling around how to go work with it is there. What is the commercial model and why

you would want to pay Docker for this? Have all that discussed by described of automation and

the build systems and everything else. Effectively, we've put out the base images and we have very

simply said the patching SLA or the frequency of which the patches come in these hardened images

is identical to what happens in upstream. So you are strictly better than using a base image from

either us or one of the Linux vendors. I won't, you know, drop my name right now. Like anybody that's

got whatever they're tracking to upstream will fix the bugs there at the exact same rate that

upstream fix them. That's what gets published. You can take a dependency on the container. You can

have a more secure baseline by far. That's all free and open source. Almost every company and

business out there. And this is where it becomes commercial is needing compliance in some form,

whether it's SOC 2 or ISO or hard things like FedRamp etc. Those all require effectively continuous

patching. And so for that, we offer a seven day SLA. We're trying to get it under one day. We'll

go have a roadmap for that over the course of the year where anytime of vulnerabilities disclose

and there's source available, we will get it out to you as a subscription in that timeline.

That's the very base trigger, I would say, that gets you from free to wanting a commercial

contract. And the reason you would do that is, well, that's where all the work comes in.

Every time one of these sources become available, getting ahead of upstream means you have to go

actually validate that source. You have to go do all the compatibility testing. You have to do a lot

of work for that. And it's fundamentally to go enable the businesses that need compliance,

regulation, and so on. So that's the most, if there's a bright line of what trips you from being

an open source developer or somebody in the community to hey, your business and you need to have

a commercial arrangement, that's the first and foremost, the motivating factor. And then above

and beyond that, we've made it very easy in the commercial product on our, because we've

already salsa three build system, which too long to read is a very complex, very regimented

structure of everything from hardware up is certified and assured and so on that we're doing

the right things. We're not letting malware in, the human process or in place, etc. Everything we

do runs on that. And there's a nice feature called customizations that make it very easy to the

point, make it much, much easier for businesses to quickly customize those base images, get their

packages in, get their certificates, their keys, whatever they want to get in there. So that

starts coming into the commercial tier because it runs on our build infrastructure. We have real

cost to incur for that. And then lastly, we have an enterprise tier that is being rapidly expanded

as well that meet the needs of more regulated, more stringent customers. A couple of dimensions

there to talk about. One is we've added extended life support. So the common cases, everything's

great when you vibe code your app and then you get into production and then you're stuck with

that version. And seeing Docker hub, we see the spread of what everybody pulls on the internet,

we're effectively DNS for content. And the spread of, there are very few people in the world

running high volume things in production that keep on the bleeding edge of version upgrades.

And so the longer something is mission critical in production, the more important it becomes for

you to have backported fixes, even when something is called end of life in the upstream open

source. And even indeed many regulatory bodies, whether it's in finance or government and so on,

actually require plus five years from an end of day. So there's a, on the enterprise offering,

those extended life support. And we're adding hardened libraries on tops to help you go beyond

containers into the, start getting into the application code. Our goal is to help secure void

main down if you're a Java programmer and you're old like me. But you know, whatever you are,

language of choices, making that easy and convenient and so on. So this is a long explanation

to the simple question of, wait, what's in it for you guys and what's your angle mark? And why

are you doing everything versus a commercial thing? So very simply, we've tried to make sure,

very genuinely, that the internet and open source community and the world at large adopts

some more secure baseline that is strictly goodness. And then where we have real cost to incur

because of complexity, we have a commercial and arrangement that where the pricing is economically

attractive for almost every business out there to do this instead of trying to, you know,

maintain it themselves and everything else. So my understanding is that you're not just providing

the sort of hardened container primitive. You are providing the hardened containers for a lot

of things on Docker Hub 2, is that right? There's hundreds of what we call repositories and

thousands of versions of repositories, something like Postgres or Node.js. And then you can imagine

the version compound out. So we've got at this point that, you know, Docker official images are what

the internet's been running on top of for, I don't know, 5, 10 years now, whatever date we put

that back out in time. And everything in there is now available hardened. So it's a soup DHI

is strictly a superset of it. And we've gone above and beyond and actually started hardening a lot

of the things our customers are telling us to that are not even in the Docker official images base.

So it's a vast sprawling and ever expanding content catalog. Yeah, talked about security patches

for end of life libraries. It's the Docker team actually going in and writing security patches

for sort of unmaintained security libraries. When we have to, yes, when I say there's hard work

to be done here. And that's that we're not doing that for free because you can't. And there's

real risk incurred when doing that. But at end of the day, yes, we go back in time and we will

selectively figure out what vulnerabilities needed to be back-ported. And that's whether you're

an enterprise or you're just somebody running a mission credit application that's kind of,

to some extent, it's frankly table stakes that you need to be able to have that assurance to

keep running your application. Is there a migration path for folks who want to go from a regular

image to a hardened image? Yeah, the simple thing we tried to, we took a philosophy day one of

we're going to base it not on invented homegrown operating systems or weird things. We're going to

make them based off of Alpine and Debian, the common things that everybody uses will add RPM

bases while add other things as demand comes up. And so in the simplest case, you literally change

the from line of the Docker file, rebuilding your done. That won't always be true because again,

you'll have dependencies that you've, you know, nobody's life is perfectly clean. So they'll end up

with some dirtiness in there that have to go clean up. But additionally, we've also got Docker

Desktop is Gordon actually some AI tooling. And so we've actually started investing in coding

agents to help it help you do this automatically and migrate your package from point A to point B.

So, you know, with agents, a lot of people have finding a lot of power to it, a lot of productivity

gains. But it's also, you're giving those agents a lot of control and a lot of trust. We've all

heard deleting your SQL table of that sort of thing. What's the sort of moves you're making to

gain trust there? This is a primary of focus for us. We've done a lot in the last year. Actually,

we put out an MCP catalog that looks and tool kit. That's a gateway that gives you some trust in

the things that your agents connect to. We put out local model running. And most recently,

and actually just vlog came out two days ago, we put out a new version of what's called Docker sandboxing.

And so what this is really about is taking the core primitives of what existed in Docker for

the last 10 years of being able to run arbitrary untrusted code with isolation, in particular on

cross laptops and across production instances and making that work for agents. So now it's

relatively easy to start something like a clogged code or a cursor or co-pilot or what have you

inside of a Docker sandbox. And now you get a safe boundary put around it where it can only see

what you've given an access to. And so now the agent can run in that environment. It can

mutate itself. It can do whatever it wants in there. But you get strong controls, observability

in a box around it. And so essentially, you're able to insert yourself back in to let it keep

having the judgment that you want for productivity, but the safety to actually let it cook essentially.

Is it a container? Is it something different? It's actually based on micro VMs. It's interesting.

A micro VM can run a container. And to some extent, this is what Docker desktop has actually

been for many years. Like Docker desktop, it strikes away the factor on a Mac machine or a Windows

laptop and allows you to go run a container inside of a virtual machine. We've effectively rewritten

that stack on something that is much, much faster and lighter weight and that'll be coming soon

to Docker desktop near you. And you can start from a container and run that container inside the

sandbox. The container is still used to portally describe what you want. In this case, it'd be something

like cloud code or cursor or co-pilot. And once it's in there, though, now the big change that

has existed that did not exist before is well, it can start to actually mutate itself and it can

start to actually, you know, like pointedly when you want to run something like cloud code, almost

the first thing it'll want to do is install something for self-environment or change it for some reason.

And so we fully allow that and you can let it take actions on the file system, let it take

actions on itself, let it take actions on the environment, but ultimately manage what it does on

the file system, what it manage what it does on the network. And we're rapidly adding secrets

management and other things to help you restrict what it does, what it wants to do external network

and external resource connections. So effectively, whether you're running to run cloud code and not

have it RMR of your file system or you want cloud code to be able to run its own code or you want

to have your own agent in there. Sandboxing gives you a new and lighter weight and clean, simple way

to go put an agent in a box essentially. It's kind of a sweet spot. Can you then have those changes

persist and become portable? You can. So funny enough, I saw a demo this morning actually of the

Dash Dash save command where you imagine you should start something like a coding agent in the sandbox

as it runs, as it changes itself, you can go invoke it and ask it to effectively save itself off

as an OCI container that you can publish back to Docker Hub or anything else and share it to another

sandbox. So it makes it very easy to start templating these things and start changing your environment

and allow to frankly share with your teammates or share with the world, whatever, you know, whatever

you want to do if you want to look like bolt bookers or open cloud and whatever it's called today.

So on. I mean, it almost sounds like you're adding a super break point system to agents.

Yeah, to some extent, it's an observable box and we're putting a lot right now. We've been

rushing to get out as the primitive so people can start depending on this and they can reason about

how to run these again locally on their laptop. What's been really interesting is just three years

ago, I think the industry was talking a lot about CDs as the end all be all and all of a sudden

everybody's back to well, I want to run all these agents as many as possible these agents on my local

laptop and control them. And the world still looks the same as this look for a long time, which is

you have a lot of people on Mac and a lot of people on Windows and want some consistent workflow

across those. And I think we'll see the line between what's an app and what's an agent in production

blur and you'll see the capability of being able to write code in production start to blur. So in

case, this portability, we think this environment that you can portably run from place to place to

place is the original ethos of Docker just resprust up for the world of agents. So do you envision

agents that being like self-improving and then with this sort of portable sandbox, could you then

pitch those movements over the wall to customers? When I think about what an agent can do, you know,

it's a autonomous system where you've flipped the control loop. Effectively, there's three

dimensions you can measure it on, latency, accuracy, and cost. And you'd imagine if you can start

putting these things in a box and observing them, you could actually start to measure what they're

doing on each of those dimensions and start to make trade-offs. So for example, you know, right now,

I think nobody defaults to opus 4.5 for everything or you know, the biggest GPT or the biggest

Gemini. At some point, does these become dominant for every workload cost controls will kick in?

And I think people will start picking the right model for the right job and wanting to,

you know, have smaller things and tearing things that the world will get more sophisticated.

And so being able to reason about that, see it, and ultimately let the agent, you know,

again, improve itself, but you can see it externally and keep track of it and make that a

shareable artifact. That is actually, I think, where we see this going and what we're rapidly

sprinting to go work on. So how much kind of observability are you enabling in there?

We have some nice UIs coming soon to a desktop near you, but you can think of it as something like

hotel feeds where you can see everything it's doing in terms of certainly tool calls and file

system calls and even network calls, but we'll start to get into more and more code interception

and be able to give you real-time visibility into what it's doing. And importantly, you know,

again, whether you're the individual developer working at home that just wants to control it,

or you're the enterprise that wants to control it across, you know, a thousand people,

what you actually want is outside the box to write your rules and controls and

based on the feeds that you can see in real-time, go change them. So actually,

to sure answer your question is, we can give you real-time feeds into what it's doing on all the

common resources you would expect. That's amazing. And just hook it up to a dashboard and

you can watch it cook. We've seen a pile of people in the last week or so vibe code a bunch of

these dashboards. So whether we give you, whether you like our dashboard or not, I think it's

relatively straightforward to go get your own dashboard and your arms are ready for it.

It seems like there's a perspective that you think there's going to be a lot more agents on the

desktop itself. Is that accurate? I think you'll see a mix of them on the desktop and I think the

desktop and the cloud will get a little bit blurry. We've got a preview of this in market with this

thing called Docker offload, which is imagine you click a button in Docker desktop and you get

a cloud computer that looks and feels and acts like your Docker desktop and when you run a Docker

command it just happens to be running on a cloud machine. I think what that will rapidly turn

into is, again, you'll want local control for the things that are local. Like if you start thinking

about the use cases of agents, beyond acting in a Linux machine, they're going to need access

things like the camera and the microphone or if you're giving an agent out to a finance person,

I don't know, I've never met one in my life that doesn't want to excel. It's going to have to work

with the local artifacts on the system, in which case the laptop remains an important,

almost production-like endpoint for agent developers, but it'll be blurry and you'll want

cloud compute attached to it natively and naturally so that you can have resource bursting,

whether that's because the machine is resource-constrained and it has frankly crappy GPUs on it,

or you'd red-pilled yourself into the coding agent world, then you want to run 20 of them at a

given time, which is when I walk the halls of our engineering floor, we see the most bleeding

edge folks are running, the wall of monitors that looks like almost the matrix or something where

they've got them all, or I guess the Texas hold them crazy, whatever metaphor you want to use,

I think being able to run that many in parallel, you'll have to have cloud attachments to it,

but fundamentally, again, because of the shape of the problem and the shape it's about

helping humans connect to autonomous systems, yeah, the laptop is critical, and so

again, this goes back to like, well, why Docker and why are we after this? This is literally

the thing Docker was created for. Thank you very much, Solon Ice, my decade ago, and helping you

build ones for on anywhere, and we're extending that going forward, so.

You talked about Docker Hub as being almost DNS for content and the MCP registry. Are you

thinking about tying those into the AI sandboxes? There's an MCP catalog and there's several

hundred of these in there growing every day, which are popular MCP servers, again, Postgres,

the obvious suspects you'd expect, Postgres, and so on, that we've gone through and containerized

for all the reasons you'd want to containerize them, and then there's what we call the MCP

Toolkit, which is built on an open source MCP gateway that allows you to quickly spin those up

in place for the agent, and the nice thing we did is we were very early in building a lot of

dynamic capabilities for them. For example, it is fairly easy to go blow out the context window

for agents. If you give them 10 servers, those tools are big servers and tell them about all the

tools in them, versus what we've done is have an interface in that MCP Toolkit that simply

exposes, find and exec, and so the agent is able to dynamically go find and pull these MCP servers

from that catalog and just in time use them and just in time run them. That is all, when I say

the agent sandbox and putting all these things together, really it's this core execution environment

that allows the box I described with MCP content and MCP gateway injected in, as well as we've got,

there's a really nice project that is quietly winning hearts and minds called C agent that allows

you to construct your own agents and orchestrate them, and so with those things together,

we'll have agent orchestration as part of it. Again, you could imagine your dashboard of 20 things

or so on, you could look at them from outside the box, you could have orchestration inside the box.

I've talked to other folks, and it seems with agents speedrunning the microservice route,

where it's like, now you've got the Kubernetes for agents over here.

I mean, the funny thing is, I think agents are effectively making everybody to your point.

They're speedrunning you to microservices, whether you wanted it or not, because ignoring

the big changes that the control loop is different and the way that you work with this thing and

what it decides is different, but from an artifact perspective and what you go run,

it looks exactly like every other microservice on Earth, which is it's a purpose-built thing that

does one thing, connects to some other things, and has state and memory and takes some actions.

And so, like I said, funny enough for Docker, I feel like it's almost like the world is just built

on top of the shoulders of what the idea of containers and what the company's been doing for a decade,

and really it's like so complimentary and so natural that agents will need all the same things

everybody needed before, for the world of cloud native and microservices just times a thousand.

But the core primitive is, if you're generating 10x the lines of code, you need more containers,

not less, so whether it's for security or for isolation, or just frankly for productivity and

sharing, whether it's from a human to an agent or an agent to an agent.

So, what is the sort of future that you're thinking about, in terms of containers,

sandboxing, hardened containers, all that? Without spoiling all the beans and giving it all away,

you'll have to stay tuned Docker in the weeks and months ahead. What I'd say is we were really

focused on making sure that the hardened image space, again, if you have think of Docker as having

two missions, help the 91% of companies get to 100% of companies running containers of production

and help those people run containers and apps safely with trust and help every dot coding agents.

Those are kind of two parallel paths. For the first one, we're super focused on completing that

DHI vision, as I talked about, of making it accessible to everybody and making it easy to go work

with and helping more people adopt it. And there's just a lot of things we're doing around tooling

and enhancements and migration capabilities and helping businesses get and achieve compliance

much more easily and much lower cost. So, there's a lot of things coming on that side of the house.

And as I mentioned, and I'll come back to agents in a second, underneath this is what we're

rewriting those like the animal DNA or recoding the animal DNA of Docker as we speak around some

of these needs of agents. But we expect to see a lot of performance improvements, speed improvements,

et cetera, and Docker desktop that everybody knows and loves. So on the one side of the house,

that's all coming soon. On the other side is then, we've put a lot of things out in market

over the past year. And we've got a few more things up our sleeves that are not currently released.

But what I would say is that all the things we just talked about around having an agent platform

and having the ability for any developer anywhere to build her run a coding agent safely and

more productively and turn off all the permission checkings and do it safely. And ultimately,

be able to go ship 10 times the amount of code, not just write 10 times the amount of code

that will require cloud computing, that will require policy management, that will require

observability, that will require some agent tool kits. Just hypothetically speaking, imagine

that we're all packaged together with the Docker DX.

Well, it is that time of the show where we shout out somebody who came out to Stack Overflow,

earned themselves a badge by dropping a little knowledge. So congrats to a populist badge winner,

humble b, they came and they dropped an answer that was so good, it outscored the accepted answer

and they dropped it on how to open run a YAML compose file very timely for this episode.

I'm Ryan Donovan, I host the podcast, edit the blog here at Stack Overflow. If you have

questions, concerns, comments, topics to cover, please email me at podcast at StackOverflow.com

and if you want to reach out to me directly, you can find me on LinkedIn.

And thanks for having me, Ryan. I'm Mark Cavidge, I'm president at Docker. I'll also give

the same shout out to humble b, thank you for that answer. We appreciate it. And I think most people

know how to get a hold of Docker, you can find me on LinkedIn as well. Thanks for having me.

All right, thank you for listening everyone and we'll talk to you next time.