mackup Documentation

Backup and keep your application settings in sync.

15,225 stars Python Python 1 file · ~13,423 tokens
RAW Doc

File: README.md

Mackup™






Backup and keep your application settings in sync.

Table of contents

Quickstart

On macOS or Linux, if you want an easy install, you can install
Homebrew and do:

bash
# Install Mackup
brew install mackup

# Launch it and back up your files
mackup backup

If not running macOS or Linux, or you don't like Homebrew, you can use pip.

bash
# Install Mackup with PIP
pip install --upgrade mackup

# Launch it and back up your files
mackup backup

You're all set and can back up from now on.

Next, on any new workstation, do:

bash
# Install Mackup
brew install mackup

# Launch it and restore your files
mackup restore

Done!

You can find more detailed instructions in INSTALL.md.

Usage

backup, restore, link install, link uninstall and link operate on all
of your configured applications by default. To limit a command to a single
application, add its name (the identifier shown by mackup list), e.g.
mackup backup vim. Naming an application overrides the
[applications_to_sync] / [applications_to_ignore] settings in your
.mackup.cfg, so you can act on any supported app without editing your config.

mackup backup [application]

Back up your application files. Copy your local config files into the Mackup folder.
Name an application to back up only that one, e.g. mackup backup vim.

mackup restore [application]

Restore your application settings on a newly installed workstation.
Copy config files from the Mackup folder to your home folder.
Name an application to restore only that one, e.g. mackup restore emacs.

mackup link install [application]

Move your local config files into the Mackup folder,
and link them to their original place.
Name an application to install only that one.

$${\color{red}warning}$$ the link strategy doesn't work correctly on macOS

mackup link [application]

On another workstation, links local config files from the Mackup folder.
Name an application to link only that one.

mackup link uninstall [application]

Copy back any synced config file to its original place.
Removes the links and copies config files from the Mackup folder back into your
home.
Name an application (e.g. mackup link uninstall git) to unlink only that one;
scoping to an application skips the global uninstall confirmation.

mackup list

Display the list of applications supported by Mackup.

mackup -h

Get some help, obviously...

What does it do

By only tracking pure configuration files, it keeps the crap out of your
freshly new installed workstation (no cache, temporary and locally specific
files are transferred).

Mackup makes setting up the environment easy and simple.

There are 2 modes of operations: copy mode and link mode.

Copy mode

Copy mode is used to back up and restore your files.
The files are backed up into the configured Mackup folder,
which can be in Dropbox, iCloud, or wherever you configure it.

It is covered by the 2 commands:

  • mackup backup
  • mackup restore

[!WARNING]
If you are using Mackup on a current version of macOS, link mode will BREAK
YOUR PREFERENCES. macOS Sonoma (macOS 14) and later don't support symlinked
preferences, see issue #2035 for
additional information. PR #2085
added copy mode, which should be used instead.

Link mode is used to move your config files into the Mackup folder,
and link them back to their original place.

This mode is useful if you are using multiple workstations,
and want to keep your application settings in sync at all times.

  • Backs up your application settings in a safe directory (e.g. Dropbox)
  • Syncs your application settings among all your workstations
  • Restores your configuration on any fresh install in one command line

Let's take git as an example. Your settings for git are saved in your home
folder, in the .gitconfig file.

It is covered by the 3 commands:

  • mackup link install
  • mackup link
  • mackup link uninstall

If you have Dropbox, these things happen when you launch mackup link install:

  1. cp ~/.gitconfig ~/Dropbox/Mackup/.gitconfig
  2. rm ~/.gitconfig
  3. ln -s ~/Dropbox/Mackup/.gitconfig ~/.gitconfig

Now your git config is always backed up and up to date on all your workstations.

When you launch mackup link, here's what it's really doing:

  1. ln -s ~/Dropbox/Mackup/.gitconfig ~/.gitconfig

That's it, you got your git config setup on your new workstation.

mackup does the same for any supported application.

You can revert all your files to their original state.

bash
# Just run this
mackup link uninstall

This will remove the symlinks and copy back the files from the Mackup folder in
Dropbox to their original places in your home. The Mackup folder and the files
in it stay put, so that any other computer also running Mackup is unaffected.

To revert a single application instead, name it, e.g.
mackup link uninstall git. Scoping the command to an application unlinks only
that app — the rest of your setup and the Mackup config itself are left in
place, and the global uninstall confirmation is skipped.

Supported Storages

See the README file in the doc directory for more info.

Unsupported Storages

Supported Applications

Can you support application X

We can with your help ;)

Personalization & configuration

Have an application that shouldn't be generally supported but that you use?
Or some personal files you want to sync, e.g. various config files in a ~/.config/
directory or your personal ~/.gitignore?

Why did you do this

Yesterday, I had a talk with Zach Zaro, complaining
about the pain it is to reconfigure our Macbook each time we get a new one or
install from scratch. That's a talk we have already had months ago.

I change my workstation every X months. Each time I either lose my apps'
configurations, or I just waste a bunch of hours getting setup like I was on my
old box. I also spend a lot of time reconfiguring the same stuff again on all my
workstations (home, work).

Boring...

Some people tried to solve the problem on the application layer, like
Github's Boxen,
but it solves a different problem, from my point of view. I don't spend a lot
of time installing or downloading stuff. I spend time configuring it.

For years, I've used a personal shell script that was copying known config
files into Subversion, Git or Dropbox, and linked them into my home. But I felt
a lot of us had the same problem: Making a more generic tool could help others
and I could get help from others to support more apps in the tool.

So here comes Mackup, the little tool that will sync all your application
configs to Dropbox (or Google Drive, or anything).

And it's GPL, of course.

What platforms are supported

  • macOS
  • GNU/Linux

What's up with the weird name

Mackup is just a portmanteau of Mac and Backup. It is simple, short, and easy to
remember, and it corresponds with the whole idea of Mackup: the simpler – the better!
(And I suck at naming stuff, but who doesn't.)

Architecture

Want to understand how Mackup works internally? Check out the
Architecture Guide which includes:

  • Visual architecture diagram
  • Component breakdown
  • Data flow diagrams
  • Design decisions
  • Extension points for contributors

Perfect for contributors who want to understand the codebase or users
curious about how their configs are managed.

Where can I find more information

In the doc directory.

File: doc/configuration_merge_guide.md

Guide for Merging Configurations Across Machines

This guide is for users who want to combine configuration settings for two or
more machines.

For example, you might have some bash settings on Machine A (like useful
command aliases) that are not on Machine B. You also have some settings on
Machine B that you would like to move over to Machine A.

The problem is that if you use Mackup to send Machine A's bash configuration
settings to Machine B, you will permanently lose any configurations on Machine
B that you wanted to keep. Mackup obviously has no idea which features you want
to keep and which ones you don't, so you'll have to do a bit of work to merge
the different configuration files yourself before using Mackup.

Step 0: Read Through This Entire Guide First

It will probably save you some pain in the long run.

Step 1: Determine Which Configuration Files to Merge

First, pick the app you wish to keep in sync. Then determine which
configuration files will be synced for that application by doing the following:

  1. Install Mackup
  2. Create a .mackup.cfg file in your home directory
  3. Add the following two lines to .mackup.cfg. Replace bash
    in the example below with the name of your application.
text
[applications_to_sync]
bash

You can get a list of supported apps by running mackup list.

  1. Save the file
  2. Run the following command:

mackup --dry-run --verbose backup

This command will let you see what mackup will do behind the scenes when it
backs up your application's configuration files so you can readily see what
configuration files Mackup will sync. Make note of these files.

Step 2: Prepare Your Workstations for Syncing

Now that you've identified which files you have to merge, choose one of the two
approaches below for merging the configuration files. Method 1 has you do all
the configuration file merges first and then pushes them out with Mackup.
With Method 2, you'll push out the configuration files from one machine to the
others and then merge in your configuration changes gradually over time.

Which method should you use? It doesn't really matter. Method 1 is more work up
front in exchange for less work later. Method 2 is less work up front but more
work later.

Method 1 is probably best if you have very dissimilar configurations and have
few machines. Method 2 is probably best if you have a machine that is very
close to working the way you want and just need a few configuration settings
from other machines.

Method 1: Backup Merge-Push Approach

  1. Create a backup of each machine's configuration files for the app you wish
    to sync.
  2. Choose a machine that will serve as the initial "master". It doesn't really
    matter which one.
  3. Edit your configuration files on the master machine so that they
    represent the ideal version of the file you wish to distribute out to your
    other machines.

Method 1 Example

Let's say we have two machines, A and B, and we want to sync our bash configuration
across the machines. We decide that Machine A will serve as our master.

First, backup the bash configuration files (there are a few of them)
for your application on all machines.

Method 1: Sample backup commands for Machine A

bash
mkdir ~/bash_backup
cp ~/.bash_profile ~/bash_backup/bash_profile.bak
cp ~/.bash_login ~/bash_backup/bash_login.bak

...plus any other bash config files you want to keep

Method 1: Sample backup commands for Machine B

bash
mkdir ~/bash_backup
cp ~/.bash_profile ~/bash_backup/bash_profile.bak
cp ~/.bash_login ~/bash_backup/bash_login.bak

...plus any other bash config files you want to keep

Machine A will be our master so we now edit the existing configuration files
on Machine A. We will use the vim text editor to do this for each of our
configuration files:

bash
vim .bash_profile
vim .bash_login

When editing these configuration files on Machine A, copy and paste the settings
from Machine B that you want to keep. In essence, you are manually merging the
configuration files together. Once you are satisfied the configuration files
have all the settings you want and need, you are ready to push out your changes
from the master machine.

Method 2: Backup Push-Merge Approach

  1. Choose a machine that will serve as the initial "master". You'll probably
    want to choose the machine you use most and like its configuration
    settings the best.
  2. For each machine that isn't the "master" (i.e. "slaves"), back up all the
    configuration files for each app that you want to sync. That's it for now.
    However, there will be more work for you later.

Method 2 Example

Let's say we have two machines, A and B, and we want to sync our bash configuration
across the machines. We decide that Machine A will serve as our master.

Since A is our master, we only need to backup the bash configuration files on
Machine B:

Method 2: Sample backup commands for Machine B

bash
mkdir ~/bash_backup
cp ~/.bash_profile ~/bash_backup/bash_profile.bak
cp ~/.bash_login ~/bash_backup/bash_login.bak

...plus any other bash config files you want to keep

If you have other machines you are syncing with the master, back those up, too.

Step 3: Push Out the Configuration Files with Mackup

Now you are ready to use Mackup to push out the changes. You should have Mackup
already installed and the .mackup.cfg file in place according to the
instructions provided above. If not, do that before proceeding.

Run the following command on the master machine:

mackup backup

On each of the other "slave" machines, run:

mackup restore

If you used Method 1 in Step 2 above, you are done. You may discover
that you didn't quite merge the files exactly the way you wanted but don't
worry, that's why you created the configuration file backups. You can grab
snippets from these backup configuration files and add them in to the live
configuration files and then easily push the changes out to all your
machines using mackup.

If you used Method 2, you'll need to merge in new features over time. As you
discover features you need to add, you'll need to take the appropriate snippets
of configuration code from the backup configuration files you created and
insert them into the appropriate configuration file. Remember it does not matter
which machine's configuration file you update as these configuration files are
now shared across all machines.

File: doc/develop.md

Develop

sh
# Install the tool for dependency management and packaging in Python
pipx install uv

# You can now edit files and see the impact of your changes
uv run mackup --version
make test

Running Tests with Coverage

To run tests with coverage reporting:

sh
# Run tests with coverage
make coverage

# View coverage report in terminal
make coverage-report

# Open HTML coverage report
open htmlcov/index.html

Code Quality Checks

The project includes several code quality tools:

sh
# Run all checks (ruff, mypy, pytest)
make check

# Run individual checks
make ruff      # Code linting
make mypy      # Type checking
make test      # Unit tests
make coverage  # Tests with coverage

Coverage Configuration

Coverage is configured in pyproject.toml with:

  • Branch coverage enabled
  • Test files excluded from coverage
  • HTML and XML reports generated
  • 67%+ coverage currently achieved

You can view detailed coverage reports by running make coverage and opening
htmlcov/index.html in your browser.

File: doc/README.md

Configuration

💡 New to Mackup? Check out the
Architecture Guide to understand how Mackup works
under the hood.

All the configuration is done in a file named .mackup.cfg stored at the
root of your home folder. This location can be overridden via environment
variables or the --config-file command-line option.

To configure Mackup, create a file named .mackup.cfg in your home
directory.

bash
vi ~/.mackup.cfg

Configuration file location

Config files are searched in the following order. If none is found, Mackup will
use the default config location of ~/.mackup.cfg

  • ~/.mackup.cfg
  • $MACKUP_CONFIG
  • $XDG_CONFIG_HOME/mackup/mackup.cfg or ~/.config/mackup/mackup.cfg

You can also specify a custom config file location using the --config-file
command-line option:

bash
mackup --config-file ~/.mackup-custom.cfg backup

The path can be absolute or relative to your home directory. Note that the
config file must be located within your home directory for security reasons.

Storage

You can specify the storage type Mackup will use to store your configuration
files.

For now, you have 4 options: dropbox, google_drive, icloud and file_system.

If none is specified, Mackup will try to use the default: dropbox.
With the dropbox storage engine, Mackup will automatically figure out your
Dropbox folder.

Dropbox

ini
[storage]
engine = dropbox

Google Drive

If you choose the google_drive storage engine instead, Mackup will figure out
where your Google Drive is and store your configuration files in it.

ini
[storage]
engine = google_drive

iCloud

If you choose the iCloud storage engine, Mackup will store your
configuration files in the ~/Library/Mobile\ Documents/com\~apple\~CloudDocs/
folder.

ini
[storage]
engine = icloud

You can check if your files are synced using:

sh
brctl monitor com.apple.CloudDocs

File System

If you want to specify another directory, you can use the file_system engine
and Mackup won't try to detect any path for you: it will store your files where
you explicitly told it to, using the path setting.
The path can be absolute (from the / of your drive) or relative to your
home directory.
The path setting is mandatory when using the file_system engine.

ini
[storage]
engine = file_system
path = some/folder/in/your/home
# or path = /some/folder/in/your/root

Note: you don't need to escape spaces or wrap the path in quotes.
For example, the following paths are valid:

ini
path = some/path in your/home
path = /some path/in/your/root

Custom Directory Name

You can customize the directory name in which Mackup stores your files. By
default, if not specified, Mackup creates a Mackup directory in the storage
engine you chose, e.g. ~/Dropbox/Mackup.

ini
[storage]
directory = Mackup

For example:

ini
[storage]
engine = file_system
path = dotfiles
directory = backup

This will store your files in the ~/dotfiles/backup directory in your home.

You can also select a subfolder:

ini
[storage]
engine = icloud
directory = .config/mackup

Switching Storage

If you ever change your mind and switch storage solutions after Mackup is
already setup (ex: from dropbox to icloud), complete the following steps.

  1. Run mackup uninstall on all computers
  2. Copy your Mackup files to the new storage location
  3. Change the storage provider details in your .mackup.cfg file (see above)
  4. Run mackup backup on the main computer and mackup restore on all others

Applications

Only sync one or two applications

In your home folder, create a file named .mackup.cfg and add the application
names to allow in the [applications_to_sync] section, one per line.

ini
# Example, to only sync SSH and Adium:
[applications_to_sync]
ssh
adium

Use mackup list to get a list of valid application names. Don't use fancy
names (with spaces) here.

A sample of this file is available in this folder. Just copy it
to your home folder:

bash
cp mackup/doc/.mackup.cfg ~/

Don't sync an application

In your home folder, create a file named .mackup.cfg and add the application
names to ignore in the [applications_to_ignore] section, one per line.

ini
# Example, to not sync SSH and Adium:
[applications_to_ignore]
ssh
adium

Use mackup list to get a list of valid application names. Don't use fancy
names (with spaces) here.

A sample of this file is available in this folder. Just copy it
to your home folder:

bash
cp mackup/doc/.mackup.cfg ~/

Get official support for an application

Open a new issue and ask for it, or
fork Mackup and open a
Pull Request.
The stock application configs are in the mackup/applications directory.

Remember to follow the guidelines in CONTRIBUTING.md
to get your Pull Request merged faster.

Add support for an application or (almost) any file or directory

You can customize the Mackup engine and add support for unsupported
applications or just custom files and directories you'd like to sync.

NOTE: Files and directories to be synced should be rooted at $HOME.

Let's say that you'd like to add support for Nethack (config file:
.nethackrc), for the bin and .hidden directories and for the
.gitignore file you keep in your home.

In your home, create a .mackup directory and add a config file for the
application you'd like to support:

bash
mkdir ~/.mackup
touch ~/.mackup/nethack.cfg
touch ~/.mackup/my-files.cfg

Custom applications directory location

Custom application configs are searched in the following order:

  1. ~/.mackup/ (legacy location, takes priority)
  2. $XDG_CONFIG_HOME/mackup/applications/ or ~/.config/mackup/applications/

If the same application config exists in both locations, the legacy location
(~/.mackup/) takes priority.

For XDG-compliant setups, you can use:

bash
mkdir -p ~/.config/mackup/applications
touch ~/.config/mackup/applications/nethack.cfg

Edit those files:

bash
$ nano ~/.mackup/nethack.cfg
[application]
name = Nethack

[configuration_files]
.nethackrc
bash
$ nano ~/.mackup/my-files.cfg
[application]
name = My personal synced files and dirs

[configuration_files]
bin
.hidden
.gitignore

Note that Mackup assumes the file paths listed here are relative to your home
directory.

You can run mackup to see if they are listed:

bash
$ mackup list
Supported applications:
[...]
 - my-files
 - nethack
[...]

All good, you can now sync your newly configured files:

bash
mackup backup

If you override an application config that is already supported by Mackup, your
new config for this application will replace the one provided by Mackup.

You can find some sample configs in this directory.

Locally test an application before submitting a Pull Request

You can add and test an application by following these steps:

  • fork this project
  • create a branch (usually containing the name of the application)
  • add the appropriate application config file in the mackup/applications folder
  • from the top-most folder (mackup) run make develop that replaces the
    currently installed mackup with the local modified one
  • simply run mackup backup to test if everything is ok
  • if everything works as expected:
    • run make undevelop to revert to the official version
    • commit and push the change to your fork and then create the Pulls Request

Add support for an application using the XDG directory

For applications storing their configuration under the ~/.config folder, you
should not hardcode it. The .config folder is the default location but it can
be named differently on other users' systems by setting the XDG_CONFIG_HOME
environment variable.

See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Mackup supports this mechanism and provides a dedicated xdg_configuration_files
section for those applications.

If any path starts with .config, remove the .config part and move the path
to a dedicated xdg_configuration_files section.

Instead of:

ini
[application]
name = Git

[configuration_files]
.gitconfig
.config/git/config
.config/git/ignore
.config/git/attributes

Use this:

ini
[application]
name = Git

[configuration_files]
.gitconfig

[xdg_configuration_files]
git/config
git/ignore
git/attributes

File: doc/release.md

Release

Releasing is now automated. Pushing a version tag triggers the
release workflow, which builds the
package, publishes it to PyPI, and creates the GitHub release.

To cut a release, run one command. The version is X.Y.Z
(major.minor.patch), and the BUMP you choose increments one number and
resets the numbers to its right to 0:

sh
make release              # patch: 0.10.3 -> 0.10.4 (bug fixes)
make release BUMP=minor   # minor: 0.10.3 -> 0.11.0 (new features)
make release BUMP=major   # major: 0.10.3 -> 1.0.0  (breaking changes)
make release VERSION=1.2.3  # pin an exact version, no arithmetic

Preview a bump without changing anything with uv version --bump <level> --dry-run.

This runs the checks, bumps the version, syncs the lockfile, then commits, tags
and pushes. The workflow takes over from the tag push:

  • Builds the package with uv build
  • Publishes it to PyPI with uv publish
  • Creates the GitHub release with auto-generated notes and the built artifacts

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →