Architecture & Migration Reference
Preserved Docker Compose and Kubernetes deployment-lineage documentation for architecture review and migration planning; ZebraByte itself is delivered as managed Cloud SaaS.
The platform lineage documented here used a containerized application backed by PostgreSQL and S3-compatible object storage. A production deployment of that architecture had to provide durable data services, TLS, secrets, outbound email, backups, monitoring and an upgrade process.
That information remains relevant when evaluating a migration into ZebraByte Cloud or reviewing historical security boundaries, but ZebraByte customers do not operate these components themselves.
Preserved architecture models
Section titled “Preserved architecture models”- Docker Compose reference documents the former single-host model and the services, secrets, persistence and network exposure that had to be managed by an operator.
- Kubernetes reference documents the former Helm-based model and its dependencies on ingress, secrets, PostgreSQL, object storage, monitoring and cluster operations.
What ZebraByte Cloud changes
Section titled “What ZebraByte Cloud changes”In ZebraByte Cloud, customers and professional advisers no longer have to operate the application stack. ZebraByte handles the platform-level responsibilities that a self-hosted operator previously had to manage, including infrastructure maintenance, application updates and platform operational controls.
Your organization still controls its own compliance data, users, approvals, connected systems and business decisions. If you choose Managed Compliance, ZebraByte can also take on more of the compliance-program workload itself.
Why keep these docs?
Section titled “Why keep these docs?”The material is retained because it can still help technical teams:
- identify data and service dependencies during migration;
- understand former database and object-storage responsibilities;
- map legacy environment/configuration concepts to a cloud transition;
- review historical network, secrets and TLS assumptions;
- understand how backups, monitoring and upgrade responsibilities changed when moving to SaaS;
- perform architecture and threat-model analysis when integrating ZebraByte with existing systems.
Operator responsibilities in the historical model
Section titled “Operator responsibilities in the historical model”An operator of the earlier self-managed architecture was responsible for:
- restricting access to the application, database and object storage;
- generating and rotating application and integration secrets;
- backing up PostgreSQL and stored files as one consistent system;
- monitoring health, capacity, logs and certificate expiry;
- testing upgrades and rollback procedures;
- configuring email and identity services used by the organization.
Those responsibilities are preserved here to make the architectural difference explicit; they are not requirements for a ZebraByte Cloud customer.
For the current product, continue with ZebraByte Cloud or the Cloud quickstart.