You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 

11 KiB

CamMonitor

Overview

CamMonitor is a self-hosted security camera footage viewer. It provides the Go HTTP server, a /health endpoint, environment-based configuration, SQLite startup and migrations, bcrypt login, session cookies, admin user management, an in-memory footage index, and Docker Compose deployment.

Getting Started

Copy the sample environment file and adjust it for your footage directory:

cp .env.example .env

Start the app with Docker Compose:

docker compose up --build

Verify the server is running:

curl http://localhost:8080/health

The response should be:

{"status":"ok"}

Open http://localhost:8080/login and sign in with ADMIN_USER and ADMIN_PASS. On the first run, CamMonitor creates that bootstrap admin account only when the user table is empty. After login, admins can add or delete users at /admin/users.

Configuration

Variable Default Description
PORT 8080 Host port published by Docker Compose
LISTEN_ADDR :8080 TCP address used by the Go server
FOOTAGE_ROOT /footage Camera footage directory inside the container
DB_PATH /data/cammonitor.db SQLite database path
ADMIN_USER admin Bootstrap admin username created on first run when no users exist
ADMIN_PASS changeme Bootstrap admin password created on first run when no users exist
SESSION_TTL 24h Session cookie lifetime
SCAN_INTERVAL 5m Footage rescan interval

Authentication

All app routes except /health, /login, and POST /login require a valid session cookie. Unauthenticated requests are redirected to /login. Admin-only pages return 403 Forbidden for signed-in non-admin users.

The login form posts credentials to /login. Successful login sets an HTTP-only session cookie and redirects to /; invalid credentials return 401 Unauthorized. POST /logout deletes the server-side session, clears the cookie, and redirects back to /login.

Admin users can manage accounts at /admin/users. New users are created with bcrypt-hashed passwords, and deleting a user also removes their sessions through the SQLite foreign key cascade.

Browsing Footage

After login, / redirects to the newest indexed day's image browser at /day/YYYYMMDD/images. The day overview at /day/YYYYMMDD shows the available image and video counts with links to /day/YYYYMMDD/images and /day/YYYYMMDD/videos.

The image browser at /day/YYYYMMDD/images shows a horizontal thumbnail strip and a full-size viewer for the selected image. Use the on-screen previous and next buttons or the left and right arrow keys to move through images for the day; navigation wraps at the ends. The current image is deep-linkable with ?idx=N, where N is the zero-based image index.

Original JPEGs are served from /raw/image/<relative-path> after validating that the path stays inside FOOTAGE_ROOT. Thumbnails are served from /thumb/image/<relative-path> as cached 160x90 JPEGs generated in memory only.

The video browser at /day/YYYYMMDD/videos uses the same strip-and-viewer layout with an HTML5 player, wraparound arrow navigation, and ?idx=N deep links. Video thumbnails are served from /thumb/video/<relative-path>, and /stream/video/<relative-path> remuxes the source clip to fragmented MP4 on demand with ffmpeg without re-encoding.

On desktop widths, the app shows a dark sidebar with indexed days grouped by month. On smaller screens, the sidebar is replaced by a drawer trigger in the header and a fixed bottom tab bar for switching between Images and Videos.

Footage Layout

Footage is mounted read-only at /footage in the container. CamMonitor scans this tree on startup and then rescans it on the SCAN_INTERVAL schedule. Days are indexed from YYYYMMDD directories, with images and videos sorted chronologically inside each day.

The expected directory format is:

YYYYMMDD/
  images/
    AYYMMDDHHMMSSNN.jpg
  record/
    AYYMMDD_HHMMSS_HHMMSS.265

AI Workflow

This project includes the persistent planner/implementer/reviewer workflow with file-based coordination, plus the PO orchestration layer. Manual and auto are two runtime modes for the same scaffold: they use the same generated files, task board, and review gate. Fewer role sessions means less coordination overhead and lower token cost.

Modes

This scaffold supports two workflow profiles that share the same generated files, task board, plan, review log, and handoff log.

  • full keeps the planner, implementer, reviewer, and optional PO split.
  • lite keeps the planner but replaces separate implementer/reviewer sessions with one aide dev session.
Profile Sessions and launchers Who drives work Commit cadence PO support Recommended fit
full aide plan, aide implement, aide review, optional aide po Separate role sessions with explicit implement/review handoffs One final task commit after reviewer approval yes Larger, riskier, or more review-heavy changes
lite aide plan, aide dev Planner plus one dev session that implements and reviews, then halts for human approval at ready_for_review One real commit per task, including all_task no Smaller changes or lower-coordination work

How to switch

aide profile full
aide profile lite

Use aide profile full to return to the split workflow, or aide profile lite to switch to the dev-session flow.

full is the default for new scaffolds. When you switch to lite, aide implement, aide review, and aide po refuse and point you at aide dev. When you switch back to full, aide dev refuses and points you at aide implement and aide review.

Runtime modes

  • Manual mode: start the planner, implementer, and reviewer in separate terminals, then drive each session yourself with the documented text commands.
  • Auto mode: run aide po to start the PO session, which uses MCP tools to coordinate the post-planning implementer/reviewer workflow for you.

Concepts

Cycle — a unit of work on a feature branch. One cycle = one branch = one PR.

Roles and file ownership:

Role Reads Writes
PO .ai/TASKS.md, .ai/PLAN.md, .ai/REVIEW.md, .ai/prompts/po.md MCP session commands via aide po
Planner ROADMAP.md .ai/PLAN.md, .ai/TASKS.md
Implementer .ai/PLAN.md, .ai/REVIEW.md source code, .ai/TASKS.md
Reviewer .ai/PLAN.md, commits .ai/REVIEW.md, .ai/TASKS.md

Status flow:

in_planning → ready_for_implement → in_implementation → ready_for_review → in_review → ready_to_commit → done
                                          ↑                                     |
                                          └──── changes_requested ◄─────────────┘

Start a new development cycle

# Edit ROADMAP.md with your goals first, then:
aide cycle start feature/<scope>

Full profile quick start

aide plan          # terminal 1
aide implement     # terminal 2
aide review        # terminal 3

Launch each role once, then keep those sessions open for the rest of the cycle.

Role launchers read default agent/model settings from .ai/config.json. To override, pass the agent first, then any CLI flags. Example: aide review claude --model sonnet Claude starts interactively by default, and the Codex launcher uses interactive codex mode so the session stays open for role commands.

Lite profile quick start

aide profile lite
aide plan          # terminal 1
aide dev           # terminal 2

The dev session handles implementation and review, then halts for human approval at ready_for_review. In lite mode, aide implement, aide review, and aide po refuse and point you at aide dev.

Start the PO orchestrator (auto mode)

aide po

The PO session drives the post-planning task board flow through the aide MCP server. PO orchestration is available only in the full profile. By default, aide po launches Claude with --model haiku, and aide po codex launches Codex with -m gpt-5.4-mini. .ai/config.json can override those defaults, and an explicit CLI --model or -m flag takes precedence. If no tasks are in ready_for_implement or later, run the planner first. The normal MCP completion path is session_run followed by session_wait, then a re-read of .ai/TASKS.md; session_get_output is for debugging only. The MCP server appends structured debug logs to .ai/mcp-server.log, and the scaffold gitignore excludes that file.

Drive work inside the existing sessions

planner> start_plan
implementer> next_task T-001
reviewer> next_task T-001
implementer> commit_task T-001
dev> next_task T-001
dev> commit_task T-001
implementer> rework_task T-001
aide cycle end 0.7.0

Cross-platform CLI equivalents: aide cycle end [VERSION] closes the cycle outside the persistent role session, and aide pr [--dry-run] creates or updates the branch PR.

Planner commands:

Before start_plan, freeform conversation with the planner is the roadmap-refinement phase. Use it to sharpen scope, acceptance criteria, constraints, and trade-offs directly in ROADMAP.md. start_plan is the explicit handoff into formal planning.

Command Description
start_plan Read ROADMAP.md, write .ai/PLAN.md and .ai/TASKS.md
rework_plan [TASK_ID] Revisit the plan when scope or approach changes

Implementer commands:

Command Description
next_task [TASK_ID] Pick up the next ready_for_implement task
commit_task [TASK_ID] Turn a ready_to_commit task into one clean final commit, including task-specific .ai/ artifacts
rework_task [TASK_ID] Address changes_requested findings from .ai/REVIEW.md
aide cycle end [VERSION] Close the cycle after all tasks reach done, committing remaining .ai/ artifacts with a Release-As: footer
status_cycle [TASK_ID] Show task status and recommended next action

Reviewer commands:

Command Description
next_task [TASK_ID] Pick up the next ready_for_review task and run review plus verification
status_cycle [TASK_ID] Show task status and recommended next action

File map

File Purpose Tracked
.ai/PLAN.md Current plan yes
.ai/TASKS.md Task board with status yes
.ai/prompts/po.md PO orchestration prompt for auto mode yes
.ai/REVIEW.md Review findings yes (tracked cycle log)
.ai/HANDOFF.md Runtime handoff log yes (tracked cycle log)
.ai/config.json Per-role launch defaults yes
ROADMAP.md Cycle goals (edit before planning) yes
AGENTS.md Project-specific and workflow-managed agent rules yes
CLAUDE.md Agent instruction entry point (@AGENTS.md) yes
aide po Launch the PO orchestration session yes

Create a PR

aide pr

Full workflow details and session recovery rules are in AGENTS.md.