local-environment
Configures and maintains local development environments using Docker containers to ensure consistent dependency states.
Install
mkdir -p .claude/skills/local-environment && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/5219" && unzip -o skill.zip -d .claude/skills/local-environment && rm skill.zipInstalls to .claude/skills/local-environment
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Local development environment management for Polar using DockerKey capabilities
- →Start local stack
- →Manage parallel worktree instances
- →View service logs
- →Execute commands in containers
- →Configure preview environments
How it works
The skill manages a two-part Docker stack, splitting shared infrastructure from per-instance application containers.
Inputs & outputs
When to use local-environment
- →Setting up local development
- →Managing dockerized environments
- →Standardizing dev environment config
About this skill
Local Environment Skill
Helps manage the Polar local development environment through the dev docker
CLI. Use it to start, stop, debug, or reason about the local stack.
The two-part model
dev docker deliberately splits the stack so many worktrees can share one set
of heavy infra:
- Shared infra — one copy per machine, Docker project
polar-shared: postgres, redis, minio, tinybird, and optional prometheus/grafana. Postgres and redis publish no host ports; MinIO exposes 9000/9001 for browser uploads. Usedev docker exec <service> ...for services without host ports. - Per-instance app stack — one per worktree, project
polar-app-<N>: api, worker, web. Only api and web publish host ports, offset per instance so worktrees don't collide.
Knowing this prevents the most common confusion: there is no localhost:5432
for the database (it lives in the shared stack and is reached through
dev docker exec db ...). MinIO does expose ports 9000/9001 for browser
uploads and console access.
Instance auto-detection
dev docker auto-detects the instance for the current worktree, so -i is
rarely needed. Priority:
POLAR_DOCKER_INSTANCEpinned indev/docker/.env.docker(dev docker set-instance N)CONDUCTOR_PORTenv var →(port - 55000) / 10 + 1- The cross-worktree registry (
~/.config/polar/docker-instances.json) - Otherwise the lowest free number, then registered
Run dev docker ports to see the resolved instance and its URLs (add --json
for tooling). To wire this worktree into Claude Code's preview, run
dev docker launch-json, which writes a per-instance .claude/launch.json with
the correct ports (it's gitignored, so regenerate after set-instance).
When to use
- Start / stop / restart the local environment
- View logs or debug a service that won't come up
- Run several isolated worktree instances in parallel
- Understand the service architecture or find a service's real port
- Diagnose container or first-boot errors
Quick reference
| Task | Command |
|---|---|
| Start full stack (background) | dev docker up -d |
| Start and block until healthy | dev docker up -d --wait |
| Start in foreground (stream logs) | dev docker up --no-detach |
| Rebuild with fresh base images | dev docker up -b --pull -d |
| Show this instance's ports/URLs | dev docker ports (--json for tooling) |
| Write Claude Code preview config | dev docker launch-json |
| Stop app stack | dev docker down |
| Stop app and shared infra | dev docker down --all |
| Follow logs | dev docker logs -f [service] |
| Print logs and exit | dev docker logs --no-follow [service] |
| Status | dev docker ps |
| Restart a service | dev docker restart <service> |
| Shell into a service | dev docker shell <service> |
| One-off command in a service | dev docker exec <service> <cmd> |
| Reset this instance | dev docker cleanup -f |
| Wipe ALL shared data | dev docker cleanup --all -f |
| List every instance | dev docker list |
| With monitoring | dev docker up --monitoring -d |
Services
| Service | Project | Host port (instance 0 / N) | Notes |
|---|---|---|---|
| api | polar-app-<N> | 8000 / 8100+N | FastAPI; /healthz healthcheck |
| web | polar-app-<N> | 3000 / 3100+N | Next.js; healthchecked |
| worker | polar-app-<N> | none | Background jobs |
| db | polar-shared | none (exec) | PostgreSQL; DB polar_dev_<N> |
| redis | polar-shared | none (exec) | Redis DB index = N |
| minio | polar-shared | 9000, 9001 | S3; buckets polar-s3-<N>; console at 9001 |
| tinybird | polar-shared | none (exec) | Analytics |
| prometheus / grafana | polar-shared | none (exec) | --monitoring only |
Discover the exact host ports for the current worktree with dev docker ports.
Instance port mapping
Only api and web get host ports: Port = Base + Instance (Base 8100 for api,
3100 for web) for instances 1–99. Instance 0 uses the legacy 8000 / 3000.
| Instance | API | Web |
|---|---|---|
| 0 | 8000 | 3000 |
| 1 | 8101 | 3101 |
| 2 | 8102 | 3102 |
| 5 | 8105 | 3105 |
Everything else is per-instance but not on a host port: database polar_dev_<N>,
redis DB index <N>, buckets polar-s3-<N> / polar-s3-public-<N>. Reach them
via dev docker exec <service> or docker exec polar-shared-<service>-1.
Rules index
| Rule | Category | Description |
|---|---|---|
| service-architecture | Reference | Service details, ports, healthchecks |
| start-environment | Operations | Starting the stack (flags, --wait, --pull) |
| stop-environment | Operations | Stopping and cleanup (app vs shared) |
| manage-instances | Operations | Parallel worktree instances |
| view-logs | Debugging | Viewing service logs |
| shell-and-workflows | Operations | Shell access and common dev workflows |
| troubleshooting | Debugging | Common errors and fixes |
| payment-testing | Operations | Login codes, Stripe webhooks, backoffice |
When not to use it
- →Direct database access without exec
Prerequisites
Limitations
- →Database and redis are not exposed on host ports
- →Requires dev docker CLI
How it compares
It automates instance detection and port mapping across multiple worktrees, avoiding manual Docker configuration.
Compared to similar skills
local-environment side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| local-environment (this skill) | 1 | 28d | Review | Beginner |
| deployment-engineer | 4 | 4mo | No flags | Advanced |
| devops | 2 | 6mo | Review | Intermediate |
| ecs | 2 | 3mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
deployment-engineer
sickn33
Expert deployment engineer specializing in modern CI/CD pipelines, GitOps workflows, and advanced deployment automation. Masters GitHub Actions, ArgoCD/Flux, progressive delivery, container security, and platform engineering. Handles zero-downtime deployments, security scanning, and developer experience optimization. Use PROACTIVELY for CI/CD design, GitOps implementation, or deployment automation.
devops
mrgoonie
Deploy to Cloudflare (Workers, R2, D1), Docker, GCP (Cloud Run, GKE), Kubernetes (kubectl, Helm). Use for serverless, containers, CI/CD, GitOps, security audit.
ecs
itsmostafa
AWS ECS container orchestration for running Docker containers. Use when deploying containerized applications, configuring task definitions, setting up services, managing clusters, or troubleshooting container issues.
exa-deploy-integration
jeremylongshore
Deploy Exa integrations to Vercel, Fly.io, and Cloud Run platforms. Use when deploying Exa-powered applications to production, configuring platform-specific secrets, or setting up deployment pipelines. Trigger with phrases like "deploy exa", "exa Vercel", "exa production deploy", "exa Cloud Run", "exa Fly.io".
openevidence-deploy-integration
jeremylongshore
Deploy OpenEvidence integrations to healthcare production environments. Use when deploying to production, setting up staging environments, or configuring cloud deployments for clinical AI applications. Trigger with phrases like "deploy openevidence", "openevidence staging", "openevidence production deploy", "release openevidence".
ugoite-release
ugoite
Use when touching release, packaging, Docker, Helm, or install/update flows.