For the online learning world

Elearning WorldLinuxMoodleTechnical

Icing on the Pi


Like most developers I’m a bit paranoid about backups and I really dislike having to repeat something I’ve already done, so I have a Raspberry Pi (named ‘Sara’):

Raspberry Pi 3

which I use to store my git repositories. And as an upstream remote its also useful for keeping other machines in sync with another copy of the code:

Git repositories on the Pi

using a pure command line interface, such as:

mkdir moodle-theme_shoelace.git
cd moodle-theme_shoelace.git
git init --bare

but, is this ideal? I use GitHub to store my public repositories, github.com/gjb2048, but what about the same sort of thing locally? In the past GitLab has been mentioned to me so I decided to take a look.


Firefox® is a registered trademark of the Mozilla Foundation.

Ubuntu® is a registered trademark of Canonical Ltd – www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy

Moodle™ is a registered trademark of ‘Martin Dougiamas’ – moodle.com/trademarks.

Other names / logos can be trademarks of their respective owners. Please review their website for details.

I am independent from the organisations listed above and am in no way writing for or endorsed by them.


Looking at GitLab’s website, about.gitlab.com/installation, I saw that there is an installation for the Raspberry Pi 2. Crumbs I thought! I have a B+ and a 3, so I can use the 3 as that is an advancement on the 2, odd though that the installation requirements say a minimum of 4GB of RAM when the Pi only has 1GB? But, I thought, must be a cut down version then? How wrong I was. I installed the community edition (‘sudo apt-get install gitlab-ce’) as per their instructions and ops! Running ‘top’ in another shell showed that the CPU was running at 100% most of the time and GitLab was unresponsive. So glad that I got the heat-sink for the CPU. After a few hours of struggle I gave up and performed the slightly tedious method of uninstalling.

The hunt for alternatives

Not one for quitting I started to search for alternatives. Surely there must be some out there?

So I started to search and found:

Then I came across Gogs, gogs.io, it says it is lightweight and runs on a Pi, so gave it a go.



Installing from the binary, gogs.io/docs/installation/install_from_binary and following the intital configuration gogs.io/docs/installation/configuration_and_run.html was not enough initial information as I really wanted to establish remote access from the start. Refering to gogs.io/docs/advanced/configuration_cheat_sheet I created a custom ‘app.ini’ file to get things going with the fixed IP (Internet Protocol) address I have for the Pi – not shown – but I set the HTTP_ADDR and DOMAIN settings. And as I’d created a new user called ‘gogs’ to keep things separate, the setting RUN_USER. To keep things simple I’ve opted for the SQLite3 database.

This got me up and running, but I was not completely happy as I have fixed IP addresses for my machines with associated names in their respective hosts files, so referring to gogs.io/docs/advanced/configuration_cheat_sheet again I made changes from IP to the hostname.

At this point the site was HTTP, but what about HTTPS? After a bit of hunting I found, gogs.io/docs/intro/faqs#how-do-i-set-up-https. And being local I’ve also changed to offline mode, gogs.io/docs/intro/faqs#how-do-i-run-gogs-in-offline-mode%2Fon-an-intranet.

Then finally after I’d played around with Gogs for a while and liked it, I wanted it to start on boot instead of manually. Looking at gogs.io/docs/intro/faqs#how-do-i-run-gogs-as-a-daemon, Gogs already comes with scripts to help. The OS I have on the Pi is Debian based (Rasbian) so a matter of learning about daemon’s and altering the script to match the user. Or you can use systemd: gogs.io/docs/intro/faqs#how-do-i-run-gogs-at-startup-with-systemd.

I did think about running on port 80, but that requires running as root, not a good idea with software you are testing out, so kept with the HTTP alternative port of 8080.

One tricky bit that caught me out was adding SSH access, which is done by adding your public key via the user interface:

SSH Keys on Gogs

This enables ssh communication for ‘push’, ‘pull’ and ‘fetch’ between the client and the repository on the Pi.

If you don’t know how to set-up ‘ssh’ access then follow: www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md and www.raspberrypi.org/documentation/remote-access/ssh/ then you can generate another public / private key combination to use with Gogs and whichever git client you use: git-scm.com/downloads/guis or simply the shell.

Installation is not completely simple but I think that depends on your circumstances. You definitely need a bit of system administration knowledge.

The Gogs experience

The interface is really simple and feels familiar. You have three options:

Gogs create options

Where there is a ‘Migration’ that I think duplicates the repostory from elsewhere and can be a ‘mirror’? There is no documentation that I can find about this. The documentation is a bit sparce, gogs.io/docs, but as Gogs is open source and you can contribute to both the documentation github.com/gogs/docs and the actual code github.com/gogs/gogs/wiki/Contributing-Code.

The third option of creating an organisation just allows you to organise your different repositories into groups, I chose ‘OrgMcOrgface’.

Creating a repository is really easy and can either be a public or private one:

New repository on Gogs

which creates the repository in the folder on the Pi that you specified on installation. Then you are presented with instructions on what to do next:

Initial repository screen

After pushing your code, the dashboard does a good job of presenting the history of your actions:

Gogs dashboard

You can view each repository with a familiar look:

A repository on Gogs

and examine what a particular commit did:

A commit on Gogs

and even compare branches:

Gogs compare branches instruction

which gives:

Compare branch result on Gogs

Where here you can see a part of the difference between the Moodle 3.4 and 3.5 versions of my Shoelace theme (moodle.org/plugins/theme_shoelace).

Gogs can be used both on intranets and on the internet, so does come with an activity page that shows what you’ve been doing:

Gogs activity

as you would find on similar applications. Note: I believe that the eMail field is only displayed to logged in users.

User management

Even though I am using Gogs just for myself, it is designed to operate with many users, teams and organisations:

Gogs organisations

Issue management

There is an issue management system with labels:

Issue management on Gogs

What I like about it is that there is an overview screen across all repositories that you are a part of.


You can document your repositories using a Wiki:

A wiki on Gogs

I’ve only created a few pages here to experiment, but I’m sure there is ways that you can link the pages. The pages are a separate repository so should be able to export them.


The repositories you create are stored as standard directories as before:

Git repositories

so you’ll be able to backup like any other Git repository.


Overall I like Gogs, it is simple and presents a familiar interface that reduces the command line instructions you have to do. It comes with the features you need to manage a repository used for development. I’m sure that there is more to Gogs and will see over the next few months how I get along.

If you do try out Gogs, then do please come back and comment on what you feel about it.

Gareth Barnard
Latest posts by Gareth Barnard (see all)

Gareth Barnard

Gareth is a developer of numerous Moodle Themes including Essential (the most popular Moodle Theme ever), Foundation, and other plugins such as course formats, including Collapsed Topics.

2 thoughts on “Icing on the Pi

  • Pingback: What's in a number? - ElearningWorld.org

  • As a non-developer (I classify myself as a ‘code tweakier’ at best, lol) this is a fascinating read. I am a big Raspberry Pi fan myself. I have a stack of 4 of them (which is called a Raspberry Pi Bramble apparently!). Every now and again I reconfigure them for some specific project. At the moment, I’m thinking of seeing them up as 1: Webserver, 2: Database, 3: File repository, 4: Proxy – and modelling a highly optimise Moodle setup. It should even be good enough as a test environment if I send enough time o the setups, lol.
    In terms of backups, I actually use a Time Machine for my laptop backups, but for some server files I use a simple rsync script (very effective) to backup files from servers to local backup disks. Not flash, but it works well, and is very reliable.


Add a reply or comment...