Github, secret keys and other local settings

How to make sure your project's passwords don't end up on the internet.

July 5, 2020, 2:32 p.m.

Most of you will be familiar with Github and will know that you shouldn't put things like secret keys, email passwords, database passwords etc. in your repository. There are many ways to do that, some use separate programs for that, some manually adjust settings files. There is a fairly straightforward approach used by Wagtail that we will explain below: put all common settings in a file, all specific non-secret development settings in, all specific non-secret production settings in and only the secret settings in a file that exists locally and on the server, but is never uploaded to Github.

To show how that works we will use our pet project as an example; it will work the same way for any project. We will briefly show how to set up a repository for the project; if you are familiar with that, skip ahead.

This might also be a good time to create your and license file. Make a file, put a # sign on the first line, followed by the title of your project. There are many options for licenses, the MIT license is very common, so make a file MIT-LICENSE.txt, copy the license text and paste it in the file.

Create a git repository; we will call ours pet. Copy the <link> to the repository. Go to the project directory on your computer. Type in the following commands:

git init
git remote add origin <link>

This initializes git in your project directory and ties it to the remote repository. The next thing to do is tell git what to synchronize, or better, what NOT to synchronize, in the .gitignore file. Create the file and add at least the following content (full content available):


Most of what we don't want in our repository is self-explanatory: database files, virtual environment files, translation compilation (*.mo), test results (.coverage). We don't want media files either, because it will take up unnecessary space, we need to upload them directly to our production server anyway and pulling media files from the repository might cause conflicts. But do make sure you backup your media files! We'll come back to the settings file in a minute. First type the following:

git add .
git commit -m "initial commit"
git push -u origin master

All content is now in your remote repository. Every time you want to update your remote repository, repeat the last three commands (with "initial commit" replaced by a meaningful message). There are lots of tutorials on git available, so we leave it at this.

On to our file. Wagtail intends to use this file for local settings that should never be tracked, such as secret keys and passwords. Development settings are in, if you check this file then you see that as a last step it tries to import The secret key is also in So create and let's put a (truly) secret key in there that will not be tracked. Django has a function for that. Open the Django shell with:

python3 shell

At the prompt type:

from import get_random_secret_key

Copy the string with the secret key and leave the shell with Ctrl-D. Put in

SECRET_KEY = '<the secret key>'

This will override the one in In production, we have to copy the manually to the server once; since also imports, the secret key will be available for production as well.

The same is valid for your database settings. If your database settings are in, take them out and paste them in your file. If you want to change the password of the user, type psql postgres to go to the psql command prompt and type:

ALTER USER usr_pet WITH PASSWORD '<new password>';

Note: for automatic testing Travis needs a working remote production environment, so when using Travis we will have to add a few minimal settings; but that's for later worry.

We'll also put our email settings for authentication in; if you want to know more, read on.

Comment on this article (sign in first or confirm by name and email below)