DarDev Ops Platform Maturity V1.0.0 is the roadmap that takes our internal company operating system from a capable single-VPS console to a Swarm-ready, metered, and security-gated platform at roughly one thousand users. Seven milestones—M16 through M22—ship after the M15 workspace UX foundation: client state, security hardening, scraper ecosystem, usage metering, multi-mail providers, Docker Swarm multi-VPS, and optional storage abstraction. V1.0.0 is complete when every gate is green in the maturity tracker and baseline scores in the architecture maturity model meet their targets.
This is not a customer-facing SaaS scale story. DarDev Ops orchestrates company infrastructure—Twenty CRM, Listmonk, Stalwart, news, and product solutions like Hesabi—not multi-tenant isolation for external tenants. Disk-first SQLite and local JSON remain correct today; the roadmap closes intentional gaps so we can split workloads across nodes when mail and ops exceed one host. The dardev-ops-solution-centric-os article explains why manifests and connectors stay the coupling spine through every milestone.
Baseline dimensions and V1.0.0 targets
In mid-2026 the platform scored highest on disk storage and architecture maturity, and lowest on metering and Swarm readiness. V1.0.0 raises security from roughly 6.8 to 8.5, Swarm readiness from 4.5 to 7.5, and metering from 2.0 to 7.0. Client state library maturity moves from ad-hoc useState fetches to TanStack Query plus Zustand workspace scope. Technical debt drops from about thirty percent toward twenty as duplicate fetch paths and fail-open auth are eliminated.
- Architecture maturity: 7.8 → 8.5 (M15 + M16)
- Security (internal staff): 6.8 → 8.5 (M17)
- Swarm / multi-VPS readiness: 4.5 → 7.5 (M21)
- Metering and quotas: 2.0 → 7.0 (M19)
- Multi mail provider: 4.0 → 7.5 (M20)
- Scraper ecosystem: 5.5 → 8.0 (M18)
Validators expose progress: node scripts/ops/maturity-v1-status.mjs --validate and per-gate checks with tracker-status.mjs --gate M16 through M22. Status lands in data/ops-maturity-v1-status.json for Ops Overview hints. We dogfood the same deployed-realities-explained honesty: single VPS is correct until metrics prove otherwise.
M16 — Client state and data layer
Before M16, each Configure, Inspect, Metrics, and Operate tab fetched independently with useState and useEffect. Cache invalidation broke when switching solutions or tabs; the Integration Inspector and configure panels could race duplicate requests for the same connector snapshot.
M16 introduces TanStack React Query for server state—health snapshots, KPIs, inspector payloads—and Zustand for UI chrome: active solution id, workspace tab, configure scope, and hash sync. Shared query keys mean Metrics refresh invalidates related inspector queries. useWorkspaceStore replaces prop drilling so tab switches preserve scope without full remount. Exit criteria include zero duplicate parallel fetches for the same solution inspector data and tracker-status.mjs --gate M16 green.
M17 — Security hardening and bus CI
Trusted staff on one VPS tolerated bearer auth fail-open when secrets were unset and optional webhook signatures. That blocks horizontal expansion: any second node or exposed bus endpoint needs fail-closed production behavior.
- Platform bus and sync-worker bearer middleware returns 401 when SYNC_WORKER_SECRET is unset in production profile
- Listmonk and Twenty webhook routes require shared secrets in production compose overlay
- sync-worker unit tests run in GitHub Actions on PRs touching sync-worker code
- Runbook docs/runbooks/OPS-SECURITY-GATE.md documents the gate for operators
M17 is a hard prerequisite for M21 Docker Swarm. Deploying stack services across nodes without webhook and bus write protection would multiply attack surface. Ops still orchestrates only—it never becomes the SMTP or DNS source of truth, as described in ops-orchestrates-never-configures-mail.
M18 — Scraper ecosystem
Early Ops supported scraper-oect for Hesabi accountant imports. M18 generalizes onboarding: scraper-custom provider, documented AUTHOR-SPEC, JSON schema for staging files, and lock file convention matching data/.twenty-crm-import.lock. A second reference scraper—Hesabi SMB—proves manifest plus script_ref is enough without new UI code.
Capabilities staging-status and trigger-run mirror OECT where possible. Default runsOn is operator-pc because many Tunisian government and directory sites block VPS bots; the prospect-import-pipelines-overview guide explains when local PC execution is mandatory. CRM handoff stays bus-mediated: cold prospects land in Twenty only, not Listmonk marketing lists until explicit opt-in.
M19 — Metering and usage attribution
Before metering, operators could not attribute send volume, scraper row counts, or capability invocations per solution. M19 extends the Ops audit log into daily counters in ops.db keyed by capability, solution, and connector.
- Capability invokes: Ops audit SQLite → Metrics Usage tiles
- Mail sends: Stalwart queue stats plus bus direct-send logs
- Scraper rows: staging JSON deltas on Pipelines and Metrics
- Bus API volume: structured access log in Admin Configure global view
Last-thirty-day send counts per solution appear on the Metrics tab. Nightly aggregation keeps the UI responsive without scanning raw logs on every page load. Cost attribution before multi-VPS split depends on this layer—you need per-solution send and scrape meters before arguing which node should host Stalwart.
M20 — Multi mail provider
Production mail today is Stalwart-first on send.dardev.net, sales.dardev.net, and agents.dardev.net. Architecture already defined smtp-external with the same capability IDs as smtp-stalwart—send-test and verify-auth—so a product manifest can declare an external SMTP API without Ops UI changes.
Rules unchanged: Ops links and validates; it does not edit From, Reply-To, or SMTP passwords. Root @dardev.net stays on Zoho for inbound; outbound campaigns use send subdomain per why-send-dardev-subdomain. Configure → Connectors shows mail provider summary read-only. The hybrid-sender-listmonk-stalwart-complete guide documents how Listmonk lists and direct SMTP automation coexist.
M21 — Docker Swarm multi-VPS
dardev-vps at 51.75.205.103 remains correct for ~1K internal users today. M21 adds docker-compose.swarm.yml, overlay network design in SWARM-TOPOLOGY.md, stateful placement strategy for Postgres, Redis, SQLite bind mounts, and Stalwart volumes, plus Docker secrets for cross-node secret_ref keys.
Target topology places host nginx, Ops on :5180, and platform bus on :3100 on the manager node while Twenty, Listmonk, and Stalwart can schedule on a worker VPS. server-host connector discovers multiple nodes. Stack deploy must succeed on a two-node lab with secrets absent from compose plaintext. M17 security gate must be green before any production Swarm cutover.
M22 — Storage abstraction
Disk-only is intentional until larger scraper dumps or multi-node mounts require optional S3 or NFS backends. M22 ships a StorageDriver interface—disk default, s3 and nfs for lab—routing news media and scraper staging paths through env STORAGE_DRIVER=disk. Default deploy is unchanged; switching drivers is explicit ops action.
Non-goals for V1.0.0: migrating Ops SQLite to distributed Postgres, or enabling S3 in production without a written ops request. M22 completes Platform Maturity V1.0.0 when tracker-status.mjs --gate M22 is green and SERVER-MODEL.md documents the driver.
Design principles that survive every gate
- Internal ops first—RBAC for staff, not customer multi-tenant isolation
- Manifest spine unchanged—solutions/{id}/manifest.json plus stable capability IDs
- Disk-first storage until M22 explicitly opts into remote drivers
- Security gates before node expansion—M17 before M21
- Ops orchestrates only—mail identity and DNS truth stay in Stalwart, Zoho, Listmonk, GoDaddy
DarDevOps the product (K8s/CI/CD) will extend the same manifest model with server-host connectors and CI metering when it launches. The platform operates products uniformly—Hesabi, 20.tn, Services—via the same connector graph described in multi-product-saas-one-core.
How operators track progress
Run bash scripts/ops/validate/ops-validate.sh maturity-v1-status for a sprint board view. Each milestone maps to OPS-MAT-* stories in ops/tracker/backlog.json with exit criteria checklists—duplicate fetches eliminated, 401 on unauthenticated bus writes, scraper onboardable by manifest only, thirty-day send tiles live, second SMTP provider registrable, two-node stack deployable, storage driver switchable in lab.
When all M16–M22 gates pass, update the Phase E progress tracker and announce V1.0.0 internally. External news articles document architecture patterns; they never publish gate flip commands, rate-limit SQL patches, or live-send bypass instructions per our redaction rules.
Is V1.0.0 required before we add another product solution?
No. New solutions onboard via manifest.json today. V1.0.0 closes platform gaps—metering, security, Swarm option—so operating ten solutions on one VPS stays maintainable as volume grows.
Why is M17 a blocker for Swarm?
Multi-node deploy exposes bus and webhook endpoints across hosts. Fail-open bearer auth and unsigned webhooks that were tolerable on a single trusted VPS become critical vulnerabilities when workers join the overlay network.
Does M20 let Ops edit SMTP From addresses?
No. M20 registers smtp-external providers and verify-auth capabilities. From, Reply-To, and credentials remain in Stalwart, product env, or Listmonk—Ops shows summary and health only.
When should we actually deploy Swarm?
When Metrics metering shows sustained CPU, disk, or mail queue pressure on dardev-vps and M17 is green. Until then single Compose on one host matches our ~1K user scope.
Where do I see current milestone status?
data/ops-maturity-v1-status.json locally, Ops Overview hints, and node scripts/ops/maturity-v1-status.mjs --open for dimension scores against V1.0.0 targets.
