Docker products

code-airlock Website: trivo25.github.io/code-airlock Run Claude Code, Codex, OpenCode, or another coding agent in a disposable microVM, then review its work as normal git commits. Code Airlock is a small wrapper around Docker Sandboxes for people who want to let coding agents work with fewer prompts without giving them direct access to the host machine. Why Use It Coding agents are most useful when they can install packages, run tests, inspect failures, and iterate without asking before every command. That is also exactly when you want a stronger boundary than process-level deny rules. Code Airlock keeps the workflow simple: You want Code Airlock does Run agents unattended Starts the selected agent inside a Docker Sandbox microVM Keep your local repo clean Uses clone mode, so the host repo is mounted read-only Review everything first Pulls sandbox commits back with fetch, diff, and merge Limit network access Can apply a configurable allowlist for model APIs and package registries Switch agents Uses AGENT=claude, AGENT=codex, AGENT=opencode, and other Docker Sandbox agents Why Let the Agent Run Freely? Coding agents are most effective when they can use the tools needed to finish the task: install dependencies, inspect generated files, run test suites, start local services, read logs, and iterate on failures. Over-constraining every shell command often turns the agent into a slower autocomplete loop. Code Airlock moves the main safety boundary below the agent. The agent can work with more autonomy inside a disposable microVM, while the host repo stays read-only and the resulting changes still come back as commits for review. Why Not Just Use sbx Directly? You can. Code Airlock is intentionally a thin wrapper around Docker Sandboxes, not a replacement for it. Use sbx directly when you want full control over sandbox lifecycle, policies, kits, and one-off experiments. Use Code Airlock when you want the common coding-agent loop already wired together: clone mode by default stable sandbox naming per repo one-command agent startup repo-local AGENTS.md scaffolding fetch, diff, review, and merge commands for the sandbox branch a documented credential and network-policy path for Claude Code, Codex, and OpenCode The point is to make the safe workflow boring and repeatable while still leaving sbx available underneath. Why Not Just Configure the Agent Harness Better? Agent harness rules are useful, and Code Airlock is meant to work with them. Codex approvals, Claude Code permissions, OpenCode settings, AGENTS.md, and custom prompts all help shape what the agent should do. Those rules are still policy inside the agent process. They do not give you a disposable VM, a read-only host repo, a separate clone for agent commits, or a host-side review step before changes land. They also do not provide a shared wrapper for Claude Code, Codex, OpenCode, and other agents. Code Airlock treats harness rules as the first layer and Docker Sandboxes as the boundary underneath it. The agent can be configured to behave well; the sandbox limits what happens when it does not. Quick Start Install Docker Sandboxes first. On Linux: curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh sudo apt-get install docker-sbx sudo usermod -aG kvm $USER newgrp kvm sbx login On macOS and Windows, follow Docker's official install guide. Install Code Airlock with npm: npm install -g code-airlock Or with Homebrew (head-only formula until a tagged release exists): brew tap trivo25/code-airlock https://github.com/Trivo25/code-airlock brew install --HEAD code-airlock Once the CLI is installed, it can walk you through any missing prerequisites: code-airlock setup # guided install; shows each command and asks before running it code-airlock doctor # checks only, changes nothing Or use the standalone shell installer: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | sh The shell installer also adds a short codelock alias when that command is not already taken: codelock up codelock status codelock attach The npm package intentionally installs only code-airlock, because codelock is already an npm package name. Add a personal shell alias if you want the shorter command after npm install: alias codelock=code-airlock Or clone it manually: git clone https://github.com/Trivo25/code-airlock.git cd code-airlock ln -s "$PWD/code-airlock" ~/.local/bin/code-airlock The installer writes to ~/.local/bin by default. Choose another location with: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | PREFIX=/usr/local/bin sh Skip or rename the short alias: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | CODE_AIRLOCK_INSTALL_ALIAS=0 sh curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | CODE_AIRLOCK_ALIAS=calock sh Run a Task The shortest loop, one command in and ordinary Git review out: code-airlock run "add pagination to the users endpoint and run the tests" code-airlock diff code-airlock merge run starts the sandbox like up and hands the task to the agent's non-interactive mode: -p for Claude Code, exec --dangerously-bypass-approvals-and-sandbox for Codex, and run for OpenCode. Other agents receive the task as a plain argument. Install - Agent Already using a coding agent? Send it this: Install Code Airlock in this environment, then run its first-run checks. Use npm when available: npm install -g code-airlock If npm is unavailable, use: curl -fsSL https://raw.githubusercontent.com/Trivo25/code-airlock/main/install.sh | sh After install, make sure code-airlock is on PATH, then run: code-airlock doctor code-airlock --dry-run up Do not start a real sandbox or change network policy unless I explicitly ask. Run it from the repo you want the agent to work on: cd ~/code/my-project code-airlock doctor # check sbx, virtualization, login, and git code-airlock --dry-run up # preview the sbx commands without running them code-airlock init # optional: add starter AGENTS.md instructions code-airlock up # start Claude Code in a sandbox code-airlock --seed-config up # optionally copy user-level agent customizations code-airlock status # see this repo's sandbox and tmux session On a remote server, keep the agent running after your SSH connection closes: code-airlock --tmux up # detach with Ctrl-b, then d code-airlock attach # reattach later Use another agent: code-airlock --agent codex up code-airlock --agent opencode run "fix the build" The AGENT environment variable and the sandbox.conf setting still work; the --agent flag wins when both are set. When the agent has made changes, review them from your host: code-airlock fetch code-airlock diff code-airlock review # optional: open a visual diff code-airlock merge Prefer a pull request over a local merge: code-airlock pr # push the sandbox branch and open a PR code-airlock pr main feature/foo # explicit base and branch name The push happens from the host with your credentials, so the sandbox still needs no GitHub access. pr uses gh when it is installed and prints the GitHub compare URL otherwise. The default branch name is code-airlock/<sandbox-name>; override it with the second argument or PR_BRANCH. How It Works Code Airlock starts Docker Sandboxes with --clone: Docker creates a private clone inside the sandbox VM. The agent edits and commits inside that clone. Your host repo stays read-only while the agent runs. You fetch the sandbox branch into your local repo and review the diff. You merge only when you are satisfied. If initialized submodules exist, fetch, diff, review, and merge also try to import each sandbox submodule's HEAD commit into the matching host submodule. Submodule commits are fetched into: refs/remotes/code-airlock/<sandbox-name> This lets the parent repo merge point at submodule commits that the host can actually check out. Disable this with FETCH_SUBMODULES=0 for parent-only fetch behavior. This means uncommitted sandbox edits do not come back through the normal flow. If needed, enter the sandbox and commit first: code-airlock shell git status git add -A git commit -m "describe the agent work" exit Then fetch and review from the host. First-Run Checks Most setup failures come from missing Docker Sandboxes, missing KVM/virtualization support, or an unauthenticated sbx CLI. Check before launching: code-airlock doctor Preview what Code Airlock would run without creating a sandbox: code-airlock --dry-run up Dry-run mode prints the sbx and git commands instead of running them. It is useful on machines that cannot run KVM yet, or when you want to understand the workflow before creating a VM. Remote / Server Runs Use --tmux to start the sandboxed agent inside a host-side tmux session: code-airlock --tmux up This attaches immediately so you can talk to the coding agent. To disconnect without stopping it, press Ctrl-b, then d. This detaches your terminal and leaves the agent running in the tmux session. Reattach later with: code-airlock attach For an unattended server run, start the tmux session without attaching: code-airlock --tmux-detached up The default session name is code-airlock-<sandbox-name>. Override it with: TMUX_SESSION=agent-work code-airlock --tmux up TMUX_SESSION=agent-work code-airlock attach For a visual review, use: code-airlock review This fetches the sandbox branch and opens a Git directory diff using VS Code by default. Your working tree is not modified by the review command. Use another Git difftool: REVIEW_TOOL=opendiff code-airlock review REVIEW_TOOL=vimdiff code-airlock review Agent Instructions Agents work better when the repo contains concise project instructions. Code Airlock can create a starter file: code-airlock init This writes AGENTS.md in the target repo only if one does not already exist. code-airlock up will mention the command when no AGENTS.md is present, but it will not silently modify your working tree. Config Seeding By default, a sandbox starts with a fresh agent home directory. Project files that are committed to Git come through clone mode, but personal commands, skills, subagents, and global instructions from your host home directory do not. Opt in to copying curated user-level config before the agent starts: code-airlock --seed-config up This changes startup from one sbx run call to: sbx create --clone ... sbx cp ... sbx run --name ... Default seeded paths: Agent Paths Claude Code ~/.claude/CLAUDE.md, ~/.claude/commands/, ~/.claude/agents/, ~/.claude/skills/ Codex ~/.codex/AGENTS.md, ~/.codex/AGENT.md, ~/.codex/agents/, ~/.codex/skills/, ~/.codex/prompts/ OpenCode ~/.config/opencode/AGENTS.md, ~/.config/opencode/opencode.jsonc, ~/.config/opencode/commands/, ~/.config/opencode/agents/, ~/.config/opencode/skills/ Code Airlock does not copy auth files, histories, logs, caches, session state, or node_modules by default. Credentials should still go through Docker Sandboxes' secret manager. Copy explicit extra user-level paths with: SEED_PATHS="$HOME/.codex/config.toml,$HOME/.claude/settings.json" code-airlock --seed-config up SEED_PATHS entries must be under $HOME; secret-like paths are skipped. Gitignored project-local files are not copied by default. Prefer committing project instructions such as AGENTS.md, CLAUDE.md, and .claude/commands/ when they are meant to travel with the repo. Authentication Model credentials should go through Docker Sandboxes' secret manager or host-side auth flow, not be pasted into the VM. Common setup: sbx secret set -g anthropic # Claude Code API key sbx secret set -g openai --oauth # Codex OAuth sbx secret set -g openai # Codex/OpenCode API key Agent-specific notes: Agent Authentication Claude Code Run code-airlock up and use /login inside Claude, or store an Anthropic key with sbx secret set -g anthropic Codex Use sbx secret set -g openai --oauth, sbx secret set -g openai, or export OPENAI_API_KEY before launch OpenCode Store the provider keys you use, such as openai, anthropic, google, xai, groq, aws, or openrouter Sandboxes do not carry user-level config such as ~/.claude or ~/.codex into the VM by design. Put project-level config in the repo if the agent needs it. GitHub Credentials Code Airlock does not need GitHub credentials for the normal fetch/diff/merge review loop. Give the sandbox GitHub access only if you want the agent to use gh, open pull requests, create issues, or push directly from inside the VM: echo "$(gh auth token)" | sbx secret set -g github Global secrets apply when a sandbox is created. For an existing sandbox, either recreate it or scope the token to that sandbox:

tinyreplay tinyreplay is a small, self-hosted session replay tool. It records browser sessions with a browser SDK, stores replay batches in local SQLite, and shows them in a local dashboard. It is for indie developers and small teams that want to inspect what happened in a browser session without adopting a full analytics platform. tinyreplay is intentionally minimal. It does not provide funnels, heatmaps, feature flags, user profiles, accounts, billing, mobile SDKs, hosted storage, SSO, distributed ingestion, or compliance guarantees. tinyreplay is pre-1.0. The core local session replay flow works, but APIs, storage format, configuration, and dashboard behavior may change before v1. The v0.1.0 release should be treated as an early self-hosted release. Documentation: https://tinyreplay.hane.studio. Quick Start From a checkout: npm install npm run build npm run start Open http://localhost:3000. For development: npm install npm run dev npm run dev:docs The SDK runs in watch mode, the dashboard runs at http://localhost:3000, and the docs app runs at http://localhost:3001. Docker Run the published image (no checkout, no build): docker run -p 3000:3000 -v "$(pwd)/data:/app/data" ghcr.io/kzekiue/tinyreplay Open http://localhost:3000. Session data persists in ./data/tinyreplay.db on the host. The latest tag tracks main; tagged releases publish a versioned image (for example ghcr.io/kzekiue/tinyreplay:0.1.0). To build from source instead (for development or local changes): docker compose up --build The compose file mounts ./data to /app/data. The equivalent plain Docker commands: docker build -t tinyreplay . docker run --rm -p 3000:3000 -v "$(pwd)/data:/app/data" tinyreplay Useful endpoints: Purpose URL Dashboard http://localhost:3000 SDK bundle http://localhost:3000/sdk/tinyreplay.umd.js Ingest API POST http://localhost:3000/api/ingest Health probe GET http://localhost:3000/api/health SDK Setup Use the bundle served by your tinyreplay server: <script src="http://localhost:3000/sdk/tinyreplay.umd.js"></script> <script> TinyReplay.init({ endpoint: 'http://localhost:3000', projectId: 'my-project', }) </script> Or install the package after it is published: npm install @tinyreplay/sdk import { TinyReplay } from '@tinyreplay/sdk' TinyReplay.init({ endpoint: 'https://your-tinyreplay-instance.example', projectId: 'my-project', }) TinyReplay.init() is a no-op during server-side rendering and ignores repeated calls while a recorder is active. TinyReplay.stop() stops recording and flushes the current buffer. Example App The dependency-free example in examples/vanilla records clicks, input, scrolling, route changes, masking, and ignored elements. npm run build npm run start python3 -m http.server 4173 -d examples/vanilla Open http://localhost:4173, interact with the page, then open http://localhost:3000 and select the session. Storage tinyreplay stores data in SQLite through better-sqlite3. The server creates one database file: DATA_DIR/tinyreplay.db Local default: ./data/tinyreplay.db Docker default: /app/data/tinyreplay.db Replay event batches are stored as JSON in the events table and connected to rows in the sessions table. Retention is off by default. Set RETENTION_DAYS to delete older sessions during the hourly sweep. Privacy Defaults Masking happens in the browser before replay events are sent to the server. Defaults: Setting Behavior maskAllInputs Enabled by default for inputs, textareas, and selects. data-tr-mask Masks text inside the marked element and its children. data-tr-unmask Allows a specific non-sensitive input to be recorded. data-tr-ignore Blocks an element and its children from recording. The SDK records console messages and error messages for debugging. It records network metadata only: method, URL, status, and duration. It does not read request bodies, response bodies, request headers, response headers, cookies, or browser storage, except for its own session id in sessionStorage. Do not log secrets from the recorded app. Console capture records argument text. Configuration Copy .env.example to .env for local overrides. Variable Default Purpose PORT 3000 Server port. DATA_DIR ./data locally, /app/data in Docker SQLite directory. ALLOWED_ORIGINS * Comma-separated CORS allowlist for ingestion. DASHBOARD_PASSWORD unset Enables HTTP Basic auth for dashboard pages. INGEST_TOKEN unset Requires a token for POST /api/ingest. RETENTION_DAYS unset Deletes sessions older than this many days. RATE_LIMIT_PER_MIN 100 Ingest requests per minute per IP. MAX_PAYLOAD_BYTES 5000000 Maximum ingest request body size. Set DASHBOARD_PASSWORD, INGEST_TOKEN, and a narrow ALLOWED_ORIGINS value before exposing an instance outside a trusted network. Put TLS and stronger access control in front of tinyreplay with a reverse proxy. Development npm install npm run dev npm run check Common commands: Command Purpose npm run check Release check: format, lint, architecture, typecheck, forbidden content, secret scan, build, tests. npm run build Build the SDK, server, and docs app. npm run dev:docs Run the docs app on port 3001. npm run test Run SDK and server tests. npm run lint Run ESLint. npm run typecheck Run TypeScript checks. npm run clean Remove build and coverage output. See CONTRIBUTING.md for contribution rules and ARCHITECTURE.md for the current module boundaries. Security Report security issues privately. See SECURITY.md.

Docker

Explore categories

How Product Visit works