Vision & Principles

Goal: DaoFlow aims to make self-hosted Docker Compose deployments dependable enough for a small team to operate without a dedicated platform team.

The intended product is a deployment platform: connect GitHub or GitLab, configure an application in the Web UI, deploy it to a Docker server, understand what happened, and recover with clear evidence when something fails. The CLI is intended to expose the same deployment engine for humans, CI, and constrained automation.

Self-Hosting Profiles

The default self-hosted installation is the lean profile: daoflow, PostgreSQL, and Redis. The optional Temporal profile adds temporal-postgresql and temporal for durable workflow orchestration; its UI remains a separate opt-in profile.

DaoFlow does not publish a universal CPU or memory minimum. The Self-Hosting Requirements separate conservative production starting points from constrained QA targets. Exact measurements are published only with a reproducible evidence record naming the tested commit and image tag. Operators should rehearse the expected build, deployment, backup, log-retention, and application workload on their own target infrastructure before relying on it for production.

Each deployment server defaults to one active image build and at most 20 queued deployments. Owners and admins can tune those limits per server. Build slots are durable across workers, abandoned slots expire, and image-only or runtime-only operations do not consume build capacity. Build work waits in oldest-first order, remains counted against the queue limit after a worker claims it, and exposes its position in the deployment dashboard. Queue admission is reserved before upload and managed-resource side effects; long uploads renew that reservation while bytes are still streaming. Worker and build lease heartbeats keep healthy long-running deployments from being mistaken for abandoned work.

Verified in this repository: GitHub and GitLab push deliveries are authenticated before entering a payload-bound recovery ledger. Expiring attempt leases and per-target outcomes allow only failed or interrupted targets to retry, while unique delivery-target keys prevent duplicate deployment records. Operators can inspect recent delivery outcomes without raw webhook bodies, signatures, or provider tokens. See the webhook recovery tests.

DaoFlow does not yet claim full Coolify or Dokploy breadth. Provider-native commit and pull-request or merge-request status, dedicated build-server placement, broader dashboard recovery flows, and deeper retention automation remain explicit production gaps.

Why DaoFlow?

Self-hosting should not require operators to assemble unrelated scripts for source control, builds, releases, logs, backups, and recovery. Existing platforms prove that a useful control plane can make these workflows approachable. DaoFlow builds on that lesson while making production safety and evidence part of the deployment model.

Teams should not have to choose between:

• Vendor lock-in — an easy deployment experience that only works on someone else's cloud
• Unsafe flexibility — raw Docker and SSH access without durable plans, permissions, or recovery evidence
• Shallow automation — APIs and CLIs that can start work but cannot consistently explain, constrain, or recover it

DaoFlow's goal is a strong middle path: a practical Coolify- or Dokploy-class deployment experience, with stricter permissions, evidence-backed operation history, explicit approval for dangerous actions, and stable CLI contracts.

Product Priority

Work is prioritized in this order:

1. Production deployment reliability — remote Docker/Compose execution, health checks, rollback, cleanup, resource limits, and recovery
2. Web UI and source-control integration — GitHub and GitLab installation, repository and branch selection, push and pull-request builds, deployment status, logs, and approvals
3. Production data safety — team-scoped registries, backup destinations, backup and restore verification, and credential isolation
4. CLI parity — important deployment and recovery workflows available with stable structured output, dry-run, permissions, and audit evidence
5. Agentic access — agents may use the CLI/API under the same constraints, but agent-specific breadth does not outrank deployment readiness

Features outside this path are deferred when they compete with making the core deployment loop trustworthy.

Open-Source Principles

DaoFlow is inspired by the same open-source ethos that drives projects like OpenClaw: the belief that the most impactful tools should be transparent, community-owned, and designed for maximum impact — not maximum revenue.

Security as Architecture

Security is an architectural priority. The following controls are targets, not an assertion that end-to-end production assurance has already been achieved:

• Automation principals should default to read-only until explicitly granted a scoped write capability
• Write paths should produce durable audit evidence
• Secrets should be masked unless specifically authorized
• Approval gates should keep humans in the loop for dangerous operations

Current limitation: Agent permissions and destructive-action controls are under active verification and are not yet an unconditional production-safety guarantee.

Current limitation: DaoFlow has not yet proved that every command-lane mutation creates a complete immutable audit record.

Current limitation: Backup and restore workflows have not yet been proven through a current real-infrastructure round trip with verified data integrity.

Current limitation: GitHub and GitLab provider, installation, callback, and checkout boundaries are not yet fully verified as team-isolated.

Data Ownership

Goal: Keep deployment state, backups, and operational decisions under the operator's explicit control.

The target architecture is self-hosted and Compose-first, with operator-visible backup and recovery evidence. Current evidence and limitations are published in the production readiness report.

The self-hosted Compose path mounts the Docker socket so DaoFlow can manage local Docker workloads; that is a high-trust boundary and belongs only on a host dedicated to trusted workloads. Database and other named-volume data is retained unless the operator explicitly chooses data removal, so backups and retention decisions remain the operator's responsibility.

Transparency Through Open Source

Verified in this repository: DaoFlow is published under the Apache License 2.0, and the repository source is available for inspection.

We believe transparency creates trust. When software has access to production infrastructure, operators need clear evidence of what the platform can and cannot do.

Impact Over Enterprise

DaoFlow aims to become a tool a small team can trust to run production workloads on their own servers. Automation may observe, explain, and assist, but should not be able to casually break production.

The goal is impact: make dependable self-hosted deployments accessible to everyone, not just teams with dedicated DevOps engineers.

Repeatable Contract Design

Current limitation: DaoFlow has not yet independently proven deterministic deployment and recovery outcomes across the complete production lifecycle.

The target deployment contract is repeatable and evidence-backed:

• daoflow deploy --compose ./compose.yaml --yes should have a repeatable, evidence-backed result
• Deployment records should capture exact inputs, resolved configs, and outcomes
• Rollback should target a specific previous deployment rather than use "best effort"
• Exit codes should remain stable: 0 = success, 1 = error, 2 = denied, 3 = dry-run

Goal: Provide one evidence-backed deployment contract for the Web UI, CLI, CI, and constrained automation.

One Deployment Engine, Multiple Interfaces

DaoFlow is designed around these intended outcomes:

1. The Web UI should become a comprehensive production operator surface — not a thin wrapper around missing server behavior
2. GitHub and GitLab should become first-class deployment sources — commit, branch, pull-request or merge-request, and build status remain traceable
3. The CLI should reach deployment parity — using the same plans, permissions, approvals, and records as the Web UI
4. Automation should be constrained by default — scoped permissions beat ambient shell access
5. Self-hosting should remain portable and open — standard Docker and Compose workloads stay under the operator's control

An agent is one possible CLI/API caller. It should not be a separate deployment system or receive a shortcut around production controls.

Decision Rules

When we make product or architecture choices, we optimize for these principles:

• Prefer smaller trusted primitives over large magical abstractions
• Prefer durable records over ephemeral process state
• Prefer explicit permissions over convenience shortcuts
• Prefer structured events over parsing raw log strings later
• Prefer one excellent deployment path over many weak ones
• Prefer agent safety over agent convenience

If a feature increases system complexity, it must clearly improve at least one of: deployment reliability, operator clarity, backup safety, agent safety, or auditability. If it does not, we defer it.