MoraTea
MoraTea is a managed reliability and operations platform for business automations. It is built around a customized Activepieces Community Edition, not around a point-of-interest application. The problem is the operational gap between drafting a workflow and trusting it in production: a small logic change can create a wrong invoice, duplicate an action, or leave an operator unsure which version actually ran.
The idea began with recurring gather, compare, review, and action workflows. Reconciling points of interest was one early use case, but the broader problem was making repeated business automation observable, reviewable, and recoverable.
Current implementation
The current codebase is a Rust control plane beside an isolated Activepieces execution stack. A customer stack uses separate Activepieces App and Worker containers with PostgreSQL and Redis. MoraTea keeps its own account-scoped control store in SQLite and an artifact store for canonical workflow bytes. It drives Activepieces through supported interfaces and does not write to the Activepieces database directly. Activepieces keeps its normal draft-versus-published model: edits can continue on a draft while the published version serves production.
The Rust service currently contains the release and reliability boundaries: immutable candidate snapshots, logic and binding identity, evidence, approvals, deployment history, production pointers, audit records, and rollback lineage. Release jobs recover after interruption and external state is read back rather than blindly retried when an outcome is uncertain. The dashboard exposes authenticated workflow, evidence, release, and operations views. A narrow editor handoff connects an owned MoraTea workflow to the matching Activepieces editor without forwarding MoraTea credentials.
Reliability work
Testing is risk-aware rather than a single generic pass. Read-only observations and reversible operations can use a lighter test path. Database writes, deletes, outbound messages, payments, permission changes, and production deployments need stronger isolation, explicit evidence, and human approval. The current reliability path includes deterministic scenarios, a mock accounting oracle, candidate claims, append-only evidence, and release execution against an exact draft. A candidate is only publishable after its artifact, required scenarios, approval, and current Activepieces readback still agree.
Work ahead
MoraTea remains active development. Current work is tightening the control and reliability loops, operations evidence, failure recovery, and the boundary between authoring, testing, approval, and release. Longer-term architecture may add more customer workflow cases and operational capacity, but the project is deliberately not claiming a universal automation operating system or a synthetic reliability score.
Status: Active development.
Built with Rust, Tokio, SQLite, PostgreSQL, Redis, a static dashboard, and a customized Activepieces fork.