Do you keep family videos in remote locations? Want the important ones, such as footage from your third wedding, stored locally so you can fall asleep to it every night without worrying that your WRT54G router might drop the signal and reboot for the ninth time today? Tired of manually repointing symlinks whenever those files move? SRTL Manager inventories local and remote storage, copies selected files in either direction, verifies transfers before switching links, and helps prevent a bad copy from freezing at the exact moment someone says, "I do." If your files have multiple homes but managing their symlinks should not be a full-time job, this app is for you.
SRTL Manager is a local-first web app for inventorying and maintaining a symlink-backed file library, with storage policies, audits, guarded copies, and durable job history in one focused interface.
- Guided first-run account, path, section, policy, and initial-scan setup.
- Symlink, local-root, remote-root, and orphan inventory with targeted title rescans.
- Per-location storage policies using editable friendly names, plus an Unassigned queue for newly discovered titles.
- Fast and deep audits across local and remote targets.
- Bidirectional copies with live progress, conflict handling, configurable verification, and source/title risk checks.
- Safe job termination, complete event timelines, restart recovery, and durable per-file copy journals.
- Required path-change review before changed mounts can affect managed links.
- Editable storage-location names while deployment paths remain environment-managed.
- Postgres-backed API and worker services in a hardened container stack.
- Dark, light, and system themes with responsive administration views.
SRTL Manager is early software. Keep backups and review copy and audit results before relying on unattended workflows.
These screenshots come from a disposable fictional library built solely for documentation. They contain no private paths or real library data.
Dashboard
Storage policies
Live copy progress
Docker Engine, Docker Compose v2, and curl are required.
curl -fsSL -o docker-compose.yml https://raw.githubusercontent.com/ramphex/SRTL-Manager/main/docker-compose.yml
curl -fsSL -o .env.example https://raw.githubusercontent.com/ramphex/SRTL-Manager/main/.env.exampleCopy .env.example to .env, then edit these deployment values before starting:
SYMLINK_DIR: the existing absolute path containing the managed symlinks.SRTL_LOCATION_1_PATHandSRTL_LOCATION_2_PATH: existing absolute storage paths. Their friendly names are set during onboarding and can be changed later in Settings > Library.SRTL_POSTGRES_PASSWORD: a database password you must set before Compose will start.SRTL_UIDandSRTL_GID: the host account that can read the managed roots and write to destinations used by copy jobs.SRTL_BIND_HOST,SRTL_WEB_PORT, and the security settings: review these if the defaults do not match your network or reverse proxy.
The administrator username and password are created in the browser during first-run setup and do not belong in .env.
Run cp .env.example .env, protect it with chmod 600 .env, validate it with docker compose config --quiet, then pull and start the stack:
docker compose pull
docker compose up -dOpen http://<server-ip>:5179 unless a different port was selected. The browser then completes account creation, section setup, initial policy strategy, and the first scan.
The default configuration follows the current stable latest image. Pin SRTL_IMAGE to a numbered image tag when repeatable deployments are more important than automatically following stable updates.
Beta builds: When a beta image is available, set
SRTL_IMAGE=ghcr.io/ramphex/srtl-manager:betain.env. Beta builds contain newer work that has not yet been promoted to a stable release.
.env is the single source of truth for deployment-owned paths, credentials, host binding, and ports. Persistent database files stay in ./data beside docker-compose.yml; that path does not need configuration. Numbered storage-location variables keep deployment identity separate from friendly names managed in Settings > Library. Friendly names, section names, display order, policies, and user preferences live in Postgres.
The API receives read-only root mounts. The worker alone receives writable roots for copy and path-migration jobs. Postgres is reachable only inside the Compose network.
The API checks the public GitHub Releases endpoint for stable and beta version information at startup and when version status is refreshed. This request does not include credentials, paths, or inventory data.
When a configured root changes, restart the stack. The UI enters maintenance mode until it validates and applies a path migration or the prior value is restored. This rebases managed paths; it does not move stored content.
Create a database backup before upgrades or path changes:
(umask 077 && docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' > srtl-manager-backup.sql)Restore into an empty database while app services are stopped:
docker compose stop api worker
docker compose exec -T postgres sh -c 'dropdb -U "$POSTGRES_USER" --if-exists "$POSTGRES_DB" && createdb -U "$POSTGRES_USER" "$POSTGRES_DB"'
docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" "$POSTGRES_DB"' < srtl-manager-backup.sql
docker compose start api workerKeep .env, .env.backup.*, and database dump files private. Dumps contain account hashes, paths, inventory records, and job history.
Requires Node.js 24 and Postgres 17. The simplest local setup uses Docker and an available port 5432:
docker run --name srtl-manager-dev-postgres --rm -d -p 5432:5432 -e POSTGRES_DB=srtl_manager -e POSTGRES_USER=srtl -e POSTGRES_PASSWORD=srtl postgres:17-alpineThen install dependencies and start the API, web interface, and worker:
npm ci
npm run devDevelopment defaults are http://localhost:5178 for the UI and port 3009 for the API. Run the complete local verification set with:
npm run check
npm run build
npm run test:e2eStop the disposable database with docker stop srtl-manager-dev-postgres. To use an existing Postgres instance instead, provide the SRTL_POSTGRES_* settings or SRTL_DATABASE_URL in a local .env.
- Pull requests target
beta. maincontains stable releases;betais the integration branch for upcoming changes.- Ordinary branch pushes run verification but do not publish images or releases.
- Stable releases publish matching numbered and
latestcontainer tags. - Prereleases use the upcoming stable version plus an ordered suffix, such as
0.1.1-beta.1. - Small stable fixes increment the patch version; the next feature line increments the minor version.
See CONTRIBUTING.md, SECURITY.md, and CHANGELOG.md.
SRTL Manager is available under the MIT License. Contributions are accepted under the same license.
- External metadata and automation adapters.
- Optional remote source-availability preflight checks where providers expose reliable metadata.
- Event-driven targeted refresh hooks.
- Additional numbered storage locations and per-location assignment policies.
- Controlled multi-worker execution after single-worker recovery semantics are fully proven.


