Skip to content

DevOps, pipelines, and deployment

Scope

DoWEB deploys customer and internal production workloads to Dokploy on the DoWEB-managed VPS in Germany. New workloads must not be placed on AWS, Azure, or another managed cloud platform without a written exception approved by the technical owner and recorded in the repository.

Existing deployments may remain where they are until a planned migration or material change makes alignment practical.

Dokploy project model

  • Create one Dokploy Project for each product, using the product identifier: cus-acme-crm, int-reporting, or ext-mailing-service.
  • Add a separate Dokploy application for each independently deployed component: normally web, api, or worker.
  • Use Dokploy-managed databases and services within the product boundary when possible. Name them by their role: postgres, redis, or minio.
  • Production data, uploaded customer files, and database storage require persistent volumes. Application source code and build output do not.
  • Configure public domains, HTTPS certificates, and secrets in Dokploy. Do not commit them to Git.

Build and runtime standard

New production Node.js applications use a committed, multi-stage Dockerfile and Dokploy's Dockerfile builder. The Dockerfile is part of the reviewed deployment contract and must:

  • use a supported Node.js LTS base image;
  • build only the required application and its workspace dependencies;
  • use a small production runtime image;
  • run as a non-root user where the image supports it;
  • respect PORT and bind to 0.0.0.0; and
  • expose a health endpoint such as GET /health.

Nixpacks is permitted for simple static sites and small non-Node tools when its build command is committed in nixpacks.toml. The documentation site is the reference example.

Environments

  • Local development is the default environment for active work.
  • Production is the standard deployed environment.
  • Add a staging deployment only when the product has integration risk, customer acceptance needs, or a destructive migration that cannot be tested locally.
  • Use the same container build and environment-variable names across staging and production. Values, domains, and secrets differ by environment.

Deployment workflow

  1. A work branch passes CI and receives review before it is merged into develop.
  2. When the work in develop is ready for production, open a release pull request from develop to main.
  3. The release pull request passes CI and receives review.
  4. Merging to main triggers Dokploy to build and deploy that revision, either through its Git integration or a repository webhook.
  5. The deployer verifies the health endpoint, the primary user journey, and application logs.
  6. Record any manual step or anomaly in the release pull request or linked work item.

Production changes that include a database migration must state the migration and rollback approach in the pull request. Migrations must be forward-compatible: deploy code that tolerates both schemas before removing or renaming live data.

Rollback and backup

  • Roll back application failures to the last known-good Dokploy deployment first.
  • Never treat an application rollback as a database rollback. Restore data only through a documented, tested recovery procedure.
  • Every production database needs automated backups at least daily, a documented retention period, and a restore test at least every six months.
  • Every customer-facing product needs a runbook containing its owner, domains, health check, data location, backup location, and rollback steps.

Secrets and access

  • Store runtime secrets in Dokploy's environment/secret configuration and share them only through the approved password manager.
  • Commit .env.example, never .env values.
  • Use separate credentials for each product and environment. Do not reuse a production password in development or staging.
  • Remove Dokploy and GitHub access promptly when a person no longer needs it.