Ordinary files and version history
The current version of each file is stored as a regular file in the Lazync-managed library. Earlier versions remain associated with a stable file identity and can be inspected or restored from the web interface.
A self-hosted file library with
desktop directory synchronization.
Lazync connects a personal NAS or Linux file server to one bound folder on a desktop computer. The server stores current content as ordinary files and retains version history. The Lazarus client monitors the local folder, manages transfer queues, and resumes synchronization after interruptions. Windows is currently supported; Linux and macOS client builds are planned. Storage, access, TLS, and backup remain under the server operator's control.
Lazync is alpha software. Core synchronization is available, but several behaviors required for dependable multi-device use remain incomplete. Do not use it as the only copy of important data.
Self-hosted
Run the server on a Linux host you administer. Accounts, directory grants, certificates, and stored data remain within that environment.
Ordinary-file storage
Current data remains directly readable as ordinary files. Lazync maintains version history alongside it without placing file content in a proprietary container.
Open source
The server and client are published under GPL-3.0. Their synchronization, authentication, and storage behavior can be inspected in the source.
Server-side file management and desktop directory sync
The server maintains the remote namespace, version history, and access grants. The desktop client binds one account to one local directory and synchronizes from filesystem notifications and the remote change journal.
Self-hosted server
Resumable transfers
Uploads use 8 MiB chunks and retain progress across interruptions. Downloads use conditional byte-range requests and continue from the last verified position.
Incremental change journal
Clients request entries after their last persistent cursor. If that cursor is no longer valid, the protocol requires a full reconciliation before incremental processing resumes.
Atomic operations and recovery
Updates use temporary files and atomic replacement. Recovery records and an exclusive writer lock help preserve library consistency after an interrupted operation.
Accounts and per-directory grants
The authentication model includes user accounts, revocable device credentials, expiring sessions, and login rate limiting. Directory grants can be read-only or read/write.
Web file manager
The English and Simplified Chinese web interface supports upload, download, directory management, version history and restore, plus administrator-managed users and grants.
Desktop client
Desktop and tray operation
The current Windows build provides an English and Simplified Chinese interface, remains available from the system tray, and preserves its binding across restarts. The Lazarus codebase is intended to support Linux and macOS builds as their platform integrations are completed.
Monitoring and reconciliation
The client combines recursive filesystem notifications with periodic reconciliation. This covers changes made while offline, missed notifications, and watcher overflow while allowing each operating system to use its native monitoring API.
Controlled transfer queues
Upload and download use separate FIFO queues, with one active transfer in each direction. Progress is persisted, SHA-256 verifies content, ETags protect concurrent writes, and downloaded files are installed atomically.
Filters and desktop integration
File, directory, glob, and extension filters are supported, and empty directories are synchronized. The current Windows build offers optional Explorer status overlays and a Lazync icon for the managed root; desktop integration on other systems will be platform-specific.
Protected client credentials
Device tokens belong in the operating system's secure credential store; the current Windows build uses Credential Manager. The client does not write account passwords or tokens to its INI file.
Explicit certificate verification
Certificate verification follows the operating system trust store; the current build uses Windows trusted roots. A private certificate that cannot be verified requires manual SHA-256 fingerprint review and is then pinned to the account binding.
Architecture
The server is authoritative for account permissions, file identities, version history, and the remote change journal. The client limits its file management to the configured directory and its hidden metadata directory.
Managed folder
An ordinary desktop folder you work in
Lazync client
Secure credentials · binding state
Lazync server
Grants · change journal
File library
Ordinary files + history
Deployment status
Lazync has not yet reached the point where it can be installed and operated through a simple, stable, and supported deployment procedure.
Current stage
The public repository is currently intended for source review and development testing. Running the server requires a source build and manual preparation of configuration, TLS, filesystem permissions, and process supervision. These details are still changing and are not presented as an end-user installation path.
Release goal
The release process is being revised around a self-contained Linux server archive with a one-command installer and installable desktop packages. Windows is the current client packaging target; Linux and macOS builds will follow after filesystem monitoring, secure credential storage, and desktop integration have been adapted and tested on each platform. A deployment guide will be published after the release artifacts and upgrade paths have been verified together.
Lazync keeps its operational boundary explicit: files reside on a server you administer, synchronization state remains inspectable, and backup remains an administrator responsibility.
Security model
Transport security, server storage, and administrator responsibilities are separate parts of the model. The current boundaries are as follows.
- Use HTTPS for every client and browser connection, including access through port forwarding.
- Server files and historical versions are stored in plaintext; use NAS volume encryption if you need encryption at rest.
- The server INI holds the root-managed administrator password by design — keep it readable only by root.
- Do not let other applications write directly into the server library.
- Back up both live files and the
.lazyncmetadata tree in one consistent snapshot. - Compare a manually accepted certificate fingerprint through an independent channel before trusting it.
Review the security policy before exposing a server outside a trusted local network.
Project status
The project is in alpha, with a working synchronization baseline and several unresolved cases that affect dependable multi-device operation.
Implemented
- Local additions and edits upload automatically; remote creates, updates and deletes download automatically
- Resumable uploads and downloads, SHA-256 verification, atomic installation
- Version history, viewable and restorable from the web interface
- Accounts, device credentials, and per-directory read-only or read/write grants
Still incomplete
- Propagation of local deletion and local rename operations
- Automatic conflict copies and complete offline multi-device conflict resolution
- Multiple active accounts or managed folders in the desktop UI
- Linux and macOS client builds and their platform-specific integrations
- Binary delta transfer, supported release packages, and automatic updates
Changed files are transferred in full, although interrupted transfers can resume. The 2 TB per-file and 500,000-files-per-binding values are protocol ceilings, not qualified deployment capacities. Effective limits depend on the NAS, filesystem, network, version retention, and path structure; see capacity and transfer limits. Use separately backed-up data for alpha testing. Development progress is tracked in the GitHub repository.
Lazync = Lazarus + sync
The server and client are implemented in Free Pascal / Lazarus. Lazarus was selected in part so the desktop client can target additional operating systems as platform support matures.
Source code
The complete source is available under GPL-3.0. Production-ready release packages are not available yet; the repository is suitable for code review and development builds while the deployment and packaging work continues.