chore: update Docker images for security vulnerability fixes

.github/agents/commiter.agent.md

@@ -37,6 +37,7 @@ request to run `git commit`.
 - Do not rewrite or revert unrelated user changes.
 - Do not create empty, vague, or non-conventional commit messages.
 - Do not commit secrets, backup junk, or accidental files.
+- **Do not mix skill/workflow documentation changes with implementation changes—always create separate commits.**
 
 ## Output Format
 

.github/skills/commit/skill.md

@@ -10,6 +10,17 @@ metadata:
 
 Always run the linters locally before committing to avoid CI failures.
 
+## Commit Scope Separation
+
+**Critical rule**: Never mix skill/workflow documentation changes (`.github/skills/`, `.github/agents/`, AGENTS.md) with implementation changes in a single commit.
+
+When a change affects both documentation/skills and implementation:
+
+1. **First commit**: Update the skill/documentation files only (type: `docs`)
+2. **Second commit**: Implement the feature or fix (type: `feat`, `fix`, etc.)
+
+This keeps changes logically separated and makes the commit history easier to review.
+
 ## Prerequisites
 
 Install the linter binary once:
@@ -53,3 +64,5 @@ Follow [Conventional Commits](https://www.conventionalcommits.org/):
 ```
 
 Types: `feat`, `fix`, `docs`, `chore`, `refactor`.
+
+When updating documentation for skills or workflows, use `docs` type. Implementation changes use their appropriate type (`feat`, `fix`, etc.) in a separate commit.

.github/skills/create-issue-branch/skill.md

@@ -39,16 +39,15 @@ canonical title. Derive the normalized branch name from it.
 
 **Always show the branch name to the user and wait for explicit approval before creating it.**
 
-### Step 3 — Create and switch to the branch
+### Step 3 — Create and switch to the branch locally
+
+Create the branch locally only (do not push to remote at this stage):
 
 ```bash
 git checkout -b <branch-name>
 ```
 
-### Step 4 — Push the branch to origin (optional, do when first committing)
-
-```bash
-git push -u origin <branch-name>
-```
+### Step 4 — Push to remote when creating the pull request
 
-The branch is typically pushed with the first commit rather than immediately after creation.
+The branch is pushed to origin only when creating the pull request. Do not push the branch
+to remote immediately after creation—wait until the PR workflow.

.github/skills/open-pull-request/skill.md

@@ -0,0 +1,88 @@
+---
+name: open-pull-request
+description: Create and open a pull request in the torrust-tracker-demo repository. Use when asked to open a PR, create a pull request, submit a PR, or push changes and create a PR. Triggers on "open PR", "create PR", "submit PR", "push and open PR", "open pull request".
+metadata:
+  author: torrust
+  version: "1.0"
+---
+
+# Opening a Pull Request
+
+This skill guides you through pushing your branch and creating a pull request on GitHub.
+
+## Prerequisites
+
+- Local commits already created and ready to push
+- Branch created locally (see `create-issue-branch` skill for branch creation)
+- GitHub CLI installed and authenticated
+
+## Workflow
+
+### Step 1 — Push the branch to remote
+
+Push the local branch to the remote repository:
+
+```bash
+git push -u origin <branch-name>
+```
+
+The `-u` flag sets the upstream tracking branch. Git will output a link to create a PR.
+
+### Step 2 — Prepare the PR title and description
+
+**Title**: Follow Conventional Commits format with the issue type and scope
+
+**Examples**:
+
+- `feat(docker): update Docker images for security vulnerability fixes`
+- `fix(tracker): resolve UDP socket binding issue`
+- `docs: update deployment guide`
+
+**Description**: Should include:
+
+- Brief summary of the change
+- Context or motivation (reference related issues or PRs)
+- Changes made (list key files or components modified)
+- Verification checklist (if applicable)
+- Link to related issue using `Fixes #<issue-number>` or `Refs: #<issue-number>`
+
+### Step 3 — Create the pull request
+
+Use GitHub CLI to create the PR with title and description:
+
+```bash
+gh pr create \
+  --title "feat(scope): description" \
+  --body "Description with Fixes #<issue-number>" \
+  --base main \
+  --head <branch-name>
+```
+
+The `--body` parameter supports markdown. Use `Fixes #<issue-number>` to auto-link and auto-close the issue when merged.
+
+### Step 4 — Verify the PR was created
+
+GitHub CLI will output the PR URL:
+
+```text
+https://github.com/torrust/torrust-tracker-demo/pull/<number>
+```
+
+Open it to:
+
+- Review the commits
+- Verify the issue is linked
+- Check that CI/CD checks pass
+- Monitor for review comments
+
+## Tips
+
+- **Link to issues**: Always include `Fixes #<issue-number>` in the PR body to auto-link
+- **Review before pushing**: Run `git log --oneline -n <count>` to verify commits are correct
+- **Check branch status**: Verify you're on the correct branch with `git status` before pushing
+- **Wait for checks**: GitHub Actions will run linters and tests. Wait for them to pass before merging.
+
+## Related Skills
+
+- `create-issue-branch` — Creating a new branch for an issue
+- `commit` — Committing changes to the repository

project-words.txt

@@ -54,6 +54,7 @@ newtrackon
 noall
 noprefixroute
 noqueue
+oneline
 oneshot
 pkts
 post-mortems

server/opt/torrust/docker-compose.yml

@@ -51,7 +51,7 @@ services:
   # Placed first as it's the entry point for HTTPS traffic
   caddy:
     <<: *defaults
-    image: caddy:2.10
+    image: caddy:2.10.2
     container_name: caddy
     # NOTE: No UFW firewall rule needed for these ports!
     # Docker-published ports bypass iptables/UFW rules entirely.
@@ -110,7 +110,7 @@ services:
 
   prometheus:
     <<: *defaults
-    image: prom/prometheus:v3.5.0
+    image: prom/prometheus:v3.5.1
     container_name: prometheus
     networks:
       - metrics_network
@@ -133,7 +133,7 @@ services:
 
   grafana:
     <<: *defaults
-    image: grafana/grafana:12.3.1
+    image: grafana/grafana:12.4.2
     container_name: grafana
     networks:
       - visualization_network