neoocean/helix-p4d repository overview

⁠helix-p4d (multi-arch, Apple Silicon native)

Perforce Helix Core (p4d) container image with native arm64 support for Apple Silicon hosts, plus continued amd64 compatibility for x86_64 Linux/Windows hosts.

⁠Supported architectures

For Apple Silicon hosts, pull 2026.1 — Docker auto-selects the linux/arm64 manifest from the multi-arch list. The image carries all the hardened2-baseline patches (existing-server init detection, APT-compatible perforce UID/GID on arm64) plus the new Perforce 2026.1 server build.

⁠Quick start

services:
  p4d:
    image: neoocean/helix-p4d:2026.1
    container_name: p4d
    environment:
      - NAME=perforce1
      - P4PORT=ssl::1666
      - P4ROOT=/p4/root
      - P4USER=super
      - P4PASSWD=<your password>
      - P4SSLDIR=/ssl
    ports:
      - "1666:1666"
    volumes:
      - /path/to/p4/data:/p4
      - /path/to/p4/data/ssl:/ssl

⁠What's in the :2026.1 tag

Built on the same hardened2-baseline patches as the prior recommended tag, refreshed to Perforce Helix Core 2026.1:

1. Helix Core 2026.1 server (P4D/LINUX26{X86_64,AARCH64}/ 2026.1/2951233) — current Perforce release line.

2. Idempotent init (carried forward from hardened2) — Container init detects existing $P4ROOT/root/db.config and skips setup.sh / configure-helix-p4d.sh. Without this, every container recreate would (a) overwrite the operator- tuned perforce1.conf with fresh-deploy templates (potentially pointing P4ROOT at a wrong nesting level) and (b) run chown -R perforce:perforce /p4/root over the entire archive tree (potentially millions of files, hours-long on USB-attached APFS).

3. APT-compatible perforce user on arm64 (carried forward from hardened2) — UID 105 / GID 106 / HOME /opt/perforce, matching the IDs that Perforce's APT package assigns on amd64. amd64 ↔ arm64 swap on the same /p4/data bind mount stays transparent.

4. No tag suffix change — The tag is plain 2026.1 (no -multiarch-hardened suffix) because the hardening is now baseline. Operators who need a non-hardened variant for a fresh-install workflow should track upstream Perforce images directly.

⁠Upgrading from 2025.x: read this first

The 2026.1 server requires a database schema upgrade (p4d -xu, level 58 → 60) and applies Perforce's "secure by default" configurable changes on first start:

• security raised to 4 (mandatory strong passwords, ticket-only auth, unauthenticated remote access disabled)
• dm.info.hide=1, dm.user.hideinvalid=1, dm.user.noautocreate=2, dm.user.setinitialpasswd=0, server.rolechecks=1

The schema upgrade is irreversible — 2025.2 binaries cannot read level-60 db.* tables. Pre-cutover steps:

1. Rotate any weak passwords (especially the super user) to meet the security level 4 strength requirements.
2. Take a pre-cutover snapshot of the entire $P4ROOT/root tree (APFS clone or rsync). This is your rollback anchor.
3. Run p4d -xu against the cloned data dir as a smoke test before applying to production (see scripts/rotate-p4- passwords.py in the upstream project for the operator- side helpers).
4. Verify your serverid and p4 server spec are populated (required for server.rolechecks=1).

See Perforce's official "secure-by-default" documentation for the full impact list.

⁠Sources

• amd64 binaries: Perforce APT repo (package.perforce.com/apt/ubuntu focal release channel), pinned at helix-p4d=2026.1-2951233~focal.
• arm64 binaries: Perforce FTP (ftp.perforce.com/perforce/r26.1/bin.linux26aarch64/), SHA256-verified during image build.
• Wrapper scripts (configure-p4d.sh, p4d-maintenance.sh, p4dctl.conf, p4dctl.conf.d/p4d.template): byte-identical extracts from the amd64 APT package — so behavior matches across architectures.
• Base image: ubuntu:focal-20250404
• Perforce server build: 2026.1/2951233

⁠Migration between tags

⁠2025.x → 2026.1 (current recommended)

NOT a plain image-tag swap — the 2026.1 server requires a database schema upgrade that is irreversible (see the "Upgrading from 2025.x: read this first" section above for the full list of secure-by-default configurable changes that take effect on first start).

Outline (use the upstream project's scripts/rotate-p4- passwords.py + the SCENARIO doc for the full operator-side procedure):

# 1. Stop p4d cleanly
docker compose stop p4d

# 2. Take a pre-cutover snapshot — this is your ONLY rollback
#    path once -xu runs.  Use APFS clone if available:
sudo cp -c -R /path/to/p4/data /backup/path/p4d-cutover-<TS>

# 3. Apply the schema upgrade in a one-shot container:
docker run --rm -v /path/to/p4/data:/p4 \
    neoocean/helix-p4d:2026.1 \
    p4d -r /p4/root/root -xu

# 4. Verify the upgrade landed cleanly (must report 0 errors):
docker run --rm -v /path/to/p4/data:/p4 \
    neoocean/helix-p4d:2026.1 \
    p4d -r /p4/root/root -xv

# 5. Flip the image tag in compose and bring up:
#    image: -> neoocean/helix-p4d:2026.1
docker compose up -d

# 6. Post-swap login + version check:
p4 -p ssl:<host>:1666 login -a
p4 -p ssl:<host>:1666 info     # expect server version 2026.1/2951233

Rollback path = restore the snapshot from step 2 + revert the image tag. Image tag flip alone is insufficient — 2025.x binaries cannot read the upgraded level-60 db.* tables.

⁠2025.2 (amd64-only) → 2025.2-multiarch-hardened2

Live image-tag swap is supported with seconds-level downtime:

# 1. Stop p4d cleanly
docker stop p4d

# 2. (Edit compose) image: -> neoocean/helix-p4d:2025.2-multiarch-hardened2
#    Remove any `platform: linux/amd64` line.

# 3. Recreate
docker compose up -d

The hardened2 init detects the existing database ($P4ROOT/root/ db.config) and skips first-time setup. Total downtime: ~2 seconds measured on Apple Silicon with the database on an external APFS volume.

For a complete validation procedure (isolated-env smoke test, cutover with 24h monitoring window, APFS clone-based rollback plan, operator decision matrix), refer to the SCENARIO docs in the source repository.

⁠Why arm64-native matters

On Apple Silicon hosts, the amd64-only 2025.2 tag runs through Rosetta 2 dynamic binary translation. Measured impact on a production workload (8TB depot, ~4GB metadata):

Rosetta also adds startup overhead per process spawn — p4d fork-on-connect and journal rotation costs are noticeably reduced.

⁠Hardening philosophy

The -hardened tag family adds operational safety patches on top of upstream Perforce behavior without changing the server itself. The Perforce binaries (p4, p4d, p4dctl) are the official Perforce builds — only the container init scripts and the user-account setup differ from upstream.

Specifically, this is not a custom p4d build — on the current :2026.1 tag, p4d -V identifies as standard P4D/LINUX26{X86_64,AARCH64}/2026.1/2951233. Earlier tags report their respective Perforce build numbers (see Sources section above).

⁠Operational notes

• The image runs p4d as the perforce user (UID 105) for least-privilege operation. Container init runs as root only to set up symlinks and call p4dctl start.
• The image enables Unicode mode by default and case-insensitive comparison (-C0); override via P4CASE env if needed.
• Health monitoring: pair this image with a monitor that polls p4 info -s (or open a TCP socket on the configured P4PORT) — the container does not bundle a stack-aware healthcheck beyond bash/dev-tcp.

⁠Compatibility matrix

Sites that cannot accept the 2026.1 schema upgrade yet (see "Upgrading from 2025.x" above) should stay on 2025.2-multiarch-hardened2 until they can plan the cutover.

⁠License

Based on Perforce Helix Core, redistributed per Perforce's end-user license terms. The container image and patches are released under the same license as the upstream helix-p4d maintenance scripts (extracted from Perforce's APT package).

⁠Source

Container build files (Dockerfile.multiarch, init scripts, p4dctl templates) are maintained alongside this image. See the upstream helix-docker project for prior amd64-only build history.