Zyvlon (CrysoLabs product) · A monorepo platform with a hostname-routed storefront runtime, a manifest-driven site manager, a durable job queue, Dokploy deployment and a verified MongoDB → PostgreSQL migration.
Client
Zyvlon (CrysoLabs product)
Timeline
Platform build, Sept 2026
Team
Small senior team
Scope
Monorepo · Control plane · Queue · Dokploy · Migration
Multi-tenancy is easy to promise and hard to keep. Every query must be scoped to the right store, a merchant's design change must never half-apply, custom domains need DNS checks and certificates, and background jobs cannot vanish when a cache restarts. The legacy MongoDB data also had to cross over without password resets.
The web service resolves the store from the Host header in one indexed query and dynamically imports only that store's template. The admin never edits live tables directly: it posts a declarative SiteManifest to the site manager, which projects the store's current state, diffs and validates it against the template's own manifest, and applies the difference in one transaction with a ThemeVersion snapshot and audit row. Slow work, such as attaching a domain through the Dokploy API, goes to a durable queue where PostgreSQL is the truth and Redis only wakes workers. The legacy migration exports read-only (the Mongo client throws on any write), maps every model to the new schema with UUIDv7 ids derived from ObjectId timestamps, imports in a single transaction, and is checked by a separate verifier that compares counts, revenue, inventory and every order total to the cent.
Stack
Organization and store foreign keys on every tenant row
Identical manifests are no-ops; changes are atomic and audited
Wildcard TLS for merchant subdomains via Traefik on Dokploy
Atomic job claims and idempotency keys for safe replicas
Read-only export, dry-run import rehearsal, one-transaction import
bcrypt passwords preserved; new accounts use scrypt
Architecture
The web runtime only reads; the site manager is the only writer of design state. That split keeps storefronts fast and changes auditable.
Operations
One Compose deployment runs migrations first, then the apps and Redis. Merchant subdomains share a wildcard certificate; custom domains get DNS verification and are attached automatically once the storefront service id is configured.
Migration
The ETL refuses to write into a database that already has tenant data, supports dry runs and store exclusions, writes a full report and an old-to-new id map, and leaves verification to an independent command.
Storefront runtime, dashboard and landing on one side; the site manager, queue and database behind them.
Manifest, projection, diff, validation and a single transaction, rendered on the next request.
Export, transform, import and an independent verifier before cut-over.
The platform deploys from one Compose file, rolls back by redeploying a commit, and keeps working if Redis disappears. Merchants keep their existing passwords, and the storefront can be scaled out freely because it holds no state.
