The whole depot,
in a browser tab.

Everything you open P4V for

Each card is backed by the real p4 command underneath — the app is a thin, honest wrapper, so results match your CLI exactly.

My Changes: edit and submit from the browser

Each user gets a server-side workspace (p4web-<user>) with sparse sync — files appear only while you work on them.

Running in under a minute

One script creates the venv, installs three pinned dependencies, and serves.

$ git clone https://github.com/neoocean/p4-web.git && cd p4-web
$ export P4WEB_P4PORT=ssl:perforce.example.com:1666  # or inherit P4PORT
$ ./run.sh
# equivalent to:
$ python3 -m venv .venv
$ .venv/bin/pip install -r requirements.txt
$ .venv/bin/uvicorn app.main:app --host 127.0.0.1 --port 8080
# then open http://127.0.0.1:8080 and log in with a Perforce account

requires: Python 3.10+ · the p4 CLI on PATH · network access to your Perforce server

no git handy? download the source as a .zip

Security, the boring way

Reviewed end-to-end across two standing passes — code review, security audit, and a live red team against a running instance. The core boundaries:

• Your ticket, your permissions. Every API call runs p4 with the session’s own user and ticket — Perforce protections apply exactly as in P4V.
• No ticket leakage. P4TICKETS points at /dev/null for every subprocess; the server’s own tickets file can never authenticate a web user.
• Passwords are never stored. Credentials are exchanged for a p4 login ticket; you can paste a ticket instead, Swarm-style.
• Command allowlist. The p4 wrapper only permits known commands; write operations are confined to your own p4-web changelists and audited.
• Hardened endpoints. Streamed raw downloads and bounded upload spooling (no 100 MB buffers), per-session rate limits, secure cookies, login throttling.
• Boring deploys. The container runs as a non-root user, the bundled p4 client is verified against a published SHA-256, and every Python dependency is pinned to an exact version.

Deploy anywhere a shell runs

Sessions persist in SQLite (data/sessions.db), so restarts don’t log anyone out, and each one lasts exactly as long as its Perforce ticket. For ssl: servers the container entrypoint trusts the fingerprint for you — pin it with P4WEB_P4FINGERPRINT, or fall back to P4WEB_AUTO_TRUST=1 on a trusted network; outside Docker, run p4 trust once yourself.

Small enough to read

app/
  main.py      FastAPI routes: auth, browse, file, diff, annotate,
               changes, comments, workspace write ops
  p4.py        p4 CLI wrapper: -G marshal parsing, path escaping,
               command allowlist, error → HTTP mapping
  sessions.py  cookie sid → {user, ticket}, plus favorites,
               comment threads, review states and mentions —
               all SQLite-backed
  index.py     per-user changelist search index (respects protections)
  workspace.py per-user p4web-<user> workspaces backing the write ops
static/
  index.html   login screen + app shell
  app.js       hash-routed SPA — no framework, no build
  style.css    light + dark, responsive below 768px
  vendor/      highlight.js, marked, DOMPurify (offline)

The entire stack is one Python process and a directory of static files. If something breaks, the code that broke is short enough to read over coffee — and every feature maps to a p4 command you already know.