Platform engineering & DevOps

One storefront runtime for every merchant, and a control plane that keeps it honest.

Zyvlon can add merchants, templates and custom domains without new deployments: one runtime serves every store, design changes land as audited transactions, and the whole stack deploys, rolls back and scales from a single Dokploy Compose file.

The multi-tenant platform and infrastructure under Zyvlon: a pnpm and Turborepo monorepo with a hostname-routed storefront runtime, a headless site manager that applies declarative manifests, a durable Postgres-backed job queue, Dokploy-native deployment, and a verified one-way migration from MongoDB to PostgreSQL.

Built by the CrysoLabs team

Zyvlon platform architecture: storefront runtime, admin, landing, site manager, PostgreSQL, job queue and Dokploy

Category

Platform Infrastructure

Collaboration

CrysoLabs Team

Primary stack

Turborepo, Next.js 16, Fastify

Business context

The original Zyvlon ran on MongoDB inside one Next.js app. Growing into a SaaS needed tenant isolation, custom domains with automatic TLS, background work that survives restarts, and a way to move every existing merchant, order and password across without a single reset.

Client fit

Best fit for SaaS founders and product teams outgrowing a single app: multi-tenant data, self-hosted deployment, domain automation, job queues and zero-loss data migrations.

What this proves

The concrete capabilities this build delivers, taken from the shipped product.

Hostname → store resolution in one indexed query; only the chosen template's code loads
Site manager applies SiteManifests as diffed, validated, single-transaction changes with a ThemeVersion snapshot and audit row
Custom domains verified by DNS and attached to the proxy through the Dokploy API
Durable job queue: Postgres is the source of truth, Redis an optional wake-up
MongoDB → PostgreSQL ETL: read-only export of 696 documents from 130 collections, one-transaction import, independent verification
Migrated users keep their bcrypt passwords; new sign-ups use scrypt

Key capabilities

Multi-tenant storefront runtime

A single stateless web service serves every store, resolves the store from the Host header, dynamically imports its template and maps theme tokens to CSS variables.

Headless control plane

The site manager projects a store's live tables into a manifest, diffs and validates changes against the template's own manifest, applies them atomically and probes storefront health.

Dokploy-native operations

One Compose deployment runs migrate, seed, web, admin, landing, site manager and Redis, with wildcard TLS for merchant subdomains and redeploy-to-rollback.

Zero-loss migration

A rehearsable ETL maps every legacy model to the new schema, keeps old ObjectIds as legacy ids and re-verifies counts, revenue and every order total to the cent.

Technology

Tools and architecture choices used to build and ship this project.

Turborepo
Next.js 16
Fastify
Prisma 7
PostgreSQL
Redis
Docker
Dokploy

Architecture summary

Monorepo boundaries

Apps (web, admin, landing, site-manager), packages (db, contracts, template-kit, core, queue, auth, ui) and templates, each with a single job.

Data conventions

Prisma 7 on PostgreSQL, UUIDv7 keys, Decimal(12,2) money carried as strings, and organization and store foreign keys on every tenant row.

Built for replicas

Job claims are atomic and scheduled work is idempotency-keyed, so web and site-manager scale horizontally; losing Redis only adds latency.

Strategic thinking

Separate the data plane (serving stores) from the control plane (changing them).

Describe desired state as manifests; let one service reconcile it.

Make the database the source of truth for jobs, and cache the rest.

Rehearse migrations until the verifier passes, then run them once.

Overview

The multi-tenant platform and infrastructure under Zyvlon: a pnpm and Turborepo monorepo with a hostname-routed storefront runtime, a headless site manager that applies declarative manifests, a durable Postgres-backed job queue, Dokploy-native deployment, and a verified one-way migration from MongoDB to PostgreSQL.

Showcase gallery

Key screens and system views from the build, each tied to what it does for the business.

How a design change lands in Zyvlon: manifest, diff, validate, transactional apply, render

Manifest-driven changes

Design saves become declarative manifests; identical manifests are no-ops and slow work such as domain attachment is queued.

Zyvlon MongoDB to PostgreSQL migration pipeline: export, transform, import, verify

MongoDB → PostgreSQL

Export where MongoDB is reachable, import where PostgreSQL is, and verify independently before cutting over.

Zyvlon dashboard listing two stores owned by one organization

Many stores, one organization

Organizations own several stores within plan limits, each on its own subdomain or custom domain.

Zyvlon store overview with plan limits and store readiness checks

Readiness from real data

Domain, payments, support contact, policies and checkout checks are computed from live store data, not a static checklist.

Related work

Outgrowing a single app?

CrysoLabs designs multi-tenant platforms, self-hosted deployments, job queues and verified data migrations that let a product scale without a rewrite every year.