mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 13:36:48 +00:00
Maurice
d88dc17e8e
docker.yml built and published whatever `main` pointed to when the build and merge jobs started, not the commit it had just bumped and tagged, so anything that landed in between shipped under a version that did not contain it. build, merge and release-helm now check out the bump commit, the way docker-dev.yml already pinned its prerelease builds. The push of that commit fast-forwards main from the commit the run started on, so a race fails the release instead of skipping over it. Nothing tied a release to a green CI run. Both release workflows now refuse a commit unless every ci-ok check run on it has finished green, and docker.yml refuses to run on anything but main. bump=auto fell back to a patch whenever no prerelease was in flight, which would have published the ORM release, the largest change the project has made, as 4.3.4. auto now only finalizes a prerelease above the last stable tag and otherwise stops, asking for patch, minor or major. The inputs are unchanged. A patch that adds migrations gets a warning, not a refusal, since patch releases have carried them before. Stable releases also publish :MAJOR.MINOR, so an install can take the fixes of one minor line without being moved onto the next on day one. The tag tables in the wiki list it and the prerelease tag, and the root CLAUDE.md describes the release and prerelease flow.
107 lines
4.1 KiB
Markdown
107 lines
4.1 KiB
Markdown
# Install: Docker
|
|
|
|
Single-container Docker run — suitable for testing or simple personal installs.
|
|
|
|
## Run Command
|
|
|
|
```bash
|
|
docker run -d \
|
|
--name trek \
|
|
-p 3000:3000 \
|
|
-v ./data:/app/data \
|
|
-v ./uploads:/app/uploads \
|
|
-e ENCRYPTION_KEY=<your-32-byte-hex-key> \
|
|
--restart unless-stopped \
|
|
mauriceboe/trek:latest
|
|
```
|
|
|
|
`ENCRYPTION_KEY` is strongly recommended but not strictly required. If omitted, a key is auto-generated on first start and persisted to `data/.encryption_key`. Setting it explicitly means you can recreate the container from scratch (e.g. on a new host) without losing access to stored encrypted data (API keys, SMTP credentials, OIDC secrets, MFA secrets).
|
|
|
|
Generate an encryption key with:
|
|
|
|
```bash
|
|
openssl rand -hex 32
|
|
```
|
|
|
|
### Common optional variables
|
|
|
|
Pass additional `-e` flags for timezone and CORS/email link support:
|
|
|
|
```bash
|
|
-e TZ=Europe/Berlin \
|
|
-e ALLOWED_ORIGINS=https://trek.example.com \
|
|
```
|
|
|
|
See [Environment-Variables](Environment-Variables) for the full list.
|
|
|
|
## Image Tags
|
|
|
|
| Tag | Example | Behavior |
|
|
|---|--------------------------|---|
|
|
| `latest` | `mauriceboe/trek:latest` | Always the newest release across all major versions |
|
|
| Major version | `mauriceboe/trek:4` | Latest release pinned to that major version |
|
|
| Minor version | `mauriceboe/trek:4.3` | Latest patch of that minor version; never moves to the next minor (published for releases after 4.3.3) |
|
|
| Full version | `mauriceboe/trek:4.0.0` | Exact release; never changes |
|
|
|
|
Replace `mauriceboe/trek:latest` in the run command with your chosen tag to pin to a major version, a minor version or an exact release. Test builds of the next version are tagged `latest-pre`; see [Updating](Updating#image-tags).
|
|
|
|
Every image carries the standard `org.opencontainers.image.*` labels (title, version, source, documentation, licence), so an update tool such as Renovate links an image update to its release notes. `docker inspect mauriceboe/trek:latest --format '{{json .Config.Labels}}'` shows them.
|
|
|
|
## Volume Reference
|
|
|
|
| Volume | Container path | What lives there |
|
|
|---|---|---|
|
|
| `./data` | `/app/data` | `travel.db` (SQLite database), `logs/trek.log`, `.jwt_secret`, `.encryption_key` |
|
|
| `./uploads` | `/app/uploads` | Uploaded files (photos, documents, covers, avatars) |
|
|
|
|
Both volumes must survive container replacement — they are your persistent state. Never remove them before pulling a new image.
|
|
|
|
### Named Volumes
|
|
|
|
The run command above uses bind mounts (`./data`, `./uploads`). You can use Docker named volumes instead, which are fully managed by Docker and not tied to a host path:
|
|
|
|
```bash
|
|
docker run -d \
|
|
--name trek \
|
|
-p 3000:3000 \
|
|
-v trek_data:/app/data \
|
|
-v trek_uploads:/app/uploads \
|
|
-e ENCRYPTION_KEY=<your-32-byte-hex-key> \
|
|
--restart unless-stopped \
|
|
mauriceboe/trek:latest
|
|
```
|
|
|
|
Docker creates `trek_data` and `trek_uploads` automatically on first run. Named volumes are easier to manage with `docker volume` commands and work better in some NAS or container-management environments.
|
|
|
|
## Health Check
|
|
|
|
The container exposes a health endpoint at:
|
|
|
|
```
|
|
http://localhost:3000/api/health
|
|
```
|
|
|
|
Docker polls it automatically (interval: 30 s, timeout: 5 s, retries: 3, start period: 15 s). You can check it manually:
|
|
|
|
```bash
|
|
curl -s http://localhost:3000/api/health
|
|
```
|
|
|
|
## Verify the Container Is Running
|
|
|
|
```bash
|
|
docker ps --filter name=trek
|
|
docker logs trek
|
|
```
|
|
|
|
## Limitations of `docker run`
|
|
|
|
A bare `docker run` command has no built-in secret management and is harder to reproduce after a system reboot. For production, see [Install-Docker-Compose](Install-Docker-Compose), which adds security hardening (`read_only`, `cap_drop`, `cap_add`, `no-new-privileges`, `tmpfs`) and makes it easy to manage environment variables through a `.env` file.
|
|
|
|
## Next Steps
|
|
|
|
- [Reverse-Proxy](Reverse-Proxy) — HTTPS is required for PWA install and the `trek_session` cookie `secure` flag
|
|
- [Install-Docker-Compose](Install-Docker-Compose) — recommended for production
|
|
- [Environment-Variables](Environment-Variables) — full list of configurable variables
|
|
- [Updating](Updating) — how to pull a new image without losing data
|