Do you want to fix a bug or implement a new feature in Tails? Welcome aboard, and please read on! If you want to quickly get up to speed on how to write code for Tails you might want to look at our Writing code for Tails introduction first.


Every Free Software project is a bit different from the others. This page is meant to help you understand some basics of the Tails project, so that you can more efficiently and joyfully contribute to Tails.

Focus on low-effort maintainability

Many, many Live system projects — including a few ones that aimed at enhancing their users' privacy — have lived fast and died young. We explain this by their being one wo/man efforts, as well as design decisions that made their maintenance much too costly timewise and energywise.

We want Tails to live as long as it is needed: Tails is not meant to be solely a pet project.

Since the early days of this project (i.e. early 2009), ease of maintenance in the long run has been a major factor in every decision we have made. Nowadays Tails is more alive and kicking than it has ever been, and we feel this would have been impossible without this mindset.

Our focus on low-effort maintainability has practical consequences.

First of all, we tend to carry the smallest possible delta with our upstreams (i.e. upstream software and Debian). For details about this, read our relationship with upstream statement. Moreover, we encourage you to improve Tails by working on Debian or by working on GNOME.

Second, we try not to reinvent the wheel, and we flee the Not invented here syndrome like the plague. Very little code is actually written specifically for Tails: most of what we call code work on Tails is more similar to system administration than it is to programming. We glue existing pieces together. When we need a feature that no software provides yet, we tend to pick the best existing tool, and do whatever is needed to get the needed feature upstream... which sometimes implies to write a patch ourselves.

How to get started

Pick up a task

We use GitLab to track our lists of tasks and bugs, as well as our roadmap. If you already know which one of the listed tasks you want to tackle and it has the T:Code label, then you can probably safely skip to the next section.

So you want to contribute code to Tails but do not know where to start? Our coding TODO list is huge and frightening, but...

Do not panic!

Let's see how we can help you picking up a task. A few tips:

  • Choose something that matters for you, such as fixing that bug that annoys you so much or implementing this feature you are missing so much.

  • Choose something where your singular skills and knowledge are put to work. For example:

    • Python:
      • Onion Circuits
      • Welcome Screen
      • Tails Cloner
      • WhisperBack
      • Persistent Storage
    • Perl:
      • Tails Upgrader
    • Ruby:
      • Test suite
  • Have a look to the list of Starter tasks: there is something, in each of these tasks, that one can do right away since it does not require deep knowledge of the Tails internals.

On the one hand, you may want to start doing practical stuff immediately. In this case, see the list of tasks that have the T:Code label. You probably want to start looking at the few ones that are also in the list of Starter tasks first so that you can gain confidence and we can smoothly learn to work together.

On the other hand, you may prefer picking up a task that requires some initial thought and discussion before rushing to your $EDITOR. In this case, you probably want to look at the guidelines for providing needed input.

Get in touch with our past, present and future

So you know what bug you want to fix, what feature you want to implement. At this point, we advise you to:

  1. Gather results of previous research and discussions on the topic you are interested in. Search this website, issues on GitLab and the mailing list archive.

  2. Tell us on about your plans to make sure your idea fits nicely into the big picture, and nobody is currently working on the same task.


Tails is developed using a set of Git repositories. If unsure, base your work on the devel branch, or ask.

Every commit shall implement one change and be labeled with a commit message that clearly expresses the rationale of your changes. This is needed so that your work can be easily reviewed: explain every proposed change to us in the same way you would explain it to someone who would not get the background.

Submit your work

Before diving into technical details, please read our merge policy.

You can submit small, easy changes as Git patches (prepared with the git format-patch command) over email to

For larger changes that will certainly require a few review/fix cycles before being merged, it's better if you:

  1. Fork us on our GitLab
  2. Push your work to a dedicated Git topic branch
  3. Ask us to review it.

Want more?

Still here? Good, please read on.

Read about Tails design

The specification and design document will help you understand better how Tails works.

Follow Tails development

You should subscribe to the tails-dev mailing list.

You can also follow the recent activity on GitLab.

Build a Tails image

You should test your changes before contributing them back. Most often, this requires you to build Tails USB and ISO images.

Tips & tricks for development

When you are developing, you might enjoy some tricks which allow you a faster development cycle, more useful debugging information, and son on. Here is a collection of useful development tricks

Talk to us

You can subscribe to, our development mailing list.

If you need input and don't know who to ask, mention @anonym on the corresponding GitLab issue. If he cannot outright help you directly, he most likely can find someone who is better suited to help.