MEGAcmd: one MEGA server behind an interactive shell and a set of mega-* commands

Two interaction modes and the three processes behind them

The design decision that explains everything else in MEGAcmd is the two-mode split. The README states it plainly: an interactive mode, which is a shell you query, and a scriptable mode, which executes commands from a shell, a script or another program.

Serving both requires three kinds of component. One server, MEGAcmdServer, holds the session and does the work. One interactive shell, MEGAcmdShell, is what a human types into. And several commands that launch the non-interactive client, MEGAcmdClient, one per operation. Installed to a system, those become `mega-cmd-server`, `mega-cmd`, and a set of `mega-*` executables such as `mega-put` and `mega-cd`.

So a scripted line like `mega-export` is not a standalone program that connects to MEGA. It talks to the already-running server, which is why the README insists that both modes require MEGAcmdServer to be up. The convenience is that the server starts automatically when you open the shell or run a command, so you do not have to manage it in normal use.

The failure signal is designed for scripting too: those commands have an output value other than zero on failure, and the README points at `src/megacmd.h` for the list of existing error codes. That is a small detail that separates a tool usable in a cron job from a tool you have to read the output of by hand.

Sessions are cached in your home folder, and logout is the way out

How state persists is the part most likely to surprise you. When you log in, the session, the list of synced folders, the cache databases and extra configuration are stored in your local home folder. Closing MEGAcmd does not delete them, and restarting the server restores the previous session, so it behaves like the MEGA Desktop App and does not ask for credentials again.

The consequence is that MEGAcmd will happily reconnect without a password prompt, which is convenient until you want it to stop. The README is direct about the only supported way to clear that data: log out properly. Killing the process leaves the session on disk.

This design has a second implication for automation. Because the session lives in your home folder rather than in a process argument, the same commands work from a cron job or a systemd unit without embedding credentials in the job definition. That is a real advantage over passing tokens on a command line, where they would land in process listings and shell history.

For the WebDAV server the same reasoning applies. If you expose a folder through it, the authentication story is inherited from the cached session rather than from per-request credentials, so the security of that endpoint depends on the session and on how you bind it. The README does not discuss TLS termination or access control for the WebDAV server, so treat that as something to check on the deployment side.

Sync, scheduled backups, WebDAV and streaming from one shell

Four capabilities share the same command surface. Synchronization is the plainest, binding a local folder to a folder in your MEGA account and keeping both ways in step:

sync /path/to/local/folder /folder/in/mega

Backups are the feature that separates MEGAcmd from a file transfer tool. You give it a local folder, a remote path, a schedule and a retention count, and it keeps historical snapshots rather than a mirror:

backup /path/mega/folder /remote/path --period="0 0 4 * * *" --num-backups=10

That example stores ten copies at four in the morning UTC daily. The schedule is a six-field cron-style string and the retention argument is what makes this a backup tool rather than another sync direction. The README points at `contrib/docs/BACKUPS.md` for the detail.

Serving and streaming are the third capability, and they share a command:

webdav /path/mega/folder
webdav /path/to/myfile.mp4

The first form publishes a location over WebDAV so other software can mount it as a drive. The second streams a single file. More detail is in `contrib/docs/WEBDAV.md`. There is also a `get` command for pulling down the contents of a shared link by URL.

Taken together, these cover the three things people actually want from cloud storage on a machine they cannot watch: keep a directory mirrored, keep historical copies on a schedule, and expose the result to something else on the network.

Building from source with CMake, vcpkg and recursive submodules

Prebuilt packages are linked from mega.nz/cmd for all supported platforms, and the README says to fall back to building from source if a package fails to install. That path is a conventional CMake project with one unusual feature: all dependencies come from vcpkg automatically, and the local vcpkg checkout is pointed at with `-DVCPKG_ROOT`, defaulting to `../vcpkg`.

Getting the source requires a recursive clone, which is a common source of confusion when the build fails immediately:

git clone https://github.com/meganz/MEGAcmd.git
cd MEGAcmd && git submodule update --init --recursive

The `.gitmodules` file in the tree confirms submodules are in use, and the `sdk` directory at the repository root is most likely the MEGA SDK they point at. Skipping the submodule step is the single most likely reason a fresh build cannot find headers.

Configuration uses a build type and a conventional directory name:

cmake -B build/build-cmake-Debug -DCMAKE_BUILD_TYPE=Debug
cmake --build build/build-cmake-Debug

The supported build types are Debug, Release, MinSizeRel and RelWithDebInfo, and the README notes the `build/build-cmake-...` naming is by convention, with `-B` free to point anywhere. Tests are compiled in with `-DENABLE_MEGACMD_TESTS=ON`, which matches the `tests/` directory in the tree, and `ccache` users get `-DCMAKE_CXX_COMPILER_LAUNCHER=ccache`. The install step is `sudo cmake --install build/build-cmake-Release`, with the README warning against installing a Debug build because some paths are not set up for it.

No tagged releases, and a licence the repository does not resolve

Two facts about this repository deserve to be stated before anyone evaluates it, because both affect how you install and how you may redistribute it.

First, the repository has no GitHub releases at all. Not old ones, not a single one. There is no version number to pin, no changelog tied to a tag, and no way to say which commit a bug report applies to. Combined with a `master` default branch and pushes continuing into September 2026, the practical reading is that this is tracked by commit rather than by version, and that the binary packages at mega.nz/cmd are the artefact the vendor considers supported. If you need a fixed version for a production deployment, you have to record the commit you built yourself.

Second, the repository is tagged NOASSERTION for licensing, which is what GitHub reports when its licence detection is not confident, while a `LICENSE` file is present in the root. Those two facts do not agree on their face. A named licence file is the authoritative text; a NOASSERTION tag is an absence of a confident automated guess. Read the `LICENSE` file before you vendor this into anything, and note that no legal conclusion follows from the GitHub tag either way.

What the repository does support is reproducibility of the build. The CMake options, the pinned vcpkg manifest in `vcpkg.json`, the submodule layout and the `jenkinsfile` at the root together mean a given commit should build the same way on a configured machine. That is the level of versioning this project actually provides.

The `build-with-docker/` directory at the root indicates a containerised build path as well, which is a reasonable way to avoid assembling the vcpkg toolchain by hand on a machine that is not going to run the result.

Where MEGAcmd sits against the desktop app and the sync clients

MEGA ships a desktop application, and the README refers to it as the reference point for session behaviour, noting that MEGAcmd likewise will not ask for a password once restarted. That comparison is the clearest way to frame the tool: the desktop app is for a person at a desk, MEGAcmd is the same account driven by a shell.

The real comparison for most people is with rclone. Both speak a command line, both sync directories, both are scriptable, and both are the answer to "I want cloud storage on a box with no browser". The difference is where the value sits. In rclone, sync semantics are the core and the shell is a thin layer over a large set of backends, so switching provider is routine. In MEGAcmd, the MEGA-specific pieces are the point: the backup scheduling with retention, and the WebDAV or streaming server, which is a feature you would otherwise assemble yourself from a sync client plus a web server.

Against the desktop app, the trade is straightforward. You give up the file browser and the tray icon, and you get cron jobs.

One limitation is worth naming plainly. Everything here is bound to a single account provider. The README does not document migrating data out through any provider-neutral route, so choosing MEGAcmd is partly a decision about MEGA. If leaving with your data is a requirement, test a full download before you build a backup schedule around the tool.

Editorial conclusion

MEGAcmd earns its place on a machine where you script against cloud storage: a NAS, a build box, or anything that should fetch a file at four in the morning without a browser. The split into a long-running server, an interactive shell and one process per command is the right shape for that, and the non-interactive commands return a nonzero exit value on failure, which is what makes them composable with ordinary shell scripts. Two things to know before you commit. The repository publishes no GitHub releases at all, so there is no version to pin and you are tracking a moving default branch; the binary packages linked from mega.nz/cmd are the supported install path. And the repository is tagged NOASSERTION for licensing while a LICENSE file sits in the root, so read that file rather than assuming. Build with `-B` and `--prefix` conventions in mind, run `logout` rather than killing the server when you want your session data gone, and start from the `UserGuide.md` file in the root.

Frequently asked questions

Official sources

1. Issues
2. meganz/MEGAcmd on GitHub
3. README