$ flowone --explain

For geeks. No marketing.

The architecture, the stack, the security model and the deployment pipeline — exactly as they run in production.

Glass-style 3D server towers with data streams on a circuit platform

Three layers. Clean boundaries.

A central fleet manager provisions and monitors every server. Each VPS runs the containerized stack as one reproducible unit. The application layer never touches infrastructure directly — every privileged operation goes through the agent's action API.

01 Fleet Manager — centralized provisioning, blueprint deployments
02 VPS + Panel — local privileged agent, task-queue execution
03 FlowOne App — the product your team actually sees

Glass-style 3D architecture: three interconnected layers — control plane, servers and app windows — joined by glowing data fibers

Boring, proven, fast.

Every component runs as a health-checked container in one compose stack — battle-tested, monitored, and chosen for predictability under load. The mail era of Postfix + Dovecot is behind us: one JMAP-native Rust binary does it all.

Glass-style 3D containers on a platform, a crane lowering a new one into place

Docker Compose

Per-server stack

Every service containerized, health-checked — one reproducible unit

Stalwart Mail

JMAP-native mail server

SMTP + JMAP + IMAP in one Rust binary — DKIM, SPF, DMARC, spam filter built in

OpenLiteSpeed + PHP

Web & app tier

HTTP/3 TLS edge; PHP with opcache + JIT

MariaDB

Primary database

InnoDB, encrypted at rest, replication-ready

Redis

Cache & pub/sub

RAM-only by policy — sessions, queues, real-time fanout

Meilisearch

Full-text search

Typo-tolerant, sub-50ms queries

Node.js WS

Real-time services

Mailbox push (mailsync) + CRDT collab editing, sub-100ms

ClamAV + Fail2Ban

Perimeter defense

SMTP-time antivirus milter, intrusion bans, FirewallD

Assume hostile. Verify everything.

The security model is layered: perimeter hardening at the edge, action-based APIs in the middle, per-object permissions at the core — and an audit trail under all of it.

JWT + 2FA

Short-lived signed tokens, enforced two-factor, device approval flow for new logins.

Action-based API

No raw shell exposure. Every operation is a whitelisted, validated, logged action.

Role-based access

Permissions resolved per object — mailbox, folder, board, document, client.

Full audit logs

Every mutation recorded with actor, timestamp and diff. Nothing happens silently.

Deploys you can trust at 3 AM.

Immutable images

Every release is built once, pushed to a registry, and pulled by servers — the exact same tested artifact everywhere.

Health-gated swaps

Every container ships a health check. A new version only takes traffic once the whole stack reports healthy.

Tagged rollbacks

Releases are versioned tags. Rolling back is repointing the tag and pulling — seconds, not a rebuild.

Fleet-wide rollouts

One control plane updates every server from the same compose blueprint — nothing drifts between boxes.

One platform. Clustered underneath.

Every mailbox lives on exactly one cluster. Each cluster is four servers with one job each: an active node serving traffic, a mirror replicating in real time, an offsite encrypted backup, and a quorum witness watching them all.

Clients / Internet

HTTPS · SMTP · JMAP — one mail platform

Per-recipient routing — each mailbox lives on exactly one cluster

cluster-a

mail.your-company.com

Healthy

Active

node-a1 · heartbeat 1 min ago

serving

StalwartMariaDBEncrypted

cpu

0.4

mem

33%

disk

45%

sec

100

live replication

Mirror

node-a2 · heartbeat 1 min ago

standby

StalwartMariaDBEncrypted

cpu

0.2

mem

31%

disk

45%

sec

100

encrypted snapshots

Backup

node-a3 · heartbeat 1 min ago

offsite

SnapshotsEncryptedOffsite

cpu

0.0

mem

12%

disk

46%

sec

100

quorum heartbeat

Witness

node-a4 · heartbeat 1 min ago

quorum

HeartbeatTiebreaker

cpu

0.0

mem

10%

disk

23%

sec

100

cluster-b

mail.your-agency.com

Healthy

Active

node-b1 · heartbeat 1 min ago

serving

StalwartMariaDBEncrypted

cpu

0.3

mem

32%

disk

53%

sec

100

live replication

Mirror

node-b2 · heartbeat 1 min ago

standby

StalwartMariaDBEncrypted

cpu

0.2

mem

37%

disk

53%

sec

100

encrypted snapshots

Backup

node-b3 · heartbeat 1 min ago

offsite

SnapshotsEncryptedOffsite

cpu

0.0

mem

12%

disk

46%

sec

100

quorum heartbeat

Witness

node-b4 · heartbeat 1 min ago

quorum

HeartbeatTiebreaker

cpu

0.0

mem

10%

disk

23%

sec

100

If an active node fails, the witness promotes its mirror automatically and traffic follows — mailboxes never notice. Backups stay offsite and encrypted either way.

Active

Serves every request — mail, files, app.

Mirror

Hot standby, replicated in real time.

Backup

Encrypted offsite snapshots, always restorable.

Witness

Watches the pair, breaks ties, triggers failover.

Watch a server die.

This is not a marketing diagram — it is the real takeover pipeline, phase by phase. The witness rules with quorum, write authority changes hands as an epoch, DNS repoints, and the clock only stops once mail provably flows again on the production hostname. At the end, the dead server rebuilds itself as a mirror.

Failover — replayed

step by step · the clock pauses at every phase

00:00

measured takeover time

We are about to kill a server.

Watch the red clock — we stop at every step and tell you what just happened.

node-1

heartbeat · 2s

active · serving

witness

quorum

watching

write epoch #12 · node-1

GTID replication

node-2

heartbeat · 1s

mirror · standby

production hostnamemail.your-co.com → node-1

functional probe web 200 + ha=active SMTP 220 IMAP OK

T+0s

Failure detected

the active node’s heartbeats go silent

+12s

Quorum verdict

the witness confirms from an independent vantage

+22s

Fence + epoch

new write epoch — the old active is read-only

+52s

Mirror promoted

database flips writable, the stack starts

+67s

DNS repointed

the production hostname moves to the new active

+222s

Functional probe

web + SMTP + IMAP through the production hostname

This replay shows the real takeover pipeline — the same phases, in the same order they run in production. The clock only stops when mail provably flows again: a DNS flip alone never counts as recovered here.

Replication trust — three independent paths

agent telemetry

the server’s own report

independent probe

the control plane queries the database itself

canary write

a real row must cross to the mirror

TRUSTED · lag < 1s

If the three paths disagree, replication is marked untrusted — and automatic promotion is blocked.

Backups — offsite, encrypted

database · every 4 hours

files · nightly

restore drill: passed

The recovery node pulls the backups — and if both data servers die, it steps in and serves.

Recovery ladder — humans only at the end

1repair replication

2reseed from backup

3recreate DB container

4full restore

!human paged — only when the ladder is exhausted

Every rung gets a bounded number of attempts, and every attempt is audited.

Tested while you sleep.

The platform tests itself around the clock: full system health, real backup restores, mailbox speed, cluster failover — hundreds of checks per cycle, every result logged. Failures page us, not you.

Can I sleep tonight?

the only dashboard question that matters

Yes — all suites passing