What is aerovato/container?

aerovato/container gives each project its own Docker or Podman environment with coding harnesses preinstalled, and keeps packages and configuration between sessions. It is a good fit for one machine running several agent-driven projects, and a poor fit if you need hardened isolation from an untrusted agent.

Can I use aerovato/container commercially?

Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is aerovato/container still maintained?

Yes. The repository last received commits 14 days ago.

What programming language is aerovato/container written in?

Mainly TypeScript, according to GitHub's language statistics.

aerovato/container: persistent agent workspaces

At a glance

What is it?: aerovato/container gives each project its own Docker or Podman environment with coding harnesses preinstalled, and keeps packages and configuration between sessions. It is a good fit for one machine running several agent-driven projects, and a poor fit if you need hardened isolation from an untrusted agent.
Who is it for?: Adopt aerovato/container if you run several agent-driven projects on one workstation and want each one's packages and configuration to survive between sessions, with a user layer at ~/.code-container/Dockerfile.User for extra tooling.
Can I use it commercially?: Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 14 days ago.
What is it written in?: Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 15, 2026 · aerovato/container

The problem aerovato/container solves, and for whom

Agentic coding tools assume a machine you control. In practice you have one laptop, several projects, and a growing pile of per-project dependencies that collide. Project A pins an old Node version, project B wants a different Python, and the agent working in either one can read everything else on disk. aerovato/container answers that with one environment per project: each project gets its own Docker or Podman environment with coding harnesses and development tools already installed, and the workspace persists across sessions, including packages and configuration. The README states that agents are isolated to that project with no access to the rest of your system. The same Linux environment is described as running on Windows, macOS, and Linux, and the tool is local, open source, and requires no account.

The intended user is a developer who already runs a coding agent and wants a repeatable box for it rather than a hand-maintained shell script. The repository topics list the harness ecosystem it targets: anthropic, claude-code, codex, copilot, opencode, and others. If you only ever work in one project, the setup cost of a shared image plus per-project containers buys you little.

How the workspace, image, and user layer fit together

There are three moving parts. The runtime is your existing Docker or Podman install. On top of it sits a shared image that carries coding harnesses and development tools. On top of that sits a user layer: packages and setup commands you add in ~/.code-container/Dockerfile.User, which the project describes as the place for customization. Common settings like tools and harnesses go through container settings, while runtime flags, mounts, and base-image settings live in ~/.code-container/settings.json.

At run time you navigate to a project and start its workspace. The project is mounted at /root/<project-name>, and the README notes that the current project is mounted read-write, so the agent can change or delete it. Multiple terminals can enter the same container, which is what makes the persistence claim useful in practice: a package you install in one terminal is still there in the next session. The rebuild commands are split by layer, container build tools, container build harness, and container build user, which tells you the image is layered rather than monolithic. That split is the main design decision worth understanding before you adopt it: changing a harness does not force you to rebuild your user packages, and vice versa.

Installing aerovato/container and starting a first workspace

The README lists Windows, macOS, or Linux plus Docker or Podman as the only requirements. On macOS and Linux the install is a shell script piped to sh:

bash

curl -fsSL https://container.aerovato.com/install.sh | sh

On Windows PowerShell the equivalent is:

powershell

irm https://container.aerovato.com/install.ps1 | iex

There is also an npm route, which is the one to pick if you already manage global Node tooling:

bash

npm install -g @aerovato/container

After installing, run the guided onboarding flow. According to the README you choose your coding harnesses, development tools, runtime, and mounts, then accept the initial image build. Expect that first build to take a while; it is assembling the shared image.

bash

container init

Then go to a project and start its workspace. The README gives this example, and notes the project is mounted at /root/<project-name>:

bash

cd /path/to/project
container

Inside the workspace you start your preferred coding agent and work normally. The README shows this pair:

bash

opencode
npm install <package>

The package you install there survives the session. If you need to reach a service from the host, the README shows runtime flags being passed after a double dash:

bash

container run /path -- -p 8080:80

Where the isolation claim stops

The security section of the README is unusually direct, and it should shape how you use the tool. It states that container limits what an agent can access but does not make the agent trusted. The current project is mounted read-write and can be changed or deleted. Enabled configurations and optional credentials may also be available inside the container. Containers retain network access. And the README says container does not protect against prompt injection or agent misalignment.

Read that list as the boundary of the product. If your goal is to run an agent against an untrusted repository and be confident nothing on your machine is reachable, this is not that tool; the mount is read-write by design, and network access is not removed. The README's own guidance is to keep important work under version control and only mount resources the agent needs. The second half of that sentence is the actionable part, because mounts are configurable through ~/.code-container/settings.json and the onboarding flow. A second limitation is environmental: the requirements are Docker or Podman, so a host where you cannot install either is out. A third is that the agent skill is host-side, and the README explains why: agents inside managed containers cannot access Container's host configuration. If you wanted the agent to reconfigure its own container from the inside, that path is closed.

aerovato/container compared with a plain Dockerfile per project

The obvious alternative is what most teams already do: a Dockerfile and a compose file per repository, built and run by hand or by a Makefile. The difference is in what is managed for you. With a plain Dockerfile you decide the base image, install the harness yourself, and solve mount paths, terminal access, and rebuild ergonomics on your own. aerovato/container ships the harness and tool layer, keeps per-project state outside the repository, and exposes a small command set (container, container run, container list, container stop, container remove, container settings, container init) plus layer-specific rebuilds. The trade-off is that you inherit its layering model. Your customization goes into ~/.code-container/Dockerfile.User and is rebuilt with container build user, rather than into a Dockerfile you fully control. If your build needs a custom base image or a multi-stage pipeline, ~/.code-container/settings.json is where base-image settings are documented to live, but the README does not walk through that path in detail.

A second alternative is a remote development environment hosted elsewhere. That solves the same isolation problem but moves your code off the machine and typically requires an account; the README states container is local and does not require an account. For a developer who wants the workspace on their own disk, that distinction is the whole argument.

Maintenance, releases, and licence

The repository is not archived, and the last push was on 2026-09-02. Recent releases are v3.5.6 on 2026-09-01, v3.5.5 on 2026-08-22, and v3.5.4 on 2026-08-17, so the cadence over that window is roughly weekly patch releases. The version in package.json matches the latest release, 3.5.6, which means the published npm package tracks the repository tag. For upgrade cost, the README directs you to rebuild the shared image when updating tools or customizations, with container build and the layer-specific variants. Budget for the image build itself, not just the download.

On licensing there is a discrepancy worth checking before you depend on it. The repository is listed under BSD-3-Clause and the README links to LICENSE.md under that heading, but the package.json declares "license": "MIT". Only the file in the repository is authoritative for the code you are distributing; confirm which one applies to your use rather than assuming either. This is a factual mismatch, not legal advice.

On project tooling: the repository is maintained with Operator Memory, and the README says the published brain lives in .operator-shared/. The build scripts are shell based (scripts/build-js.sh, scripts/build-binary.sh), tests run through vitest, and the website is an Astro project under website/. If you plan to contribute, the precommit path is bash scripts/precommit.sh via husky.

Editorial conclusion

Adopt aerovato/container if you run several agent-driven projects on one workstation and want each one's packages and configuration to survive between sessions, with a user layer at ~/.code-container/Dockerfile.User for extra tooling. Do not adopt it if you expect the container to make an untrusted agent safe: the README states plainly that the current project is mounted read-write, that enabled configurations and optional credentials may be available inside the container, and that it does not protect against prompt injection or agent misalignment. Verify first that your runtime is Docker or Podman, that the initial image build succeeds on your machine, and that the project you are mounting is under version control before you point an agent at it.

Frequently asked questions

How do I use aerovato/container with an existing project?

Install it, run container init to choose harnesses, tools, runtime, and mounts, then cd into the project and run container. The project is mounted at /root/<project-name> and the container persists between sessions.

Does aerovato/container work with Podman as well as Docker?

Yes. The README lists the requirement as Docker or Podman, and the onboarding flow asks you to choose your runtime.

How do I install aerovato/container?

On macOS and Linux the README gives a curl install script piped to sh, on Windows PowerShell an irm script piped to iex, and there is also npm install -g @aerovato/container.

Is aerovato/container safe to run an untrusted agent in?

The README states that container limits what an agent can access but does not make the agent trusted, that the current project is mounted read-write, and that it does not protect against prompt injection or agent misalignment. Containers also retain network access.

How do I add my own packages to aerovato/container?

Add packages and setup commands to the user layer at ~/.code-container/Dockerfile.User, then rebuild with container build user.

What licence is aerovato/container under?

The repository is listed as BSD-3-Clause and the README links to LICENSE.md, but package.json declares MIT. Check the repository licence file for the terms that apply to your use.

Official sources

Community notes