Gitblit GO Installation & Setup

  1. Download and unzip Gitblit GO 1.8.0 (Windows) or 1.8.0 (Linux/OSX).
    It is best to eliminate spaces in the path name.
  2. The server itself is configured through a simple text file.
    Open data/ in your favorite text editor and make sure to review and set:
    • server.httpPort and server.httpsPort
    • server.storePassword (do not enter # characters)
      https is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!
    • git.packedGitLimit (set larger than the size of your largest repository)
  3. Execute authority.cmd or java -cp gitblit.jar com.gitblit.authority.Launcher --baseFolder data from a command-line
    NOTE: The Authority is a Swing GUI application. Use of this tool is not required as Gitblit GO will startup and create SSL certificates itself, BUT use of this tool allows you to control the identification metadata used in the generated self-signed certificates. Skipping this step will result in certificates with default metadata.
    1. fill out the fields in the new certificate defaults dialog
    2. enter the store password used in server.storePassword when prompted. This generates an SSL certificate for localhost.
    3. you may want to generate an SSL certificate for the hostname or ip address hostnames you are serving from
      NOTE: You can only have one SSL certificate specified for a port.
    4. exit the authority app
  4. Execute gitblit.cmd or java -jar gitblit.jar --baseFolder data from a command-line
  5. Open your browser to http://localhost:8080 or https://localhost:8443 depending on your chosen configuration.
  6. Enter the default administrator credentials: admin / admin and click the Login button
    NOTE: Make sure to change the administrator username and/or password!!

GO Data Location

By default, Gitblit GO stores all data (users, settings, repositories, etc) in the data subfolder of your GO installation. You may specify an external location for your data on the command-line by setting the --baseFolder argument. If you relocate the data folder then you must supply the --baseFolder argument to both GO and the Certificate Authority.

If you are deploying Gitblit to a *nix platform, you might consider moving the data folder out of the GO installation folder and then creating a symlink named "data" that points to your moved folder.

Specifying baseFolder via GITBLIT_HOME

You can specify GITBLIT_HOME either as an environment variable or as a -DGITBLIT_HOME JVM system property.

Including Other Properties

SINCE 1.7.0

Gitblit supports loading it's settings from multiple properties files. You can achieve this using the include=filename key. This setting supports loading multiple files using a comma as the delimiter. They are processed in the order defined and they may be nested (i.e. your included properties may include properties, etc, etc).

Creating your own Self-Signed SSL Certificate

Gitblit GO (and Gitblit Certificate Authority) automatically generates a Certificate Authority (CA) certificate and an ssl certificate signed by this CA certificate that is bound to localhost.

Remote Eclipse/EGit/JGit clients (< 3.0) will fail to communicate using this certificate because JGit always verifies the hostname of the certificate, regardless of the http.sslVerify=false client-side setting.

The EGit failure message is something like:

Cannot get remote repository refs.
Reason: https:/ cannot open git-upload-pack

If you want to serve your repositories to another machine over https then you will want to generate a new certificate for the hostname or ip address you are serving from.

NOTE: The Gitblit Authority is a GUI tool and will require X11 forwarding on headless UNIX boxes.

  1. authority.cmd or java -jar authority.jar --baseFolder data
  2. Click the new ssl certificate button (red rosette in the toolbar in upper left of window)
  3. Enter the hostname or ip address
  4. Make sure the checkbox serve https with this certificate is checked
  5. In the keystore password prompt, enter the server.storePassword password

If you decide to change the value of server.storePassword (recommended) after you have already started Gitblit or Gitblit Certificate Authority, then you will have to delete the following files and then restart the Gitblit Certificate Authority app:

  1. data/serverKeyStore.jks
  2. data/serverTrustStore.jks
  3. data/certs/caKeyStore.jks
  4. data/certs/ca.crt
  5. data/certs/caRevocationList.crl (optional)

Client SSL Certificates

SINCE 1.2.0

Gitblit supports X509 certificate authentication. This authentication method relies on your servlet container to validate/verify/trust your client certificate and can be used by your browser and your git client.

All X509 certificates have a distinguished name (DN) which is a signature of several fields like:


Gitblit must be able to map the DN of the certificate to an existing account username. The default mapping is to extract the common name (CN) value from the DN and use that as the account name. If the CN is a valid account, then the user is authenticated. The servlet container which runs Gitblit validates, verifies, and trusts the certificate passed to Gitblit. If you need to specify an alternative DN mapping you may do so with the git.certificateUsernameOIDs setting, but this mapping must be matched to the user account name.

How do you make your servlet container trust a client certificate?

In the WAR variant, you will have to manually setup your servlet container to:

  1. want/need client certificates
  2. trust a CA certificate used to sign your client certificates
  3. generate client certificates signed by your CA certificate

Alternatively, Gitblit GO is designed to facilitate use of client certificate authentication. Gitblit GO ships with a tool that simplifies creation and management of client certificates, Gitblit Certificate Authority.

Creating SSL Certificates with Gitblit Certificate Authority

When you generate a new client certificate, a zip file bundle is created which includes a P12 keystore for browsers and a PEM keystore for Git. Both of these are password-protected. Additionally, a personalized README file is generated with setup instructions for popular browsers and Git. The README is generated from data\certs\instructions.tmpl and can be modified to suit your needs.

  1. authority.cmd or java -jar authority.jar --baseFolder data
  2. Select the user for which to generate the certificate
  3. Click the new certificate button and enter the expiration date of the certificate. You must also enter a password for the generated keystore. This password is not the same as the user's login password. This password is used to protect the privatekey and public certificate you will generate for the selected user. You must also enter a password hint for the user.
  4. If your mail server settings are properly configured you will have a send email checkbox which you can use to immediately send the generated certificate bundle to the user.

Certificate Inspection and Advanced Troubleshooting

X509 certificates can be confusing and tricky even with the simplified Gitblit Certificate Authority tool. If you find you need more tooling to understand your keystores, certificates, and certificate revocation lists (CRLs), I highly recommend Portecle which can be conveniently launched as a Java Web Start app.

Running as a Windows Service

Gitblit uses Apache Commons Daemon to install and configure its Windows service.

  1. Review the contents of the installService.cmd where you may have to change the default keystore password.
  2. Set the ARCH value as appropriate for your installed Java Virtual Machine.
  3. Add any necessary --StartParams as enumerated below in Command-Line Parameters.
  4. Execute the script.

After service installation you can use the gitblitw.exe utility to control and modify the runtime settings of the service.
Additional service definition options and runtime capabilities of gitblitw.exe (prunmgr.exe) are documented here.

If you change the name of the service from gitblit you must also change the name of gitblitw.exe to match the new service name otherwise the connection between the service and the utility is lost, at least to double-click execution.

VM Considerations

By default, the service installation script configures your Windows service to use your default JVM. This setup usually defaults to a client VM.
If you have installed a JDK, you might consider using the gitblitw.exe utility to manually specify the server VM.

  1. Execute gitblitw.exe
  2. On the Java tab uncheck Use default.
  3. Manually navigate your filesystem and specify the server VM with the ... button
    Java Virtual Machine:
    C:\Program Files\Java\jre6\bin\server\jvm.dll

Command-Line Parameters

Command-Line parameters override the values in at runtime.

--baseFolder           The default base folder for all relative file reference settings
--repositoriesFolder   Git Repositories Folder
--userService          Authentication and Authorization Service (filename or fully qualified classname)
--httpPort             HTTP port for to serve. (port <= 0 will disable this connector)
--httpsPort            HTTPS port to serve.  (port <= 0 will disable this connector)
--sshPort              SSH Daemon port to serve.  (port <= 0 will disable this daemon)
--gitPort              Git Daemon port to serve.  (port <= 0 will disable this daemon)
--alias                Alias in keystore of SSL cert to use for https serving
--storePassword        Password for SSL (https) keystore.
--shutdownPort         Port for Shutdown Monitor to listen on. (port <= 0 will disable this monitor)
--dailyLogFile         Redirect logging to a rolling, daily log file instead of stdout
--tempFolder           Folder for server to extract built-in webapp


java -jar gitblit.jar --userService c:/myrealm.config --storePassword something --baseFolder c:/data

Overriding Gitblit GO's Log4j Configuration

You can override Gitblit GO's default Log4j configuration with a command-line parameter to the JVM.

java -Dlog4j.configuration=file:///home/james/ -jar gitblit.jar <optional_gitblit_args>

You can not use override the default log4j configuration AND specify the --dailyLogFile parameter. For reference, here is Gitblit's default Log4j configuration. It includes some file appenders that are disabled by default.