Architecture & Migration Reference
Docker Compose and Kubernetes implementation documentation for architecture review and migration planning are retained;ZebraByteitself is delivered as a managed cloud SaaS.
The platform line documented here used a containerized application supported by PostgreSQL and S3 object storage. A production implementation of this architecture had to provide durable data services,TLS, secrets, output email, backups, monitoring and an upgrade process.
This information remains relevant when evaluating a migration to ZebraByteCloud or when reviewing historical security limits, but ZebraBytenu customers operate these components on their own.
Preserved architecture models
Section “Preserved architecture models”- Docker Compose reference document the previous single-host model and the services, secrets, persistence and network exposure that had to be managed by an operator.
- Kubernetes reference Documents the previous Helm-based model and its input dependencies, secrets, PostgreSQL, object storage, monitoring and cluster operations.
What ZebraByte Cloud changes
Section titled “WhatZebraByteCloud changes”InZebraByteCloud, customers and professional consultants no longer need to operate the app stack.ZebraBytese deals with platform-level responsibilities that a self-hosting provider had to manage previously, including infrastructure maintenance, app updates, and platform operational controls.
Your organization still controls its own compliance data, users, approvals, connected systems, and business decisions. Managed compliance,ZebraByte can also take over more of the workload of the compliance program itself.
Why keep these documents?
Section titled “Why keep these documents?”The material is preserved because it can still help the technical teams:
- identify data and service dependencies during migration;
- understand former database and object-storage responsibilities;
- maps the environment/configuration concepts inherited toward a cloud transition;
- review historical network, secrets and TLS assumptions;
- Understand how backup, monitoring and upgrade responsibilities changed when switching to SaaS;
- perform architectural analysis and threat models when integrating existing systems with ZebraByte.
Operator responsibilities in the historical model
“Operator responsibilities in the historical model”A previous self-managed architecture operator was responsible for:
- restriction of access to the application, database and object storage space;
- the generation and rotation of application and integration secrets;
- PostgreSQL backup and files stored as a single coherent system;
- monitoring health, capacity, logs and certificate expiry;
- testing upgrades and rollback procedures;
- Configuration of email and identity services used by the organization.
These responsibilities are held here to make the architectural difference explicit; they are There are no requirements for a clientZebraByteCloud.
For the current product, continue with ZebraByte Cloud and la Cloud quickstart.