align the Firecrawl Dokploy template with the current upstream self-hosted architecture
pin Firecrawl source builds to v2.8.0 and switch startup to the upstream harness entrypoint
update the template env model for PostgreSQL and RabbitMQ, and refresh the meta.json entry
What changed
replaced the stale split-process Firecrawl deployment with the current harness-driven api service
added the missing rabbitmq dependency and kept redis, playwright-service, and nuq-postgres
changed Firecrawl-owned services from latest images to remote source builds pinned to v2.8.0
updated Dokploy template variables to use POSTGRES_*, NUQ_RABBITMQ_URL, and current optional Firecrawl envs
pinned the Firecrawl metadata version to v2.8.0
running the required meta processing also removed a pre-existing duplicate strapi entry from meta.json
Root cause
The existing Firecrawl template still launched the old runtime layout using node --import ./dist/src/otel.js .... Upstream Firecrawl now starts through node dist/src/harness.js --start-docker and expects RabbitMQ plus harness-managed workers, so the old Dokploy template crashed with ERR_MODULE_NOT_FOUND for /app/dist/src/otel.js.
Impact
Dokploy users should get a Firecrawl deployment shape that matches current upstream self-hosting instead of the broken legacy image startup path. The template is also now version-pinned instead of following latest.
npm run validate-docker-compose -- --file ../blueprints/firecrawl/docker-compose.yml (from build-scripts/)
npm run validate-template -- --dir ../blueprints/firecrawl (from build-scripts/)
git diff --check
🔄 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/768
**Author:** [@Manan-Santoki](https://github.com/Manan-Santoki)
**Created:** 4/3/2026
**Status:** ❌ Closed
**Base:** `canary` ← **Head:** `codex/fix-firecrawl-template-v2-8-0`
---
### 📝 Commits (1)
- [`d9c507e`](https://github.com/Dokploy/templates/commit/d9c507e093b32d211a96f6688f1e5eb105b58921) fix: update firecrawl template for v2.8.0
### 📊 Changes
**3 files changed** (+98 additions, -82 deletions)
<details>
<summary>View changed files</summary>
📝 `blueprints/firecrawl/docker-compose.yml` (+65 -58)
📝 `blueprints/firecrawl/template.toml` (+31 -4)
📝 `meta.json` (+2 -20)
</details>
### 📄 Description
## Summary
- align the Firecrawl Dokploy template with the current upstream self-hosted architecture
- pin Firecrawl source builds to `v2.8.0` and switch startup to the upstream harness entrypoint
- update the template env model for PostgreSQL and RabbitMQ, and refresh the `meta.json` entry
## What changed
- replaced the stale split-process Firecrawl deployment with the current harness-driven `api` service
- added the missing `rabbitmq` dependency and kept `redis`, `playwright-service`, and `nuq-postgres`
- changed Firecrawl-owned services from `latest` images to remote source builds pinned to `v2.8.0`
- updated Dokploy template variables to use `POSTGRES_*`, `NUQ_RABBITMQ_URL`, and current optional Firecrawl envs
- pinned the Firecrawl metadata version to `v2.8.0`
- running the required meta processing also removed a pre-existing duplicate `strapi` entry from `meta.json`
## Root cause
The existing Firecrawl template still launched the old runtime layout using `node --import ./dist/src/otel.js ...`. Upstream Firecrawl now starts through `node dist/src/harness.js --start-docker` and expects RabbitMQ plus harness-managed workers, so the old Dokploy template crashed with `ERR_MODULE_NOT_FOUND` for `/app/dist/src/otel.js`.
## Impact
Dokploy users should get a Firecrawl deployment shape that matches current upstream self-hosting instead of the broken legacy image startup path. The template is also now version-pinned instead of following `latest`.
## Validation
- `node dedupe-and-sort-meta.js`
- `docker compose -f blueprints/firecrawl/docker-compose.yml config`
- `npm run validate-docker-compose -- --file ../blueprints/firecrawl/docker-compose.yml` (from `build-scripts/`)
- `npm run validate-template -- --dir ../blueprints/firecrawl` (from `build-scripts/`)
- `git diff --check`
---
<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/768
Author: @Manan-Santoki
Created: 4/3/2026
Status: ❌ Closed
Base:
canary← Head:codex/fix-firecrawl-template-v2-8-0📝 Commits (1)
d9c507efix: update firecrawl template for v2.8.0📊 Changes
3 files changed (+98 additions, -82 deletions)
View changed files
📝
blueprints/firecrawl/docker-compose.yml(+65 -58)📝
blueprints/firecrawl/template.toml(+31 -4)📝
meta.json(+2 -20)📄 Description
Summary
v2.8.0and switch startup to the upstream harness entrypointmeta.jsonentryWhat changed
apiservicerabbitmqdependency and keptredis,playwright-service, andnuq-postgreslatestimages to remote source builds pinned tov2.8.0POSTGRES_*,NUQ_RABBITMQ_URL, and current optional Firecrawl envsv2.8.0strapientry frommeta.jsonRoot cause
The existing Firecrawl template still launched the old runtime layout using
node --import ./dist/src/otel.js .... Upstream Firecrawl now starts throughnode dist/src/harness.js --start-dockerand expects RabbitMQ plus harness-managed workers, so the old Dokploy template crashed withERR_MODULE_NOT_FOUNDfor/app/dist/src/otel.js.Impact
Dokploy users should get a Firecrawl deployment shape that matches current upstream self-hosting instead of the broken legacy image startup path. The template is also now version-pinned instead of following
latest.Validation
node dedupe-and-sort-meta.jsdocker compose -f blueprints/firecrawl/docker-compose.yml confignpm run validate-docker-compose -- --file ../blueprints/firecrawl/docker-compose.yml(frombuild-scripts/)npm run validate-template -- --dir ../blueprints/firecrawl(frombuild-scripts/)git diff --check🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.