I have tested the template in my instance, so the maintainers don't spend time trying to figure out what's wrong.
I have added tests that demonstrate that my correction works or that my new feature works.
Screenshots or Videos
Greptile Summary
This PR updates the Glitchtip template from v4.0 to 6.1.0, replacing Redis with Valkey, upgrading PostgreSQL from 16 to 18, switching from ports to expose (correct per conventions), and updating worker/migrate startup commands to match the new release's script layout.
Key changes:
glitchtip/glitchtip:v4.0 → glitchtip/glitchtip:6.1.0 across all three services
redis replaced with valkey/valkey:9; VALKEY_URL env var added
GLITCHTIP_DOMAIN now properly constructed with https:// prefix and configurable DEFAULT_FROM_EMAIL via ${email} helper
Worker command updated to ./bin/run-worker.sh; migrate command updated to ./bin/run-migrate.sh
version: "3.8" correctly added to the compose file
ports correctly replaced with expose
Issues found:
The PostgreSQL volume mount was changed from pg-data:/var/lib/postgresql/data to pg-data:/var/lib/postgresql. While this works for fresh deployments, it would cause any existing deployment being upgraded to lose access to its data, since PostgreSQL's PGDATA still resolves to /var/lib/postgresql/data (a subdirectory of the new mount) rather than the root of the previously populated volume.
meta.json lists the version as v6.1.0 while the Docker image tag is 6.1.0 — these should match exactly per the project's AGENTS.md guide.
Confidence Score: 3/5
Safe for new deployments, but the postgres volume path change is a data-loss risk for users upgrading from the previous template version.
The overall update is well-structured and the v6.1.0 changes (Valkey, new script paths, https domain, expose vs ports) are all correct. However, the postgres volume mount path regression (/var/lib/postgresql vs /var/lib/postgresql/data) could silently wipe existing data for upgrading users, which is a meaningful reliability concern. The meta.json version prefix inconsistency is minor but straightforward to fix.
blueprints/glitchtip/docker-compose.yml — specifically the postgres volume mount path on line 23.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/Dokploy/templates/pull/751
**Author:** [@andrew-tinekov](https://github.com/andrew-tinekov)
**Created:** 3/23/2026
**Status:** ✅ Merged
**Merged:** 7/7/2026
**Merged by:** [@Siumauricio](https://github.com/Siumauricio)
**Base:** `canary` ← **Head:** `feat/update-glitchtip-to-v6`
---
### 📝 Commits (2)
- [`079be40`](https://github.com/Dokploy/templates/commit/079be40968cf969ea2e3216ba758aa7cd4c32e2a) feat(glitchtip): update to version 6.1.0
- [`4049760`](https://github.com/Dokploy/templates/commit/4049760579c4ebad1ef4f7b21e3cf5a22cef6596) fix(glitchtip): fix code violations
### 📊 Changes
**3 files changed** (+19 additions, -21 deletions)
<details>
<summary>View changed files</summary>
📝 `blueprints/glitchtip/docker-compose.yml` (+15 -18)
📝 `blueprints/glitchtip/template.toml` (+3 -2)
📝 `meta.json` (+1 -1)
</details>
### 📄 Description
## What is this PR about?
Update Glitchtip to version 6.1.0
## Checklist
Before submitting this PR, please make sure that:
- [x] I have read the suggestions in the README.md file https://github.com/Dokploy/templates?tab=readme-ov-file#general-requirements-when-creating-a-template
- [x] I have tested the template in my instance, so the maintainers don't spend time trying to figure out what's wrong.
- [x] I have added tests that demonstrate that my correction works or that my new feature works.
## Screenshots or Videos
<img width="1512" height="982" alt="glitchtip1" src="https://github.com/user-attachments/assets/b7a0c8da-6c87-4c8b-8f2b-98a859fc6642" />
<img width="1512" height="982" alt="glitchtip2" src="https://github.com/user-attachments/assets/127917d4-b32d-408d-b83f-0faf3c7a02f4" />
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
This PR updates the Glitchtip template from v4.0 to 6.1.0, replacing Redis with Valkey, upgrading PostgreSQL from 16 to 18, switching from `ports` to `expose` (correct per conventions), and updating worker/migrate startup commands to match the new release's script layout.
**Key changes:**
- `glitchtip/glitchtip:v4.0` → `glitchtip/glitchtip:6.1.0` across all three services
- `redis` replaced with `valkey/valkey:9`; `VALKEY_URL` env var added
- `GLITCHTIP_DOMAIN` now properly constructed with `https://` prefix and configurable `DEFAULT_FROM_EMAIL` via `${email}` helper
- Worker command updated to `./bin/run-worker.sh`; migrate command updated to `./bin/run-migrate.sh`
- `version: "3.8"` correctly added to the compose file
- `ports` correctly replaced with `expose`
**Issues found:**
- The PostgreSQL volume mount was changed from `pg-data:/var/lib/postgresql/data` to `pg-data:/var/lib/postgresql`. While this works for fresh deployments, it would cause any existing deployment being upgraded to lose access to its data, since PostgreSQL's `PGDATA` still resolves to `/var/lib/postgresql/data` (a subdirectory of the new mount) rather than the root of the previously populated volume.
- `meta.json` lists the version as `v6.1.0` while the Docker image tag is `6.1.0` — these should match exactly per the project's AGENTS.md guide.
<h3>Confidence Score: 3/5</h3>
- Safe for new deployments, but the postgres volume path change is a data-loss risk for users upgrading from the previous template version.
- The overall update is well-structured and the v6.1.0 changes (Valkey, new script paths, https domain, expose vs ports) are all correct. However, the postgres volume mount path regression (`/var/lib/postgresql` vs `/var/lib/postgresql/data`) could silently wipe existing data for upgrading users, which is a meaningful reliability concern. The meta.json version prefix inconsistency is minor but straightforward to fix.
- blueprints/glitchtip/docker-compose.yml — specifically the postgres volume mount path on line 23.
<sub>Reviews (1): Last reviewed commit: ["feat(glitchtip): update to version 6.1.0"](https://github.com/dokploy/templates/commit/079be40968cf969ea2e3216ba758aa7cd4c32e2a) | [Re-trigger Greptile](https://app.greptile.com/api/retrigger?id=26092159)</sub>
> Greptile also left **2 inline comments** on this PR.
<sub>(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!</sub>
**Context used:**
- Context used - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=09330bde-2058-497c-9c64-ceae637fb5b2))
<!-- /greptile_comment -->
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/Dokploy/templates/pull/751
Author: @andrew-tinekov
Created: 3/23/2026
Status: ✅ Merged
Merged: 7/7/2026
Merged by: @Siumauricio
Base:
canary← Head:feat/update-glitchtip-to-v6📝 Commits (2)
079be40feat(glitchtip): update to version 6.1.04049760fix(glitchtip): fix code violations📊 Changes
3 files changed (+19 additions, -21 deletions)
View changed files
📝
blueprints/glitchtip/docker-compose.yml(+15 -18)📝
blueprints/glitchtip/template.toml(+3 -2)📝
meta.json(+1 -1)📄 Description
What is this PR about?
Update Glitchtip to version 6.1.0
Checklist
Before submitting this PR, please make sure that:
Screenshots or Videos
Greptile Summary
This PR updates the Glitchtip template from v4.0 to 6.1.0, replacing Redis with Valkey, upgrading PostgreSQL from 16 to 18, switching from
portstoexpose(correct per conventions), and updating worker/migrate startup commands to match the new release's script layout.Key changes:
glitchtip/glitchtip:v4.0→glitchtip/glitchtip:6.1.0across all three servicesredisreplaced withvalkey/valkey:9;VALKEY_URLenv var addedGLITCHTIP_DOMAINnow properly constructed withhttps://prefix and configurableDEFAULT_FROM_EMAILvia${email}helper./bin/run-worker.sh; migrate command updated to./bin/run-migrate.shversion: "3.8"correctly added to the compose fileportscorrectly replaced withexposeIssues found:
pg-data:/var/lib/postgresql/datatopg-data:/var/lib/postgresql. While this works for fresh deployments, it would cause any existing deployment being upgraded to lose access to its data, since PostgreSQL'sPGDATAstill resolves to/var/lib/postgresql/data(a subdirectory of the new mount) rather than the root of the previously populated volume.meta.jsonlists the version asv6.1.0while the Docker image tag is6.1.0— these should match exactly per the project's AGENTS.md guide.Confidence Score: 3/5
/var/lib/postgresqlvs/var/lib/postgresql/data) could silently wipe existing data for upgrading users, which is a meaningful reliability concern. The meta.json version prefix inconsistency is minor but straightforward to fix.Reviews (1): Last reviewed commit: "feat(glitchtip): update to version 6.1.0" | Re-trigger Greptile
(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!
Context used:
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.