Dokploy Open Source Templates

Deploy a self-hosted log search and structured observability server using the Seq Dokploy template. This template automates the setup of the official Datalust container image with the following configurations:

• Web UI & Ingestion API: Accessible via the configured Dokploy domain on port 80.
• Persistence: Includes a persistent /data volume to ensure logs are preserved across restarts.
• Security: Automatically generates a first-run admin password.
• EULA Compliance: Sets the ACCEPT_EULA=Y environment variable required by the official Seq image.

CertMate uses the following Docker volumes to persist critical data. Ensure these are managed correctly to prevent data loss during redeployments:

• certmate_certificates: Stores issued certificates.
• certmate_data: Stores application data.
• certmate_backups: Stores backup files.

When managing a Synapse deployment via Dokploy, keep the following architectural details in mind:

• Data Persistence: Signing keys and media uploads are stored in the synapse-data volume. The database is stored in the postgres-data volume.
• Federation: Federation with other Matrix servers is handled via .well-known delegation over HTTPS on port 443. The standard federation port 8448 is not exposed in this deployment.

Firecrawl uses several named volumes for persistent state. It is critical to back up the PostgreSQL volumes before performing any upgrades.

Persistent Volumes:

• firecrawl-db-data (PostgreSQL: authentication, requests, crawls, monitoring, and app data)
• nuq-postgres-data (NuQ job storage)
• redis-data (Queues, caching, rate-limiting)
• rabbitmq-data (Extract-job transport)

Backup Recommendations:

• Always back up both PostgreSQL volumes before upgrading.
• Back up Redis and RabbitMQ if you need queued jobs to survive disaster recovery.

Warning: Database initialization scripts only run when firecrawl-db-data is empty. Do not replace the pinned image version with latest without reviewing migrations and testing a restored backup, as schema or RPC changes may be required.

The Dify template deployment includes several integrated components:

• Vector Store: Uses pgvector running inside the bundled PostgreSQL instance. No external Weaviate or Qdrant containers are required.
• Routing & API Access: An internal Nginx gateway handles all routing (including /console/api, /api, /v1, /files, and /e/). The Dify service API is accessible at https://<your-domain>/v1.
• Security & Execution:
  • Code execution is isolated within the sandbox service.
  • Outbound HTTP requests triggered by users are routed through the ssrf_proxy (squid) service to prevent SSRF attacks.

The OpenStatus template deploys a self-hosted stack using the official Docker setup. The stack consists of several specialized services:

• dashboard: The Admin UI (configured as your first domain).
• status-page: Serves public status pages (configured as your second domain, accessible at /<slug>).
• server: The API backend providing tRPC and public API access.
• workflows: Handles background jobs and alerting.
• libsql: A local libSQL (Turso) database; no cloud account is required.
• db-migrate: An idempotent, one-shot migration runner that executes automatically on every deploy.
• private-location: The ingest server that receives check results from monitoring probes.

Note: The first deployment may take several minutes longer than usual because the db-migrate service is built from source.

Users should be aware of the following technical constraints in this template:

• Image Versioning: The template uses ghcr.io/frappe/lms:v2.52.0. This specific version is used because it is the latest upstream image that includes the LMS app pre-installed. Newer upstream tags may not have the app baked in.
• Payment Features: The upstream image does not include the payments app. Consequently, paid-course checkout features are unavailable. However, free courses, batches, quizzes, and certifications remain fully functional.

This template deploys n8n in Queue Mode to support scaling. The architecture consists of four main components:

• n8n (main): The primary instance that serves the Editor UI and receives webhooks/triggers. It publishes executions to the Redis queue.
• n8n-worker: Instances that pull executions from the Redis (Bull) queue and execute them. The template defaults to 2 replicas.
• redis: Acts as the message broker for the queue (password protected).
• postgres: The database used to store workflows, credentials, and execution data.

Critical Requirement: All n8n containers must share the same N8N_ENCRYPTION_KEY. In this template, this key is generated automatically to ensure workers can decrypt credentials stored in the database.

The Langfuse template exposes two distinct domains that must both be accessible for the application to function correctly:

1. Main Domain: Serves the Langfuse web application and API (via langfuse-web on port 3000).
2. Second Domain: Exposes the MinIO S3 API (on port 9000).

Crucial Note: The second domain is not just an internal implementation detail. The Langfuse web UI generates presigned URLs for media (such as images attached to traces) that the user's browser fetches directly from MinIO. Therefore, the MinIO endpoint must be publicly reachable.

The BlogFactory template is designed with a security-first networking model. During import, Dokploy generates independent secrets for the database, storage, JWT, encryption, and scheduler.

Network Isolation:

• Public Access: Only the web service is assigned a public domain.
• Private Services: The API, scheduler, PostgreSQL, and MinIO services remain private and are not exposed to the public internet.

CMS Integration Permissions: BlogFactory operates with limited authority over connected CMS providers. It sends reviewed content to connected CMS providers as drafts only. The template does not grant the application authority to live-publish or delete content on your CMS.

Persistence

All critical server state, including databases, logs, and JWT signing keys used for identities, is stored in the spacetimedb-data volume. This ensures that identities and data survive service restarts and upgrades.

Networking

• API: The service exposes the SpacetimeDB HTTP/WebSocket API. Opening the root domain (/) in a browser will return a 404, which is expected behavior.
• WebSockets: Client connections use WebSockets over the existing domain; no extra configuration is needed for WebSocket communication.