Docker Sandboxes — одна из самых интересных возможностей Docker 2026 года. Теперь разработчик или GitLab CI может запускать полноценную изолированную среду с собственным Docker Engine внутри microVM. Это позволяет безопасно выполнять сборки, тесты, AI-агентов (Claude Code, Codex, Cursor Agent), Docker Buildx и любые потенциально опасные команды без доступа к хостовой машине. Docker перевёл эту функцию из Docker Desktop в отдельную утилиту sbx, которая работает независимо и поддерживает воспроизводимые окружения.

Что нового появилось в Docker Sandboxes

В отличие от привычного Docker-in-Docker (dind) или монтирования /var/run/docker.sock, новый Sandbox создаёт отдельную виртуальную машину.

Главное отличие

Классический Docker Runner	Docker Sandbox
Общий kernel с хостом.	Собственный Linux kernel внутри microVM.
Доступ к Docker Socket.	Отдельный Docker Engine.
Контейнер может влиять на систему.	Хост полностью изолирован.
Ограниченная сеть.	Политики сети Allow / Deny.
Сложно безопасно запускать AI-агентов.	Можно использовать YOLO / Dangerous Mode безопасно.

Docker официально рекомендует Sandboxes именно как безопасную среду исполнения AI-агентов и контейнеров.

Docker Documentation+1

Архитектура Docker Sandbox

Как это устроено

Host → MicroVM → Docker Engine → Containers

Каждая песочница получает собственный Docker daemon, файловую систему и сетевой стек. Хостовый Docker Socket внутрь не пробрасывается.

Docker Documentation

Что изолируется

6

Компонент	Изоляция
Файловая система	Только выбранный workspace монтируется внутрь.
Docker Engine	Полностью отдельный daemon.
Network	Прокси фильтрует соединения по политикам.
Secrets	Передаются через sbx secret.
Kernel	Собственный kernel внутри microVM.

Почему это важно для GitLab CI

В GitLab исторически существует три варианта запуска Docker.

Сравнение подходов

Docker Socket	Docker-in-Docker	Docker Sandbox
Очень быстро.	Средняя скорость.	Немного медленнее запуска.
Небезопасно.	Нужен privileged.	Privileged не нужен внутри хоста.
Контейнер управляет хостом.	Общий kernel.	Отдельная microVM.
Нет сетевых политик.	Нет гибких политик.	Allow / Deny список сайтов.

Где Sandbox выигрывает

• CI/CD с недоверенным кодом.
• AI Code Review.
• BuildKit.
• Docker Compose внутри CI.
• Интеграционные тесты.
• Kubernetes manifests validation.

Как GitLab запускает Sandbox

GitLab Pipeline → Sandbox → Docker

Runner запускает sbx run, внутри microVM стартует Docker Engine, после чего контейнеры собираются и публикуются в GitLab Registry.

Установка Docker Sandbox

Поддерживаемые платформы

Платформа	Статус
Ubuntu 24.04 / 22.04	Поддерживается.
Debian 12	Поддерживается.
Windows 11	Поддерживается через Hypervisor Platform.
macOS Apple Silicon	Поддерживается.

Документация Docker рекомендует использовать отдельный пакет docker-sbx.

Docker Documentation+1

Linux

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh

sudo apt update
sudo apt install docker-sbx

Проверяем

sbx version

Авторизация Docker

sbx login

После логина Sandbox сможет использовать Docker Hub, Registry и секреты.

Docker Documentation

Первый Sandbox

mkdir demo
cd demo

sbx run bash

Получаем shell внутри microVM.

Проверяем окружение

uname -a

docker version

docker info

4

Обратите внимание:

• Docker daemon работает.
• /var/run/docker.sock отсутствует.
• Engine расположен внутри VM. Docker Documentation

Что находится внутри Sandbox

Каталог	Описание
/workspace	Ваш Git-проект.
/tmp	Временные файлы.
/var/lib/docker	Docker images внутри Sandbox.
/root/.cache	Кэш пакетов.

После удаления Sandbox всё исчезает.

Создание Docker образов внутри Sandbox

FROM alpine:3.22

RUN apk add curl git bash

CMD ["bash"]

Сборка.

docker build -t alpine-dev .

Запуск.

docker run --rm alpine-dev curl https://example.com

4

BuildKit работает автоматически

DOCKER_BUILDKIT=1 docker build .

Можно использовать:

• cache mounts;
• multi-stage builds;
• secrets;
• SSH forwarding.

5

Docker Compose внутри Sandbox

docker-compose.yml

services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: secret

  api:
    build: .
    depends_on:
      - postgres

Запуск.

docker compose up -d

5

Все контейнеры существуют только внутри VM.

Подключаем Sandbox к GitLab CI

Архитектурная схема

Устанавливаем Runner

4

docker run -d \
 --name gitlab-runner \
 --restart always \
 -v gitlab-runner-config:/etc/gitlab-runner \
 -v /var/run/docker.sock:/var/run/docker.sock \
 gitlab/gitlab-runner:latest

Затем внутри Runner устанавливаем docker-sbx.

Можно использовать кастомный образ Runner.

Dockerfile Runner

FROM gitlab/gitlab-runner:alpine

RUN apk add bash curl git

RUN curl -fsSL https://get.docker.com | sh

RUN apk add docker-sbx

Регистрируем Runner

gitlab-runner register

Выбираем Docker Executor.

Пример .gitlab-ci.yml

stages:
  - build

variables:
  DOCKER_BUILDKIT: "1"

build-image:
  stage: build

  script:
    - sbx run -- docker build -t app:${CI_COMMIT_SHA} .

Именно sbx run создаёт Sandbox и выполняет команду внутри неё.

Docker Documentation

Публикация образа в GitLab Registry

publish:
  stage: build

  script:
    - sbx run -- docker login registry.gitlab.com \
        -u $CI_REGISTRY_USER \
        -p $CI_REGISTRY_PASSWORD

    - sbx run -- docker build \
        -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

    - sbx run -- docker push \
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Использование секретов

Docker добавил собственный менеджер секретов.

sbx secret set github --command "gh auth token"

sbx secret set npm --value "$NPM_TOKEN"

Использование.

sbx run bash

echo $NPM_TOKEN

Секрет появляется только внутри Sandbox.

Docker Documentation

4

Настройка сетевых политик

Это одна из самых мощных возможностей.

Balanced режим

Проверяем.

sbx policy ls

Разрешаем Docker Hub.

sbx policy allow network registry-1.docker.io

Разрешаем GitLab.

sbx policy allow network gitlab.com

Open режим

sbx policy allow network "*"

Все сайты доступны.

Закрываем интернет полностью

sbx policy deny network "*"

Контейнер не сможет скачать пакеты.

Docker Documentation

Dashboard Sandboxes

Очень удобный TUI.

sbx

Показывает:

• CPU;
• RAM;
• контейнеры;
• Sandbox;
• сетевые запросы;
• политики.

Docker Documentation

Несколько Sandbox одновременно

sbx run --name backend bash

sbx run --name frontend bash

sbx run --name tests bash

Проверяем.

sbx ls

Работа с Git внутри Sandbox

Проект автоматически монтируется.

5

git status

git checkout feature/api

git commit -m "New API"

Файлы появляются на хосте.

Использование Claude Code / Codex / Cursor Agent

Это одна из главных причин появления Sandbox.

Почему

AI получает Dangerous Mode.

6

sbx run claude

или

sbx run codex

или

sbx run cursor-agent

Теперь агент может:

• запускать Docker;
• устанавливать пакеты;
• удалять файлы;
• выполнять shell-команды.

Но только внутри VM.

Docker Documentation+1

Использование Dangerous Mode безопасно

Docker специально рекомендует использовать Sandbox вместе с режимами --dangerously-skip-permissions и аналогичными режимами AI-агентов.

Andrew Lock | .NET Escapades+1

Интеграционные тесты PostgreSQL + Redis + RabbitMQ

4

integration:
  stage: test

  script:
    - sbx run -- docker compose up -d
    - sbx run -- pytest tests/

После завершения:

sbx rm integration

Кэширование зависимостей

Sandbox можно использовать совместно с GitLab Cache.

cache:
  paths:
    - .npm
    - .cache/pip
    - .gradle

4

Внутри Sandbox BuildKit использует собственный cache layer.

Declarative Sandbox Environment (.sbxenv.yaml)

Самая свежая возможность Docker Sandboxes.

Docker Documentation

Пример

name: dockerhosting-blog

agent: codex

workspace:
  path: .

env:
  NODE_ENV: development

ports:
  - 3000:3000

resources:
  cpu: 4
  memory: 8Gi

kits:
  - docker
  - node
  - python

registry:
  dockerhub: true

Запуск.

sbx env run

4

Теперь вся команда запускает идентичную Sandbox одной командой.

Ограничение CPU и памяти

sbx env create \
  --cpu 2 \
  --memory 4096

5

Можно задавать лимиты для CI.

Проброс портов

ports:
  - 8080:8080
  - 5432:5432

Запуск приложения.

docker compose up

5

Работа с Kubernetes

4

Внутри Sandbox можно запускать:

kind create cluster

kubectl get pods

или

k3d cluster create

Полностью изолированный Kubernetes.

Использование Buildx Multi-Platform

5

docker buildx create --use

docker buildx build \
 --platform linux/amd64,linux/arm64 \
 -t app:latest .

Sandbox отлично подходит для Buildx.

GitLab Matrix Build

build:
  parallel:
    matrix:
      - PLATFORM: linux/amd64
      - PLATFORM: linux/arm64

  script:
    - sbx run -- docker buildx build \
        --platform $PLATFORM .

4

Очистка Sandbox

Показать список.

sbx ls

Удалить одну.

sbx rm backend

Удалить всё.

sbx prune

Docker Sandbox vs Docker-in-Docker

4

Docker-in-Docker	Docker Sandbox
Требует privileged.	Не требует доступа к Docker Socket.
Общий kernel.	Собственный kernel.
Потенциальный breakout.	MicroVM защищает хост.
Сложнее ограничить сеть.	Гибкие политики сети.
Меньше изоляции секретов.	Secrets управляются отдельно.

Производительность

Что показывает практика

Операция	Особенности
Запуск Sandbox	Обычно 1–3 секунды.
Docker Build	Почти как BuildKit на хосте при использовании кэша.
Compose	Практически без изменений.
AI Agent	Есть небольшая задержка на I/O.

Некоторые пользователи отмечают, что большие проекты могут работать медленнее из-за виртуализации файловой системы, хотя Docker продолжает оптимизировать производительность.

Andrew Lock | .NET Escapades+1

Практический Pipeline для dockerhosting.ru

stages:
  - lint
  - test
  - build
  - publish

variables:
  DOCKER_BUILDKIT: "1"

before_script:
  - sbx login --token $DOCKER_TOKEN

lint:
  stage: lint
  script:
    - sbx run -- npm ci
    - sbx run -- npm run lint

tests:
  stage: test
  script:
    - sbx run -- docker compose up -d postgres redis
    - sbx run -- pytest
    - sbx run -- docker compose down

build:
  stage: build
  script:
    - sbx run -- docker build \
        -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

publish:
  stage: publish
  script:
    - sbx run -- docker login \
        registry.gitlab.com \
        -u $CI_REGISTRY_USER \
        -p $CI_REGISTRY_PASSWORD

    - sbx run -- docker push \
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Безопасность Docker Sandboxes

6

Что защищает Sandbox

Механизм	Назначение
MicroVM	Изоляция ядра Linux.
Namespaces	Изоляция процессов.
Network Proxy	Контроль доступа к интернету.
Secrets	Секреты не сохраняются в VM.
Disposable filesystem	Удаляется после завершения.

Docker позиционирует Sandboxes как безопасную среду для автономных AI-агентов и потенциально недоверенного кода.

Docker Documentation+1

Когда использовать Docker Sandbox в GitLab

Сценарий	Рекомендация
Сборка Docker-образов	Да.
BuildKit / Buildx	Да.
Docker Compose интеграционные тесты	Да.
AI Agent (Claude, Codex, Cursor)	Да — один из основных сценариев.
Недоверенные Merge Request	Да — высокая степень изоляции.
Запуск Kind / K3d Kubernetes	Да.
Максимально быстрые локальные сборки	Иногда быстрее остаётся обычный Docker Engine.

Итоги

Docker Sandboxes — это существенный шаг вперёд по сравнению с классическими схемами docker.sock и Docker-in-Docker. Вместо контейнера с общим ядром разработчик получает полностью изолированную microVM с собственным Docker Engine, управляемую через CLI sbx. Для GitLab CI это означает возможность безопасно собирать контейнеры, запускать Docker Compose, BuildKit, Kubernetes-in-Docker и AI-агентов без риска компрометации Runner-хоста. Новая возможность также добавляет сетевые политики, управление секретами и декларативные окружения через .sbxenv.yaml, что делает пайплайны воспроизводимыми и удобными для командной разработки.

Docker Documentation+2

Иллюстрации, использованные в статье

В статье предусмотрены схемы и изображения для публикации в блоге:

1. Hero-баннер Docker Sandboxes.
2. Архитектура Host → MicroVM → Docker Engine.
3. Схема GitLab CI → Runner → Sandbox → Registry.
4. Схема сетевой изоляции и Network Policy.
5. BuildKit / Buildx внутри Sandbox.
6. Docker Compose внутри Sandbox.