Development containers

A development container packages a project’s toolchain, dependencies, and configuration into a reproducible image, so every developer, and every automated job, works in an identical environment. Running Syntic Code inside a dev container is a natural fit: the agent gets a clean, well-defined workspace, and any command it runs is contained within the image rather than touching the host. This makes the container both a consistency tool and a safety boundary.

Why run the agent in a container

Containers give you three benefits at once. They make behavior reproducible, since the same image yields the same tools whether the agent runs on a laptop or a build server. They contain risk, because the agent’s shell commands act inside the container and cannot reach the host filesystem or network beyond what you allow. And they simplify onboarding, since a new developer gets a fully configured environment, Syntic Code included, by opening the project rather than following a setup checklist.

Adding Syntic Code to a container image

Install the pinned syntic binary as a step in your container definition so it is present in every build of the image:

ARG SYNTIC_VERSION=1.8.0
RUN curl -fsSL "https://downloads.syntic.ai/cli/${SYNTIC_VERSION}/syntic-linux-x64" \
      -o /usr/local/bin/syntic \
 && chmod +x /usr/local/bin/syntic

Bake in the tools the agent will need for the project, such as the language runtime, package manager, and test harness, so its shell commands have everything to work with.

Credentials and configuration

Never bake a key into the image, which would leak to anyone who pulls it. Inject the Syntic credential at runtime as an environment variable from your secret manager, and mount a project .syntic/settings.json so the container inherits your permission rules and model tier. Because the container already isolates the agent, it pairs well with auto mode for automated tasks: the image is the sandbox, and the settings inside it are the policy.