Brick CLI #

What is Brick CLI? #

Brick CLI is the command-line client for Brick.

It keeps a local folder on your computer in sync with your Brick account - files and folders are mirrored in both directions as soon as a change is detected, either locally or on the server. Beyond the syncing itself, you can:

• Upload and download individual files or entire folder trees, without going through the sync folder.
• Choose which subfolders to skip entirely (selective sync).
• Give remote access to files on the device via the Brick webapp (remote control).
• Run the client as a daemon in the background, without an open terminal window.
• Manage several accounts and switch between them easily.

Installation #

Install the latest version on macOS or Linux like so:

curl -fsSL https://webbite.io/cli/install.sh | bash

The binary is installed to ~/.local/bin by default.

Commands #

Brick CLI is built around commands (login, sync, upload and so on). If you run brick with no arguments at all, the help text is printed - nothing else happens, no sync is started:

Usage:
  brick [global flags] <command> [command flags] [args]

Global flags (must come before command):

  -h, --help                    Show help information
  -v, --version                 Show version information
      --no-upgrade-check        Disable automatic upgrade check
      --no-control-api          Disable the local status/control API (used by tray apps)

Account Mgmt:

  login                         Log in via browser
  switch-accounts               Switch the active account
  whoami                        Show logged-in user and account details
  restart                       Clear existing settings and configure Brick from scratch

Storage Sync:

  sync [options]                Sync storageSyncFolder with the Storage API and watch for changes
    -d, --daemon                Detach into the background once logged in and the Storage API is reachable
    -r, --remote-control        Allow remote control via Brick webapp (also possible to enable via config file)
        --agent-root PATH       Directory to expose to remote clients when remote control is enabled (repeatable)
    -s, --selective-sync        Choose which folders to exclude from sync (deletes their local copies)
        --list-selective-sync   List the folders currently excluded from sync

Transfer:

  upload <file|dir> [target]    Upload a local file or folder
    -r, --recursive             Required to upload a folder
    -s, --silent                Suppress all output except errors
        --overwrite             Replace an existing remote file instead of creating a copy
  download <uuid|path> [dir]    Download a remote file or folder
    -r, --recursive             Required to download a folder
    -s, --silent                Suppress all output except errors

Other:

  uninstall                     Uninstall brick

A typical first-time flow looks like this:

brick login
brick switch-accounts   # only needed if your user has more than one account
brick sync

Account management #

# Log in via the browser
brick login

# Switch the active account
brick switch-accounts

# Show the logged-in user and account details
brick whoami

# Clear all local settings and configure Brick from scratch
brick restart

Storage sync #

# Start syncing: syncs storageSyncFolder with Brick's API and then watches
# the folder for changes until you stop it with Ctrl+C
brick sync

# Detach the sync into a background process (daemon) once login has
# succeeded and Brick's API is reachable
brick sync -d
brick sync --daemon

# Allow remote control via the Brick webapp (can also be enabled
# permanently via the config file, see the onboarding below)
brick sync -r
brick sync --remote-control

# Expose an additional folder to clients when remote control is enabled
# (the flag can be repeated for more folders)
brick sync --agent-root /path/to/folder

# Choose which folders to exclude from sync (deletes their local copies)
brick sync -s
brick sync --selective-sync

# List the folders currently excluded from sync
brick sync --list-selective-sync

File transfer #

# Upload a file to the account's root folder
brick upload report.pdf

# Upload a file to a specific folder in the cloud
brick upload report.pdf /Documents/Reports

# Upload an entire folder (requires -r)
brick upload -r ~/Pictures /Pictures

# Download a file to the current folder
brick download /Documents/report.pdf

# Download an entire folder to a chosen local folder (requires -r)
brick download -r /Documents ~/Downloads

See Upload and download below for the details.

Other #

# Disable the automatic upgrade check that otherwise runs at every start
brick --no-upgrade-check sync

# Disable the local status/control API that is otherwise used by the
# system tray app
brick --no-control-api sync

# Uninstall brick (binary, config file, shell completions and man page -
# you choose yourself what gets removed)
brick uninstall

# Show the help text (the same thing as running brick with no arguments)
brick -h
brick --help

# Show version information
brick -v
brick --version

First run #

The first time you run brick sync - before you have logged in or configured a sync folder - an interactive onboarding guide walks you through the following steps, in order:

1. Login #

If you are not already logged in, your browser opens against Brick for authentication. If you choose not to log in, the run is cancelled.

2. Picking a sync folder #

You get to choose where on your computer your files should be synced:

Choose a sync folder
> Use ~/Brick
  Pick existing folder in ~
  Create folder

• Use ~/Brick - creates and uses the default folder ~/Brick.
• Pick existing folder - lets you browse for an existing folder.
• Create folder - lets you type the name (or a relative path) of a new folder that is created for you.

3. Conflict handling on the first sync #

If the chosen folder is not empty, Brick asks how any files that already exist on both sides (locally and in the cloud) should be handled. See Conflict handling below for the three options.

4. What to sync #

If your account already contains folders in the cloud, you get to choose whether everything should be synced, or whether you want to exclude certain top-level folders right from the start:

Sync scope
> Sync all folders from Brick (1.2 GB)
  Pick which folders to sync

5. Remote access (remote control) #

Finally, the guide asks whether you want to be able to access files on this device remotely via the Brick webapp:

Do you want to remotely access files on this device via Brick? (Y/n):

If you answer yes, you then choose which folder should be available - your home folder or any folder you browse for. Read more under Remote control.

Once all the steps are done, the choices you made are summarized as a numbered checklist in the terminal, for example:

1. ✅ Logged in to account: acme
2. ✅ Sync folder selected (~/Brick)
3. ✅ Folders selected (all)
4. ✅ Remote file access enabled (root folder: ~)
5. ✅ Done and ready to go!

These choices are saved in the config file and used from then on when you run brick sync.

Upload and download #

brick upload and brick download transfer a single file or an entire folder tree alongside the two-way synced folder - handy for a one-off transfer, without having to set up (or touch) a sync folder first:

brick upload [-r] [-s] [--overwrite] <local-file|local-dir> [remote-path|uuid]
brick download [-r] [-s] <uuid|remote-path> [local-target-dir]

Both commands accept either a node UUID or a path wherever one is needed:

• The source for download and the target for upload may be a node UUID (for example copied from the Brick webapp) or a path like /Documents/Reports - resolved from the account's root folder in exactly the same way as in the webapp.
• The target for upload may be omitted entirely, in which case the file or folder ends up in the account's root folder. If you give a path that does not exist, it is created for you.
• The target folder for download may also be omitted, in which case the files end up in the folder you are standing in. The folder is created if it does not already exist.

Entire folders. A folder as the source requires -r/--recursive - without the flag, brick does nothing and exits with an error code, rather than guessing that you meant the whole folder tree. With -r, brick first prints a summary (Uploading 42 files in 6 folders (18.2 MB)...) before anything is transferred, and then shows a progress bar per file.

Errors during a transfer do not abort the whole run - brick continues with the remaining files, then lists every failure at the end and exits with an error code if anything went wrong.

Conflicts.

• download overwrites an existing local file with the same name.
• upload creates a copy by default (report.pdf → report (copy).pdf), just like the Brick webapp does when the name is already taken by a file in the same folder. Add --overwrite to replace the contents of the existing file in the cloud instead.

Silent mode. -s/--silent hides everything but errors - no introductory summary, no progress bars and no closing line. Useful in a cron job or script that only cares about the exit code.

Remote control #

Remote control gives you the ability to browse and access files on this device remotely, directly via the Brick webapp - without those files having to live in your synced folder or be uploaded to the cloud.

The feature is enabled either by answering yes to the question during the onboarding on the first run, or by adding the flag -r/--remote-control on each individual run:

brick sync -r

If you choose to enable it permanently during the onboarding, it is saved in the config file (remoteControl: true), and you then don't need to pass -r again - the flag still works as a one-off activation if you declined from the start but want to turn it on for a single run.

By default, your home folder is exposed. If you want to give remote access to more folders - or to folders other than the home folder - you use --agent-root, which can be repeated to add several folders:

brick sync --agent-root ~/Documents --agent-root /mnt/external-disk

The connection between the device and the Brick webapp is established via a secure tunnel to Brick's API, so the device itself doesn't need to be reachable from the outside or have any open ports.

Config file #

Brick saves its settings in a YAML file, ~/.config/brick/config.yaml.

The file is created automatically (with permissions 0600, that is, readable only by you) the first time you run brick sync, and contains the following fields:

Each entry under accounts has its own settings in turn, tied to that particular account:

The file can be edited by hand if you want, but most of the settings are most easily set by running the corresponding command (e.g. brick sync --selective-sync or the onboarding guide) instead.

Conflict handling #

On the first run #

If you pick a sync folder that already contains files while syncing against an account that also already has files in the cloud, the same file may naturally exist in both places without Brick knowing yet that they belong together. You then get to choose how such duplicates should be handled, once, before the first sync is run:

The picked folder contains files. How should possible conflicts be
handled on first sync?

Conflict resolution
> Overwrite any duplicate files on this device.
  Overwrite any duplicate files on Brick.
  Make a copy of any duplicate files (so nothing is lost).

• Overwrite any duplicate files on this device - the file in the cloud wins and is downloaded, the local file is overwritten.
• Overwrite any duplicate files on Brick - the local file wins and is uploaded, the file in the cloud is overwritten.
• Make a copy of any duplicate files - nothing is overwritten. The local file is renamed (so that it gets a unique name) and both versions are kept.

The choice applies only to the very first sync of that particular folder - once a file has been synced once, Brick knows its history and this step is not needed again.

On future runs #

After the first sync, Brick keeps track of each file's last known local and remote state (hash and ETag respectively). That lets it determine exactly what has happened since last time:

• If the file has changed on only one side (locally or in the cloud), the change is mirrored automatically to the other side - without asking you.
• If the file has been deleted on one side and is unchanged on the other, the deletion is mirrored to the other side as well.
• If the file has changed on both sides since it was last synced - a genuine conflict - the version in the cloud always wins, and the local change is overwritten.

This happens entirely automatically in the background, both when Brick runs in the foreground and as a daemon (brick sync -d).