polar-local-environment

Featured

This skill should be used when setting up or managing Polar local development environment with Docker.

AI & Automation 822 stars 70 forks Updated 2 days ago Apache-2.0

Install

View on GitHub

Quality Score: 95/100

Stars 20%
97
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# 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. Use `dev 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: 1. `POLAR_DOCKER_INSTANCE` pinned in `dev/docker/.env.docker` (`dev docker set-instance N`) 2. `CONDUCTOR_PORT` env var → `(port - 55000) / 10 + 1` 3. The cross-worktree registry (`~/.config/polar/docker-instances.json`) 4. Otherwise the lowest free number, then registered Run `dev docker ports` to see the resolved instance and its URL...

Details

Author
fcakyon
Repository
fcakyon/claude-codex-settings
Created
1 years ago
Last Updated
2 days ago
Language
Python
License
Apache-2.0

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

devcontainer-designer

Design a reproducible dev environment (Dev Container / Docker) so onboarding is one command and 'works on my machine' dies — by detecting the project's real stack and versions, authoring a devcontainer.json (+ Dockerfile/compose) that pins the runtime to what the repo targets, wires dependent services, caches dependencies, and injects secrets instead of baking them. Use when new contributors struggle to set up the project, when environment drift causes inconsistent behavior, or when standardizing tooling across a team.

1 Updated 1 weeks ago
imtiazrayhan
DevOps & Infrastructure Listed

environments

Virtual-environment-first setup for robotics projects: decide uv/venv vs Docker, make local and remote-server runs reproduce identically, handle GPU passthrough and headless/display forwarding. Use when: setting up any new robotics project environment; 'uv', 'venv', 'virtualenv', 'docker for this project', 'reproducible environment', 'works locally but not on the server', 'GPU in container'. Load early in any robium build, right after architect. Decision rule of thumb: pure-Python ML stacks → uv; anything needing ROS 2 or system deps → Docker. Not for: multi-module application Dockerfiles and compose wiring (integration skill).

0 Updated yesterday
robium-ai
API & Backend Solid

michel-run-local-dev-stack

The canonical recipe for starting, checking, and stopping the Packmind local dev stack with Docker Compose — the single source of truth other skills and the Michel agent defer to. Covers bringing the full stack (PostgreSQL, Redis, NestJS API, React/Vite frontend on :4200, MCP server, nginx) up in the background, the init services (dependency install + TypeORM migrations) you must wait on, the critical host-port trap that the API on container port 3000 is NOT exposed to the host and must be reached via the frontend Vite proxy at localhost:4200/api/v0, confirming the API and frontend are actually serving before you depend on them, the persistent-volume gotcha that leaves stale Postgres schema and node_modules behind between runs, building the CLI, and tearing everything down so no container is left blocking the run. Use this whenever you need Packmind running locally — to verify a change, record a UI or CLI demo, hit the API, seed data, or reproduce a bug — and whenever you are about to start or stop `docker co

303 Updated today
PackmindHub