Tails and its website are developed in numerous Git repositories.

Git is a distributed version control system. It allows several people to work on the same source code and handle changes in a distributed and efficient way.

Learn Git

To learn more about Git, refer to its homepage, and official documentation.

Here are a couple of links to get started with Git:

General information

Git hosting setup at immerda

Documentation for our Git hosting setup at immerda:

Merge policy

See our merge policy.


If you intend to prepare Tails releases, you'll need to make the development team signing key the default one for Git tags:

git config user.signingkey A490D0F4D311A4153E2BB7CADBB802B258ACD84F


Main repository

This repository contains the Tails source code and the source of the website.

Anyone can check it out like this:

git clone https://git-tails.immerda.ch/tails

Developers with write access to the repositories should instead:

torsocks git clone gitolite@d53ykjpeekuikgoq.onion:tails

And then, in any case, in your new Git clone's directory:

git submodule update --init

For more information about our usage of Git submodules, see the dedicated section.

We have a web interface available for the main repository.


Developers with write access to the repositories should:

git config --global url.tails@git.tails.boum.org:.insteadOf \


Tails development uses several branches modeled a bit like the Debian development process. Here they are.


The master branch is mostly used to build the website. It is merged into devel and stable from time to time. We merge into master:


The stable branch is intended to contain:

  • the state of the code tagged for the last stable release
  • fixes for security or important bugs.

Its purpose is to prepare bugfix releases.


The testing branch is used to prepare an imminent major release: at some point of the development process, the devel branch code is merged into testing, frozen, and endures careful testing and bug-fixing until this branch is considered good enough to become a stable release. The testing branch is then merged into the stable and master ones, images built and shipped and we go back to code shiny new stuff in the devel branch.

Please note that the testing branch generally has not been granted the same testing and attention as code that has made it into a stable release: please use it for testing purposes but do not rely on it for anything. No guarantee, blablabla.


Most of the development work that is done in Tails, is done in the devel branch. This branch will never get released; instead, code from it will be merged into testing and then into a real release.

Please note that the devel branch can be broken, have awful security problems and so on. No guarantee, blablabla.

The master branch is merged into devel from time to time.

Topic branches

We use topic branches called bugfix/* and feature/*, respectively aimed at fixing a single bug and implementing a single new feature. Once ready, a topic branch is merged (with --no-ff) into the appropriate branch (generally devel). Until it has been merged, a topic branch's history may be rewritten, e.g. it may be rebased on top of devel.

Unless there are good reasons to do otherwise, bugfix branches must be forked off the latest stable release tag, while feature branches should be forked off the devel branch.

If you intend to work on a branch not really meant to be proposed to a merge at first, like an experimenting branch that you still want to push to share with other developers, you can prefix its name by the keyword wip/. It will make it clear to everyone that this branch shouldn't be merged before being renamed, and our Jenkins instance will not build nor test it, so you won't get notifications for a branch that you know is breaking the build and/or the test suite.

Promotion material

This repository contains Tails promotion material.

Anyone can check it out like this:

git clone https://git-tails.immerda.ch/promotion-material

Developers with write access to the repositories should instead:

torsocks git clone gitolite@d53ykjpeekuikgoq.onion:promotion-material

We have a web interface available for the promotion material repository.

Puppet code

Puppet manifests

Only Tails system administrators have access to our Puppet manifests. If you are not a member of that team, please skip to the Puppet modules section below.

  1. Configure your SSH client:

     Host git.puppet.tails.boum.org
         HostName d53ykjpeekuikgoq.onion
         ProxyCommand torsocks monkeysphere ssh-proxycommand %h %p
  2. Clone our private Puppet manifests repository:

     git clone gitolite@git.puppet.tails.boum.org:puppet-lizard-manifests && \
     git submodule update --init

All the Puppet modules we use are tracked as Git submodules in this repository.

Puppet modules

We use and publish a lot of other Puppet modules. Each of them is stored in a Git repository called puppet-$module. For example, puppet-tails is the main public Puppet module we use to manage Tails infrastructure, including classes such as tails::reprepro and tails::whisperback::relay.

If you are on the Tails system administration team, use the authoritative repositories for these modules at git.puppet.tails.boum.org:

  • They are referenced as Git submodules in our private Puppet manifests repository so you should have a local clone of them already.
  • Anything you push to these repositories (except tails_secrets_*) is automatically synchronized to public mirrors at https://git-tails.immerda.ch/.
  • Do not push to the public mirrors: your changes would be overwritten by the next automatic synchronization.

Otherwise, you can list, browse and fork these repositories using their public mirrors.

Other repositories

All other public Tails Git repositories are at https://git-tails.immerda.ch/.

Unauthenticated access is of the form:

git clone https://git-tails.immerda.ch/$REPOSITORY

Developers with write access to the repositories should instead:

git clone tails@git.tails.boum.org:$REPOSITORY


We use Git submodules to track external repositories from the main Tails source tree.

The main practical consequence thereof so far, for most Tails contributors, is that one should generally run the following command after checking out a branch:

git submodule update --init

For more information, see:

Creating a new repository

In the vast majority of cases, your new repository will be hosted at https://git-tails.immerda.ch/. Here is how to get it created.

  1. Send your OpenPGP public key, pasted in the body of an email, to the Tails system administrators. State that you want to establish a communication channel in order to eventually get a Git repository created. Do not attach your public key, this would not work due to bugs in the mailing list software we use.
  2. Wait for the Tails system administrators to confirm they have received your OpenPGP public key and imported it into the keyring of their mailing list.
  3. Send your Git repository request in an OpenPGP-signed email to the Tails system administrators; include the following information:
    • the name you want to publicly use in our Git repository hosting system (only lower-case ASCII chars and digits);
    • the preferred name of the repository you want to create (only lower-case ASCII chars and digits);
    • your SSH RSA public key;
    • whether the repository shall be publicly available or not;
    • who else needs read access to the repository, plus their SSH RSA public key;
    • who else needs write access to the repository, plus their SSH RSA public key.

Once your repository has been created, clone it:

Initializing a git-remote-gcrypt repository

Clone the new, empty repository in a way that tells Git it's going to be encrypted:

git clone gcrypt::tails@git-tails.immerda.ch:$REPOSITORY

Change directory into the newly cloned repository:


Decide whether you want to hide to the immerda administrators which OpenPGP keys this repository will be encrypted for (note that this has severe usability drawbacks). Skip to the next step if you really want that. Otherwise:

git config gcrypt.publish-participants true

Tell Git which OpenPGP keys the repository will be encrypted for:

git config gcrypt.participants "LIST OF OPENPGP FINGERPRINTS"

Write some setup instructions for your team-mates, e.g. copy and paste the git config command(s) you have just run:

editor README

Add these setup instructions to the repository and commit:

git add README && git commit -m 'Add setup documentation.'


git push -u origin master


First, check with your team-mates: in some cases they can help you troubleshoot your problem, and confirm whether the problem is on your side or on the server side. If that is not enough, get in touch with the Tails system administrators.