Tresor – Backup Platform & App

File contents are encrypted on-device in authenticated AES-256-GCM chunks. File-key envelopes use XChaCha20-Poly1305, while devices register X25519 public keys and receive required keys as encrypted envelopes.

Private device keys remain on the device. On Android, local key material is additionally protected through the Android Keystore. The API does not receive unencrypted file contents and does not need to process plaintext for the actual data path.

The Laravel API coordinates uploads, but encrypted file bytes do not pass through the application server. Short-lived presigned URLs enable direct transfer into private S3-compatible object storage.

Smaller files use single PUT while larger files use multipart uploads. SHA-256 checksums, quota reservation, upload lifecycle handling, cleanup, and reconciliation keep interrupted or orphaned uploads under control.

Tresor models devices as security-relevant entities of their own. Access and refresh tokens are handled separately and rotated; active web and mobile sessions remain visible and individual devices can be revoked.

The product goal is deliberately low-maintenance: install, sign in or register, configure backup, and only intervene for a real reason. Authentication recovery and session lifecycles are therefore part of the core architecture rather than convenience features.

Automatic backup on Android has to work within JobScheduler quotas, background limits, and foreground-service rules. The app combines scheduled background jobs with controlled foreground paths and recovery mechanisms so backups remain reliable even for large media libraries.

Encryption, hashing, upload, and state management are part of the same processing pipeline. The focus is not only theoretical throughput but robust behavior under the actual constraints of mobile operating systems.

The current Android app is only the first client. The architecture is designed so the same global account identity, vaults, and backend logic can later be used on iOS, macOS, and desktop without introducing separate accounts or identity models per platform.

Further priorities include a stronger restore experience, adaptive processing for large media libraries, and a platform where device changes or additional clients require as little manual work as possible.