# Architecture & Migration Reference

  ZebraByte is delivered as a managed Cloud SaaS platform and is not distributed
  as open-source or self-hosted software. This section is intentionally preserved
  because the earlier Docker and Kubernetes architecture remains useful for
  migration planning, security analysis and understanding platform dependencies.

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

- **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.

- [Docker Compose reference](/docs/deployment/self-hosting/docker-compose) — Review the preserved single-host architecture, configuration, backup and security considerations
- [Kubernetes reference](/docs/deployment/self-hosting/kubernetes) — Review the preserved Helm/Kubernetes architecture, data services, ingress and operational considerations

## 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](/managed-compliance), ZebraByte can also take on more of the compliance-program workload itself.

## 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

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](/docs/deployment/cloud) or the [Cloud quickstart](/docs/product/getting-started/quickstart).