# Cryptomator: client-side encryption for cloud folders you already sync

> Cryptomator is a Java desktop application that puts an encrypted vault inside any cloud folder that syncs to your local disk. It is aimed at people who want their provider to store ciphertext, and it is not a full-disk encryption tool.

**cryptomator/cryptomator** — Cryptomator for Windows, macOS, and Linux: Secure client-side encryption for your cloud storage, ensuring privacy and control over your data.

- Repository: https://github.com/cryptomator/cryptomator
- Website: https://cryptomator.org
- Stars: 16,227 · Forks: 1,545
- Language: Java
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/cryptomator-cryptomator

## The problem Cryptomator solves, and who has it

Cloud storage providers encrypt data at rest, but they hold the keys. That means the provider can read filenames, folder names and file contents, and so can anyone who obtains access to the provider's systems or to your account. Cryptomator moves the encryption to your machine: files are encrypted before the sync client ever sees them, and the provider stores ciphertext with obfuscated names.

The project is explicit about the boundary. The README lists support for Dropbox, Google Drive, OneDrive, MEGA, pCloud, ownCloud, Nextcloud, and, in the project's words, "any other cloud storage service which synchronizes with a local directory". That last clause is the real requirement: Cryptomator does not talk to cloud APIs. It needs a folder on your disk that something else keeps in sync.

The audience follows from that. It suits a person or a small team with an existing sync setup who wants the provider to hold unreadable data. It does not suit anyone who wants the provider to index, preview or search their files, because the provider cannot read them. It also does not suit anyone who needs a browser-only workflow, since the application is a native desktop client built in Java.

## How the vault mechanism actually works

A vault is a directory. Inside it, Cryptomator stores encrypted file content plus encrypted metadata, and the README states that "each file contains all information needed for decryption (except for the key of course), no common metadata means no SPOF". That design choice matters: there is no central index file whose corruption would take the whole vault with it, but it also means per-file overhead exists on every file, including small ones.

The README describes AES with 256-bit keys and scrypt for key derivation, with salts, IVs and the master key drawn from a cryptographically secure random number generator. File names are encrypted and the folder structure is obfuscated, so a directory listing on the provider side reveals neither what a file is called nor how your folders are arranged. Authenticated encryption is used for file content, which the README says lets the software "recognize changed ciphertext before decryption" rather than returning garbage plaintext.

Access is transparent: you unlock the vault with a password and work on a virtual drive, which the README compares to a USB flash drive. Multiple vaults can live in the same cloud folder with independent passwords. The README also notes that sensitive data is wiped from the heap as soon as possible, and that I/O operations are transactional and atomic "if the filesystems support it", a qualifier worth noticing because it pushes part of the consistency guarantee onto the underlying filesystem and sync client.

## Installing Cryptomator and creating a first vault

The project's own download route is the website: the README says native binaries are available on cryptomator.org, and that is the path most desktop users should take. Building from source is documented for people who want to run the development branch or package it themselves, and it requires JDK 26, for example temurin or zulu.

The build command from the README produces the jars and their OS-specific dependencies under target:

```bash
./mvnw clean install
```

To run the application from source rather than installing it, the README gives a Maven profile that starts the app with the defaults in pom.xml, picking OS-specific parameters automatically:

```bash
./mvnw -Prun compile exec:exec
```

If you already have Cryptomator installed and do not want a development run to touch its settings, logs or mount directory, add the dev profile, which switches to the Cryptomator-Dev locations:

```bash
./mvnw -Prun,dev compile exec:exec
```

Once the application is running, the workflow the README describes is: create a vault inside a folder that your cloud client already syncs, set a password for that vault, and unlock it to get a virtual drive. Files you write to that drive appear in the cloud folder as encrypted entries. The README does not document rollback, key rotation or a password-recovery procedure, so the recovery key the project provides should be stored outside the vault before you put anything in it.

## Where Cryptomator is the wrong tool

Cryptomator is not full-disk encryption. It protects files placed in a vault; it does nothing for the rest of your disk, your swap file, your browser cache or your operating system. If your threat model is a stolen laptop, a vault only covers the subset of data you moved into it.

The second limitation is the sync client itself. Cryptomator depends on another program to move bytes to the cloud, and that program sees a directory of opaque encrypted files. Some sync services behave badly with that pattern: conflict copies, partial uploads and re-uploads of large encrypted blobs are all products of the sync layer, not of Cryptomator's cryptography. The README's atomicity claim is conditional on the filesystem supporting it, which leaves the sync client as an uncontrolled variable.

The third is collaboration. The README describes vaults with individual passwords, which is a good fit for one person with several vaults. It does not describe shared vaults with per-user keys, access revocation or server-side audit. A team that needs to remove one member's access without re-encrypting the entire vault will not find that mechanism in this repository.

Finally, mobile use is a separate matter. This repository is the desktop client for Windows, macOS and Linux; the README does not describe iOS or Android builds, so anyone searching for Cryptomator on a phone should look at the project's own distribution channels rather than at this source tree.

## Cryptomator against VeraCrypt and against provider-side encryption

The most common comparison is with VeraCrypt, and the difference is architectural rather than a matter of strength. VeraCrypt creates encrypted containers and encrypted volumes at the disk level: you mount a container file or encrypt a partition, and everything inside it is protected, including files that never go near a cloud service. Cryptomator instead assumes a directory that a sync client watches, and its design goal is that the encrypted output can be uploaded piecemeal, with per-file metadata so a partial sync does not destroy the vault.

That yields a practical split. VeraCrypt containers are typically large single files, which sync clients handle poorly because every change rewrites a huge blob. Cryptomator's per-file layout is friendlier to incremental sync, and its filename encryption hides the structure of your data from the provider. In exchange, VeraCrypt covers a whole volume and does not depend on a third-party sync process, while Cryptomator covers only what you put in the vault and inherits the sync client's failure modes.

The other alternative is doing nothing and relying on the provider. That is a legitimate choice for data you would not mind the provider reading, and it is cheaper in effort. Cryptomator only pays off when the provider learning your filenames and contents is the thing you are trying to prevent.

## Licence, maintenance and what an upgrade costs you

The repository is licensed GPL-3.0, and the README states the project is dual-licensed: GPLv3 for FOSS projects and a commercial licence for independent software vendors and resellers, with the README directing those parties to contact the support team. Practically, that means shipping Cryptomator inside a proprietary product is not covered by the GPL path, and the README points to a separate commercial arrangement rather than describing its terms. Anyone planning to redistribute it should read LICENSE.txt in the repository and, if the commercial route matters, ask the project directly. This is a description of what the files say, not legal advice.

On activity: the repository is not archived, and the last push was on 2026-09-16, five days before this writing. The most recent release listed is 1.19.3 from 2026-06-29. The project is developed on the develop branch, which is also the default branch, so anyone building from a clone is building unreleased code unless they check out a release tag.

Upgrade cost is mostly operational. Because the application is distributed as native binaries and the README gives a Maven build path requiring JDK 26, a team that packages Cryptomator internally has to track that toolchain. Vaults themselves are not tied to the application version in any way the README describes, so upgrading the client does not require re-encrypting existing vaults. The README does not document a migration procedure, a downgrade path or a compatibility matrix between client versions and vault formats.

## Conclusion

Adopt Cryptomator if you sync files through a consumer cloud provider and want filenames and folder structure hidden from that provider, without giving up your existing sync client. Do not adopt it if you need whole-disk encryption, a shared team vault with per-user keys, or a server-side component, because the repository describes a desktop client and no account system. Before trusting a vault, verify three things yourself: that the README's build path works on your JDK, that your cloud client does not rewrite or re-upload files while the vault is unlocked, and that you have stored the recovery key somewhere outside the vault, since the project's own documentation offers no rollback for a lost password.

## FAQ

### What is Cryptomator used for?

It provides client-side encryption for files you keep in a cloud folder that syncs to your local disk. The README lists Dropbox, Google Drive, OneDrive, MEGA, pCloud, ownCloud and Nextcloud, and adds that it works with any service that synchronizes with a local directory. Filenames are encrypted and the folder structure is obfuscated, so the provider stores unreadable data.

### Is Cryptomator really safe?

The README states that file content uses AES with 256-bit keys, that scrypt is used for key derivation, that salts, IVs and the master key come from a cryptographically secure random number generator, and that authenticated encryption lets the software recognize changed ciphertext before decryption. It also states that sensitive data is wiped from the heap as soon as possible. Those are the project's own claims; the README points to cryptomator.org for the full security architecture.

### Which is better, VeraCrypt or Cryptomator?

They protect different things. VeraCrypt works at the disk and container level, so everything inside a mounted volume is covered whether or not it goes to a cloud service. Cryptomator encrypts files inside a directory that a sync client uploads, and the README says each file carries the information needed for decryption, which suits incremental sync. Choose based on whether your priority is a whole volume or a synced cloud folder.

### Who is behind Cryptomator?

The project is developed in the cryptomator/cryptomator repository on GitHub and distributes native binaries from cryptomator.org. The README states the project is free of charge and open source, and that it depends on donations and sponsors to fund development.

### How do I install Cryptomator on Linux?

The README says native binaries are available for download at cryptomator.org, which is the documented route for desktop users. Building from source is also documented and requires JDK 26, for example temurin or zulu, followed by ./mvnw clean install to produce the jars and OS-specific dependencies under target.

### How do I use Cryptomator with Google Drive or Dropbox?

Point the vault at a folder that your Google Drive or Dropbox client already syncs to your local disk, then unlock the vault and work on the virtual drive. The README states that Cryptomator does not connect to cloud services itself; it relies on the provider's client to synchronize the encrypted files.

## Sources

- [cryptomator/cryptomator on GitHub](https://github.com/cryptomator/cryptomator)
- [License: GPL-3.0](https://github.com/cryptomator/cryptomator/blob/develop/LICENSE)
- [Project website](https://cryptomator.org)
- [README](https://github.com/cryptomator/cryptomator/blob/develop/README.md)
- [Releases](https://github.com/cryptomator/cryptomator/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cryptomator-cryptomator