Lohnt sich dein eigenes pCloud?

Build a closest honest personal substitute for pCloud in an empty repository.
Use Next.js 15, TypeScript, PostgreSQL, MinIO, and a Tauri 2 sync client; do not offer alternative stacks.
The core loop is: sync selected folders against a user-owned object store, encrypt files client-side, track versions, and restore any version on demand.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Build a desktop client that watches explicitly selected folders and ignores configured patterns.
Chunk, hash, compress, and encrypt files locally before uploading to the configured object store.
Store version metadata, tombstones, device identifiers, and integrity checks in PostgreSQL.
Provide upload and restore queues with pause, retry, bandwidth limits, and resumable transfers.
Add file history, point-in-time restore, key export, storage usage, and scheduled restore tests.
Document the failure model and make clear that one server is not a complete backup strategy.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Do not claim to reproduce proprietary data, network liquidity, regulated access, or frontier infrastructure.
Deliberately leave out multi-provider consumer sync at global scale.
Deliberately leave out guaranteed durability or ransomware recovery.
Deliberately leave out shared-drive administration, mobile apps, and enterprise compliance.
Finish by running the tests and listing the exact commands used.