a letter with my name on it
on day one of the docker captains summit, Eva Bojorges handed every captain an envelope. inside was a handwritten letter.
she had taken time to learn about each of us before writing them. in mine, she talked about how i use creativity to tell stories from the docker community, and how i could bring that same energy to what docker is building next.. it set the tone for the next four days
this blog is everything i brought back from cancun, from the tech and conversations to the people i met and a few things i didn't expect to learn!
a little about me before we get into it.. I'm a senior platform engineer, currently freelancing. before this, i worked as a platform engineer at slice finance bank and as a software engineer at akuity. I've been a cncf ambassador for two years, and recently became a docker captain!
my cloud native journey actually started w docker. my first container, my first "but it works on my machine" moment, and even my first tech talk were all connected to it.
so walking into a room full of docker captains for my first ever captains summit is so amazing.
A day in the summit, from sunrise to sandboxes
we stayed at the iberostar in cancun, and pretty much everything happened inside the resort. which meant we could go from a technical session to the beach without having to plan our entire day around travelling.
a typical day looked something like this.
1. sunrise on the beach
some of us actually managed to wake up early enough to watch the sun rise over the caribbean
2. breakfast with captains
these were some of my favorite conversations because nobody was in a rush to get somewhere else
3. sessions, workshops and a lot of feedback
the product teams walked us through what they're working on, asked for feedback and gave us a chance to try things ourselves. some of the things we saw are under nda, so i can't share everything. but there was plenty that is already public, and that's what i want to talk about in this post.
4. afternoons in the sun
we had fun video shoots, archery, shooting, tennis, pool time and ocean swimming. basically, a very different kind of day from what my usual engineering routine looks like.
5. evenings together
long dinners, food from pretty much every cuisine you can think of, circus, dance workshops, games and karaoke. there was always something happening, and somehow the conversations kept going even after the official schedule ended.
3 things that will Change How You See Docker
we mostly think of docker as the company that made containers easy to use. after seeing what the team is working on around AI Agents, i started looking at it a little differently.
the bigger question now is how do we give ai agents a place to work without giving them access to everything on our machines?
here are three things that are imp for u
1. an agent running on your laptop has access to your laptop
coding agents like claude code, codex and gemini cli can run commands on your machine. depending on how they're configured, that can mean access to your files, environment variables, ssh keys and network.
which is convenient until something goes wrong.
an agent doesn't have to be malicious to cause trouble. it could run the wrong command, expose a secret or make a network request you never intended it to make. and if it has access to your machine, the damage can go beyond the project you're working on.
this is where docker sandboxes come in.
launched earlier this year, docker sandboxes give coding agents an isolated environment using microvms. the interesting part is how that isolation works.
- a separate kernel. regular containers share the host kernel. a microvm provides a stronger isolation boundary, closer to a traditional virtual machine.
- a separate docker daemon. agents can run docker build and docker compose inside the sandbox without needing access to host's docker socket.
- network and filesystem controls. you can control which files the agent can access and which hosts it can connect to. credentials can be provided from outside the vm instead of being stored inside it.
- disposable environments. if something goes wrong, you can delete the sandbox and start again without having to clean up your entire machine.
docker has also built its own vm manager to make this work across macos, windows and linux.
if you want to try it yourself, here's the official quickstart.
for macos, the basic flow looks like this:
# install and sign in
brew install docker/tap/sbx
# go to your project
cd ~/my-project
# start claude code inside a sandbox
sbx run --name my-sandbox claude
# allow access to a specific host
sbx policy allow network registry.npmjs.org
# list and remove sandboxes
sbx ls
sbx rm my-sandbox
the first run lets you choose a network policy. you can start w a more open setup or restrict access depending on what the agent needs to do!
what i liked here is that the security boundary isn't just a prompt telling the agent to be careful.. it's enforced by the environment the agent runs in.
2. permissions should exist outside the agent
this was probably one of my biggest takeaways from the technical sessions.
we're increasingly asking ai agents to do things that can affect our code, infrastructure and external services. but asking an agent to follow security rules isn't the same as actually enforcing those rules.
you shouldn't have to trust an agent to police itself.
that's the idea behind sandbox kits. fellow docker captain mohammad-ali a'râbi explains this in his write-up on authority as code
a kit is an oci image that describes the tools and permissions an agent needs. there are two main parts:
- a workload, which is the agent or application doing the work.
- a mixin, which adds things like tools, network rules or credentials.
one example is a mixin for github cli. you can let an agent interact with the github api while blocking certain operations, such as deleting repositories. credentials can be provided through a proxy, so the agent doesn't directly hold the token.
this makes the permissions much easier to define and manage. because a kit is packaged as an image, you can also use familiar tools to build, scan, sign and pin it.
i particularly liked that docker published the spec as open source and is working towards CNCF governance..As a CNCF Ambassador, seeing security tooling move towards open standards is something i def care about
the larger idea is pretty simple. instead of relying on an agent to behave define what it's allowed to do and enforce those limits outside of it
3. secure defaults are better than another security checklist
most teams know they should care about security.. the problem is that secure setups often take more time and effort, especially when you're trying to get something working quickly.
docker seems to be approaching this by making security part of the default workflow and not something you remember to add later.
a few examples stood out to me.
- docker hardened images are now free and open source under apache 2.0. the collection includes over 1,000 minimal images, with software bills of materials, public vulnerability data and build provenance.
- MCP server isolation. running MCP servers in isolated containers behind a gateway gives you a way to control how AI tools connect to external systems instead of letting every tool access everything.
- docker model runner. you can pull and run models locally and serve them through openai-compatible apis, using a workflow that already feels familiar if you've worked with containers.
what connects all of these is the focus on making the safer option easier to use.
I think that's important because security tools are only useful when developers actually adopt them. if doing the secure thing adds too much friction, people will find shortcuts. making it part of the normal workflow gives teams a much better chance of getting it right.
why i think docker has a big opportunity with AI
10 years ago, one of the big questions was how to package an application so it could run consistently across different environments.
containers helped solve that problem.
now, with ai agents, we're dealing with another question. how do you give an agent an environment where it can work, run tools and access what it needs without putting everything else at risk?
the problems aren't exactly the same, but there are some interesting similarities.
docker already has the container ecosystem, the developer workflows and a lot of trust from people who build software. applying that experience to ai agents feels like a natural next step.
i'm especially interested in this space because it sits at the intersection of developer experience, infrastructure and security. these are areas i've spent a lot of time working in, and there's still so much to figure out.
the summit gave me a better sense of where docker is heading, and honestly i'm excited to see how this develops.
back to the Captains Summit
if you ask me what i'll remember years from now, it's probably going to be the people. here are a few of all the amazing folks who made the summit memorable!
Mohammad-ali A'râbi, and his wonderful wife... their energy was contagious. and of course, here's a picture of me with the best selfie captain:
Serena Sensini, who built her own custom pink pc. we spent an afternoon talking about camera-speaking together, and it was fun sharing ideas beyond our usual technical work. She's also so inspring!
Max Proske, who speaks hindi better than most indians i know! he also won docker captain of the year, which was so well deserved. here's to me hijacking the captains trophy:
Aurélie Vache, a fellow cncf ambassador and an author whose books have helped so many people in the cloud native community!
Kristiyan Velkov, whose talk was just as fun as his linkedin posts. he also patiently helped me get some drone shots!
Nick Janetakis, whose courses and ideas around teaching made me want to create more learning content myself.
Ajeet Singh Raina, his stories about hosting meetups gave me so many ideas that i want to try back home.
Usha Mandya, shared how much thought and effort goes into good documentation! I'm inspired
Sathiya Shunmugasundaram, who shared security lessons from his work at tesla and was also incredibly kind.
Jennifer K., our social media captain, she has captured so many moments from the trip!
Khushboo Verma, who i've known since college 1st yr... we'd never met in person before, and somehow our first meeting happened in Mexico.
and here are the DOCKER CAPTAINS of the year.
also, the stickers deserve a mention of their own.
someone brought some of the wildest stickers i've ever seen, and everyone gathered around the table picking their favorites
what's next for me?
one thing i took away from talking w fellow captains was how much a local community can do when someone actually brings people together.. i'd want to explore more around developer experience, ai agents and sandboxing, and share what i learn through talks and blogs!
if you're organizing a docker event and looking for a speaker, feel free to reach out. i'd love to be part of it.
thank you, captains
Eva, thank you for inviting us, for the handwritten letters and for creating a space where a room full of people from different countries could feel like friends within a few hours.
thank you to the docker team for sharing your time, listening to our feedback and giving us a closer look at what you're building.
and thank you to every captain who shared a breakfast table, a buggy ride, a microphone or a sticker with me.
see you at the next one!
further reading
Comments
Join the discussionNo comments yet. Be the first to comment.
