Host Gitea on Google Cloud in Minimal Ubuntu LTS (Example)

In over ~~one~~ two years hosting Gitea on Google Cloud, I have enjoyed the self-hosted Git service.

Creating an instance, setting it up, and securing the service was an amazing adventure. Enhancing the instance was, well, tricky but rewarding. Gitea itself is, indeed, (arguably!) painless: I have only encountered two issues, issues which I think even an enthusiast can fix with a little knowledge of SQLite3.

What follows is documentation of how I got Gitea up and running on Google Cloud. Hopefully, it can help others who want to host Gitea on Google Cloud, too. Perhaps, one could even adapt my work to host Gitea with other cloud providers.

Enjoy!

Part I: Create an Instance
Part II: Set Up the Instance
Part III: Additional Measures to Secure Gitea
Parts IV-VI: Enhance the Instance
Part VII: Upgrading Packages, Collections and Ubuntu, and Retesting Functionality
Part VIII: Testing
Part IX: Maintenance
Part X: Troubleshooting
Part XI: Privacy
Part XII: Options

Part I: Create an Instance

Let's get some formalities squared away...

Use Google's Chrome web browser for the best experience. Google Cloud webpages tend to time out or fail to load in Safari.

Now, let's work on creating the instance...

Compute Engine

Access It

Activate Cloud Shell

Click on the command prompt icon at the top-right corner of your web browser.

Click on the down arrow next to "Terminal," and select the auto-generated project ID.

Open Ports

Port 80

gcloud compute firewall-rules create default-allow-http \
	--direction INGRESS \
	--rules tcp:80 \
	--action ALLOW

Port 443

gcloud compute firewall-rules create default-allow-https \
	--direction INGRESS \
	--rules tcp:443 \
	--action ALLOW

Port 3000

gcloud compute firewall-rules create gitea-setup \
	--direction INGRESS \
	--rules tcp:3000 \
	--action ALLOW

~~Port 80 will redirect HTTP requests to the HTTPS address, and port 3000 will only be used to set up Gitea.~~
Ports 80 and 3000 are for accepting HTTP requests, and port 443 is for accepting HTTPS requests.
Caddy (Part II) will redirect requests on port 80 to port 443.
We will use port 3000 to set up Gitea and a reverse proxy (Part II) and to perform maintenance periodically (Part IX).

Create an Instance

Check for the latest release of Minimal Ubuntu LTS

gcloud compute images list \
  --filter ubuntu-minimal

Example:

NAME: ubuntu-minimal-2204-jammy-v20220928
PROJECT: ubuntu-os-cloud
FAMILY: ubuntu-minimal-2204-lts
DEPRECATED:
STATUS: READY

Create the instance

gcloud compute instances create gitea \
	--machine-type e2-small \
	--image ubuntu-minimal-2204-jammy-v20220928 \
	--image-project ubuntu-os-cloud \
	--scopes compute-rw,cloud-platform \
	--tags http-server,https-server \
	--shielded-secure-boot \
	--zone us-west1-b

e2-micro could also work. See Gitea system requirements 🔗.
Additional machine types: https://cloud.google.com/compute/all-pricing 🔗
Additional zones (and regions): https://cloud.google.com/compute/docs/regions-zones 🔗

Reserve the external IP address

gcloud compute addresses create gitea-address \
	--addresses 34.168.233.62 \
	--region us-west1

Cloud Domains

https://console.cloud.google.com/net-services/domains/registrations/list 🔗

Register mydomain.dev (or any domain that ~~equally~~ requires an SSL certificate)

Cloud DNS

https://console.cloud.google.com/net-services/dns/ 🔗

Click on the zone name corresponding to the registered domain, and add a Type A DNS record

TTL: 360 minutes
IPv4 Address: 34.168.233.62

Back to the Compute Engine

Reconnect to Cloud Shell

Back Up the Instance

Create a Snapshot

gcloud compute snapshots create snapshot-1 \
	--project myproject \
	--source-disk gitea \
	--description "created instance" \
	--source-disk-zone us-west1-b \
	--storage-location us

If you ever need to restore it, go to https://console.cloud.google.com/compute/instances 🔗.
Stop the instance; edit it by replacing its boot disk with the snapshot; and re-start the instance.

In fact, trying that now might be a good idea; learn now to mitigate any potential downtime later.

Part II: Set Up the Instance

The instance is created. Now, let's work on setting up the instance...

Compute Engine (Continued)

Connect to the Instance

https://console.cloud.google.com/compute/instances 🔗

Click on "SSH," and unblock the pop-up window. (You may have to reclick on "SSH.")

Check and Upgrade Packages

Check for the latest packages

sudo apt update

Upgrade them

sudo apt upgrade

If asked to reboot, run: sudo reboot.
Wait a moment, then retry connecting to the instance.

Install and Set Up Packages

Nano

Install a command line text editor

sudo apt install nano

We will use nano to set up packages. Feel free to see an overview of nano's shortcuts 🔗.

Caddy

Install a web server

https://caddyserver.com/docs/install#debian-ubuntu-raspbian 🔗

We will use caddy to obtain the required SSL certificate (Part I) and redirect the HTTP requests to the HTTPS address (Part I).

Set up the web server

sudo nano /etc/caddy/Caddyfile

Input:

mydomain.dev {
	# root * /usr/share/caddy
	# file_server
	reverse_proxy localhost:3000
}

~~Restart~~ Reload the web server

sudo systemctl reload caddy

Gitea

Install the Git service

https://gitlab.com/packaging/gitea/ 🔗

Run the last command with sudo. That is, sudo systemctl enable --now gitea
If you prefer installing Gitea manually, consult https://docs.gitea.io/en-us/install-from-binary/ 🔗
Gitea is available as a snap package, unfortunately you cannot modify the logo, home page or theme.

Set up the service

http://34.168.233.62:3000 🔗

Database Type: SQLite3
Server Domain: mydomain.dev
Gitea Base URL: https://mydomain.dev/

Email Settings

SMTP Host: smtp.gmail.com
SMTP Port: 465
Send Email As: example@gmail.com
SMTP Username: example@gmail.com
SMTP Password: ***
✓ Enable email notifications

Port 465 uses recommended Implicit TLS. See https://docs.gitea.io/en-us/email-setup/ 🔗
For the SMTP Password, use an App Password 🔗. This requires two-step verification.

Server and Third-Party Service Settings

✗ Enable OpenID Sign-In
✓ Disable Self-Registration

Administrator Account Settings

Administrator Username: john.doe
Password: ***
Confirm Password: ***
Email Address: example@gmail.com

Please use a strong password. Administrator email address can be different than SMTP username.

Test Caddy and Gitea

Check https://mydomain.dev 🔗

You may have to reload the web browser tab.
Caution: Do NOT log into mydomain.dev. The link is purely an example. Use your own domain.

Check email notifications

Sign In > Site Administration > Configuration > Send Testing Email

For creating additional user accounts, see Part XI.

Back to Cloud Shell

Create another snapshot...

Part III: Additional Measures to Secure Gitea

Enabling two-step verification, registering a domain that requires an SSL certificate, disabling OpenID sign-in, disabling self-registration, and using a strong administrator password help secure Gitea by restricting access to it.

However, we can do better...

Compute Engine (Continued)

Close Public Access to Port 3000

Reconnect to Cloud Shell

gcloud compute firewall-rules delete gitea-setup

Block Brute Force Attacks

Back to the SSH browser window

Enable logs

sudo nano /etc/gitea/app.ini

Input:

[log]
MODE = file

Restart the service

sudo systemctl restart gitea

Check for logs

sudo cat /var/lib/gitea/log/gitea.log

Time stamps use Coordinated Universal Time.

Install iptables

sudo apt install iptables

Install crowdsec

https://docs.crowdsec.net/docs/getting_started/install_crowdsec 🔗

Run the installation commands with sudo.

Enable Gitea support

sudo cscli collections install LePresidente/gitea

Parse Gitea logs

sudo nano /etc/crowdsec/acquis.yaml

Append:

filenames:
	- /var/lib/gitea/log/gitea.log
labels:
	type: gitea

Reload crowdsec

sudo systemctl reload crowdsec

Test it

Go to https://mydomain.dev 🔗. Create several failed authentication attempts until the website times out. Check sudo cscli decisions list, and you should see an ID (e.g., 9098) with your IP address banned. Either wait, or unban yourself: sudo cscli decisions delete --id 9098. Re-attempt to sign in.

Mitigate the Risk of Cross-Regional Outages

Reconnect to Cloud Shell

gcloud compute instances add-metadata gitea \
	--metadata VmDnsSetting=ZonalOnly

Back to the SSH browser window

sudo dhclient -v -r

Mitigate Snapshot Restoration Error

Periodically, if one attempts to restore a snapshot they will encounter an error message: 'Operation type [insert] failed with message "The zone...does not have enough resources available to fulfill the request. Try a different zone, or try again later.'

Reconnect to Cloud Shell

gcloud compute reservations create my-reservation \
	--zone=us-west1-b \
	--vm-count=1 \
	--machine-type=e2-small

Enable CAPTCHA

Back to the SSH browser window

Enable CAPTCHA

sudo nano /etc/gitea/app.ini

Input:

[service]
ENABLE_CAPTCHA = true 
REQUIRE_CAPTCHA_FOR_LOGIN = true

Restart the service

sudo systemctl restart gitea

Check https://mydomain.dev 🔗

The default CAPTCHA type is image. For additional CAPTCHA types, consult Gitea's Configuration Cheat Sheet 🔗

Checklist

Double-check that all of these measures have been taken...

2-Step verification (Google account)
stable image (Ubuntu Server LTS)
secure boot (enabled when created instance)
reserved external IP address (did after created instance)
HTTPS only (.dev domain requires an SSL certificate)
DNSSEC (Cloud DNS)
create snapshots (doing after completing each part)

We will schedule snapshots in Part VI.

We will redirect the domain for maintenance in Part IX.

In fact, I like that Ubuntu packages—except for Node.js (Part IV)—are relatively up-to-date, not bleeding edge / potentially unstable as on Arch Linux and not potentially outdated as on Debian or RHEL.

Keep in mind...

These measures are not exhaustive

You don't have to customize the logo, favicon, home page, theme and font (Parts IV-V)

Back to Cloud Shell

Create another snapshot...

Part IV: Enhance the Instance

PHEW! The instance is finally set up. Now, let's work on enhancing the instance...

Compute Engine (Continued)

Caution: The following instructions will not work with Gitea's snap package. See Part II for workable installation instructions.

Customize the Logo and Favicon

Back to the SSH browser window

Install Node.js

https://github.com/nodesource/distributions/blob/master/README.md 🔗

You will need the latest LTS version of Node.js, and look for "Node.js LTS"
The version of Node.js packaged with Ubuntu will be outdated.

The latest LTS version is available as a snap package, unfortunately when I installed it and ran make generate-images (below), I received an error: "Not implemented: HTMLCanvasElement.prototype.getContext" (see also issue #20157 🔗).

Prepare logo and favicon you want

Start with the logo. Export the PNG or JPG/JPEG image file to a SVG vector file. Then, scale the vector file to, say 48px x 48px, and export that. Name these vector files as logo.svg and favicon.svg, respectively.

Focus on the logo. Export the PNG or JPG/JPEG image file to a SVG vector file. Name the vector file as logo.svg. Then, duplicate the file and rename the duplicate as favicon.svg.

Suggestion: Use vector graphics software (e.g., Inkscape or Affinity Designer). For Inkscape, export image files to Inkscape SVG. For Affinity Designer, export image files to SVG (for export). Pixelmator Pro, an image editor, also works by exporting image files ~~converting areas in image files to shapes, grouping the shapes and exporting the group~~ to ~~simply~~ SVG.

Copy the logo and favicon you want from your local computer to the instance

Click on UPLOAD FILE at the top edge of the pop-up window.
Upload logo.svg and favicon.svg.

Install make

sudo apt install make

Clone Gitea's source repository

git clone https://github.com/go-gitea/gitea.git gitea-source

Checkout the latest release

cd gitea-source/ && \
git checkout f48fda8eefa4d47e335f01ac92366b9373950e0e

Locate the latest release by going to https://github.com/go-gitea/gitea/releases 🔗 (e.g., v1.17.3)
Copy its commit hash (e.g., f48fda8eefa4d47e335f01ac92366b9373950e0e)

Make sure that the Gitea service version (Part II) matches the release version. Otherwise, either upgrade the Gitea service (Part II) or checkout an earlier release.

Replace the logo and favicon in the cloned repository's assets directory with yours

mv logo.svg gitea-source/assets/ && \
mv favicon.svg gitea-source/assets/

Generate new images for your logo and favicon

cd gitea-source/ && \
make generate-images

You can ignore any "deprecated" warnings.

Be patient! Generating the images may take several minutes.

Locate the images

cd public/assets/img # old: public/img

Feel free to download a copy of logo.png for a maintenance page (see Part IX)

Click on DOWNLOAD FILE at the top edge of the pop-up window.

Other SVG export formats could work, as well, but with Inkscape SVG, SVG (for export) or SVG the make generate-images command will generate the images completely. With other export formats, the command may not do so, for example with Affinity Designer's SVG (digital - high quality) preset, the command did not generate logo.png and favicon.png.

Create an "img" directory in the working directory of your instance, and move everything into it

export WD=/var/lib/gitea/ && \
sudo mkdir -p $WD/custom/public/img/ && \
sudo mv * $WD/custom/public/img/

Restart the service

sudo systemctl restart gitea

Check https://mydomain.dev 🔗

If you are using either the Firefox or Chrome desktop web browser, the favicon should change.

However, if you are using the Safari desktop web browser, you will need to quit Safari, empty the favicon cache, and re-launch Safari.
To empty the favicon cache, launch Finder > Go > Go to Folder... > ~/Library/Safari/Favicon Cache/. Select all items in the folder, move them to the trash, and empty the trash.

Back to Cloud Shell

Create another snapshot...

Part V: Enhance the Instance (Cont.)

We have customized the logo and favicon. Now, let's customize the home page, theme, and font...

Compute Engine (Continued)

Caution: Again, the following instructions will not work with Gitea's snap package. See Part II for workable installation instructions.

Customize the Home Page

Back to the SSH browser window

Clone Gitea's source repository, and checkout the latest release

See Part IV.

Modify the "home" template

nano templates/home.tmpl

Leave only the logo, app name, and app description:

<!--
	<div class="ui stackable middle very relaxed page grid">
	...
	</div>
	<div class="ui stackable middle very relaxed page grid">
	...
	</div>
-->

Create a "templates" directory in the working directory of your instance, and move the "home" template into it

export WD=/var/lib/gitea/ && \
sudo mkdir $WD/custom/templates/ && \
sudo mv templates/home.tmpl $WD/custom/templates/

Restart the service

sudo systemctl restart gitea

Check https://mydomain.dev 🔗

Customize the Theme

Select one from Awesome Gitea 🔗 (e.g., Red Silver, or a fork of it)

Clone its repository

git clone https://github.com/iamdoubz/Gitea-Red-Silver.git

Navigate to the public/css directory

cd Gitea-Red-Silver/public/css

You can ignore the public/img directory, unless you want to overwrite any customized logo and favicon.

Create an "css" directory in the working directory of your instance, and move the CSS file into it

export WD=/var/lib/gitea/ && \
sudo mkdir -p $WD/custom/public/css/ && \
sudo mv theme-redsilver.css $WD/custom/public/css/

As stated in the README, make the theme selectable, and make it the default

sudo nano /etc/gitea/app.ini

Input:

[ui]
THEMES = auto,gitea,arc-green,redsilver
DEFAULT_THEME = redsilver

You can also remove the original theme color by inputting: THEME_COLOR_META_TAG = none
Otherwise, when you scroll down or up, areas above or below each webpage will still be colored green.

Restart the service

sudo systemctl restart gitea

Check https://mydomain.dev 🔗

Sign In > Settings > Appearance > redsilver > Update Theme

Customize the Font

Back to the SSH browser window

Clone Gitea's source repository, and checkout the latest release

See Part IV.

Modify the "head_style" template

nano templates/base/head_style.tmpl

Append a link(s) to the stylesheet

Example with Comic Neue:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Comic+Neue:ital,wght@0,300;0,400;0,700;1,300;1,400;1,700&display=swap" rel="stylesheet">

Source: https://fonts.google.com/specimen/Comic+Neue 🔗

Set --fonts-proportional

Example with Comic Neue (continued):

<style>
    :root {
        --fonts-proportional: "Comic Neue", cursive, -apple-system, "Segoe UI", system-ui, Roboto, "Helvetica Neue", Arial !important;
    }
</style>

To change the monospaced font, append a link(s) to the stylesheet, then set --fonts-monospace

Example with Comic Mono:
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/comic-mono@0.0.1/index.css">
<style>
    :root {
        --fonts-monospace: "Comic Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace, var(--fonts-emoji) !important;
    }
</style>
Source: https://github.com/dtinth/comic-mono-font 🔗

Create a "templates" directory in the working directory of your instance, and move the "head_style" template into it

export WD=/var/lib/gitea/ && \
sudo mkdir $WD/custom/templates/base/ && \
sudo mv templates/base/head_style.tmpl $WD/custom/templates/base/

Restart the service

sudo systemctl restart gitea

Check https://mydomain.dev 🔗

Custom fonts will display automatically.

Back to Cloud Shell

Create another snapshot...

Part VI: Enhance the Instance (Cont.)

We have customized the home page, theme, and font. Now, let's apply finishing touches...

Compute Engine (Continued)

Schedule Snapshots

Back to Cloud Shell

Create snapshot schedule

gcloud compute resource-policies create snapshot-schedule gitea-snapshots \
    --project myproject \
    --region us-west1 \
    --max-retention-days 14 \
    --on-source-disk-delete keep-auto-snapshots \
    --daily-schedule \
    --start-time 18:00 \
    --storage-location us \
    --description "regular and automatic back up"

Start time is in Coordinated Universal Time (UTC).

18:00 UTC is late morning in California.

Attach the schedule to the instance

gcloud compute disks add-resource-policies gitea \
    --resource-policies gitea-snapshots \
    --zone us-west1-b

Snapshots make Gitea's backup and restore commands 🔗 redundant. I am grateful for this, as well, because for me the backup command never completely worked (e.g., avatars and repo-avatars were never backed up).

Part VII: Upgrading Packages, Collections and Ubuntu, and Retesting Functionality

We have applied finishing touches. Now, let's discuss additional resources...

Compute Engine (Continued)

Upgrading Nano, Caddy, Gitea, Iptables, Crowdsec, Crowdsec Collections, Node.js, Make, etc.

Back to the SSH browser window

sudo cscli collections upgrade --all # do first, otherwise may encounter broken dependencies
sudo systemctl reload crowdsec # same
sudo apt update
sudo apt upgrade

If asked to reboot, run: sudo reboot.
Wait a moment, then retry connecting to the instance.

Excluding Ubuntu Packages

Useful, if you want to skip one newer package version:
sudo apt-mark hold [package]

To re-commence upgrades:
sudo apt-mark unhold [package]

Upgrading Ubuntu Releases

Not for Ubuntu LTS point releases!

Back to Cloud Shell

Open port 1022

gcloud compute firewall-rules create recovery \
	--direction INGRESS \
	--rules tcp:1022 \
	--action ALLOW

Back to the SSH browser window

do-release-upgrade

Back to Cloud Shell

Close port 1022

gcloud compute firewall-rules delete recovery

After upgrading any packages, collections or the operating system, retest functionality...

Retesting the Domain

Check https://mydomain.dev 🔗

Retesting Brute Force Protection

Back to the SSH browser window

Reset Crowdsec's metrics

sudo systemctl reload crowdsec

Create a failed authentication attempt at https://mydomain.dev 🔗

Check Crowdsec's metrics

sudo cscli metrics

"gitea-logs" should be parsed

Except for two issues (Part IX), simply retesting the domain and brute force protection have worked for me, but your mileage may vary.

Part VIII: Testing

If you want to test changes, before performing maintenance (i.e., applying the changes)...

Compute Engine (Continued)

List the snapshots

gcloud compute snapshots list

Look for the latest one, for example:

NAME: gitea-us-west1-b-20230906181913-frig00od
DISK_SIZE_GB: 10
SRC_DISK: us-west1-b/disks/gitea
STATUS: READY

Copy its name, for example "gitea-us-west1-b-20230906181913-frig00od"

Create a new instance using the latest snapshot

gcloud compute instances create gitea-testing \
	--machine-type e2-small \
	--source-snapshot gitea-us-west1-b-20230906181913-frig00od \
	--scopes compute-rw,cloud-platform \
	--tags http-server,https-server \
	--shielded-secure-boot \
	--zone us-west1-b

If a newer snapshot is needed, create one manually (see end of Part I) and recreate the instance with it.

Connect to it over SSH (see Part II)

If testing requires web access, you can briefly re-open port 3000 (see Part I).

AS OF Gitea 1.20.5 🔗, to access the test instance via the web using port 3000 you will also need to reset the Server Domain and Gitea Base URL. Back to the SSH browser window, run sudo nano /etc/gitea/app.ini; change "DOMAIN" to localhost and "ROOT_URL" to http://localhost:3000/; then run sudo systemctl restart gitea.

Once testing is completed, reset and reload the web server, and, if testing required web access, check http://EXTERNAL_IP:3000 🔗

Once finished, stop and delete the instance with two simple commands: gcloud compute instances stop gitea-testing and gcloud compute instances delete gitea-testing (No need to revert the Server Domain and Gitea Base URL, since the test instance would be deleted.)

Part IX: Maintenance

If you want to perform maintenance (i.e., apply the changes)...

Compute Engine (Continued)

As for testing (see Part VIII), we will create a separate instance. However, unlike for testing, this new instance will be persistent; we will briefly and periodically redirect the domain to it for maintenance.

Redirect Gitea for Maintenance

Create a new instance, and reserve the external IP address (see Part I)

e2-micro should be sufficient.

Register a new domain for the (new) instance, and add a Type A DNS record (see Part I)

Remember to use the reserved external IP address for the DNS record.

Set up the instance (see Part II): Connect over SSH; check and upgrade packages; and install Nano and Caddy

However, set up the web server (Caddy) differently

sudo nano /etc/caddy/Caddyfile

Input:

mydomain2.dev {
	root * /var/www/html
	file_server
}

Create the "html" directory

sudo mkdir -p /var/www/html

Create an HTML file in it

sudo nano /var/www/html/index.html

Input:

<!DOCTYPE html>
<html>
  <head>
    <title>
      Domain Not Available
    </title>
    <style>
      body {
        font-family: -apple-system, "Segoe UI", system-ui, "Roboto", "Helvetica Neue", "Arial";
        text-align: center;
        padding: 20% 0%;
      }
    </style>
  </head>
  <body>
    <img src="logo.png" width="100">
    <h1>
      Domain
    </h1>
    <p>
      Undergoing maintenance. Check <u><a href="https://mydomain.dev">mydomain.dev</a></u> later.
    </p>
  </body>
</html>

Padding aligns text vertically.
You can upload logo.png from Part IV or use an emoji; then, move it into the "html" directory: sudo mv logo.png /var/www/html/ (example)

Reload Caddy

sudo systemctl reload caddy

Redirect Gitea

Connect to the original instance over SSH

Modify the web server

sudo nano /etc/caddy/Caddyfile

Input:

mydomain.dev {
	redir https://mydomain2.dev temporary
	# root * /usr/share/caddy
	# file_server
	# reverse_proxy localhost:3000
}

Reload the web server

sudo systemctl reload caddy

Check https://mydomain.dev 🔗

You should be redirected to the maintenance page.

Perform any maintenance.

If doing so requires web access, you can briefly re-open port 3000 (see Part I). Just be sure to temporarily reset the Server Domain and Gitea Base URL (see Part VIII).

Once maintenance is completed, revert the Server Domain and Gitea Base URL, reset and reload the web server, and check https://mydomain.dev 🔗

Once finished, you can also shutdown the new instance with a simple command: gcloud compute instances stop gitea-maintenance, until you want to perform maintenance again Alternatively, you can redirect the maintenance page to Gitea: Connect to the new instance over SSH; modify the web server; under mydomain2.dev, input: redir https://mydomain.dev temporary; and reload the web server. (no sense in running a server that is not being used; run gcloud compute instances start gitea-maintenance to restart the instance)

Lastly, create one snapshot of the new instance. (Since the new instance is static, one should be sufficient.)

Part X: Troubleshooting

If you run into any issues...

Compute Engine (Continued)

Troubleshooting the Domain

Back to the SSH browser window

Check Gitea

sudo systemctl status gitea --no-pager --full

If the problem(s) exists here, consult the example below. (I will add additional examples, if any new problems arise.)

Example: "UNIQUE constraint failed: webauthn_credential.lower_name, webauthn_credential.user_id"

Let's say the lower_name = yubikey (and user_id = 21)

SOLUTION

Install sqlite3

sudo apt install sqlite3

Change user

sudo su gitea

Edit the database

sqlite3 /var/lib/gitea/data/gitea.db

Remove the row in the database with that lower_name (and user_id)

SELECT lower_name FROM webauthn_credential;

DELETE FROM webauthn_credential
WHERE lower_name = yubikey;

You could also have used the user_id, but lower_name will delete both.

Exit the database

.quit

Otherwise, check to see if anyone submitted an issue for the problem(s): https://github.com/go-gitea/gitea/issues 🔗. Gitea support staff may reply to the issue. If no issue is submitted, you can either submit one yourself, join Gitea's Discord chat 🔗, or participate in their Discourse forum 🔗.

You can also check Gitea's logs

sudo cat /var/lib/gitea/log/gitea.log

If the problem(s) exists elsewhere, then check Caddy...

Check Caddy

sudo systemctl status caddy --no-pager --full

You can safely ignore any "context canceled" errors. See "Aborting with incomplete response" 🔗.

In over ~~one~~ two years hosting Gitea on Google Cloud, though, I have only encountered two issues, both of which involved Gitea and occurred after upgrading it (one required removing a webauthn_credential, and the other required a downgrade)...neither involved Caddy, nor Ubuntu, nor any other package. ~~(I just started using Crowdsec.)~~

Troubleshooting a Security Vulnerability

EXAMPLE

"gitattributes parsing integer overflow" 🔗

SOLUTION

Install software-properties-common

sudo apt install software-properties-common

Add Ubuntu Git Maintainers' Personal Package Archive (PPA)

sudo add-apt-repository ppa:git-core/ppa

Run

sudo apt update && \
sudo apt install git

Troubleshooting Images Not Loading and Being Logged Out

MP4 files do not load properly, and—for whatever reason—you will be logged out.

SOLUTION

Replace MP4 files with GIF files.

Part XI: Privacy

Protect users...

Compute Engine (Continued)

https://mydomain.dev 🔗

Hide Administrator Visibility and Activity

Administrator visibility ~~and activity~~ can reveal ~~users and their activity~~ them self

Administrator Account > Settings > Profile > User visibility: Private ~~- [x] Administrator Account > Settings > Profile > ✓ Hide the activity from the profile page~~ (redundant)

Hide Regular Users' Visibility and Activity

Regular users' visibility ~~and activity~~ can reveal themselves ~~and their activity~~

Administrator Account > Site Administration > User Accounts > Create/Edit User Account > User visibility: Private

Users who want to be discoverable by private users can use Limited visibility. ~~Just be sure you hide activity from your profile page.~~ (optional)
Users who want to be discoverable by ALL users (even external ones) can use Public visibility.

Users who want their repositories to be discoverable and forkable by private users must use Limited visibility and ~~make their repositories Public~~ add the private users as collaborators.
Users who want their repositories to be discoverable and forkable by ALL users (even external ones) must use Public visibility and make their repositories Public.

Disable Stars

Starring repositories can reveal users ~~and their activity~~

Edit Gitea's configuration file

sudo nano /etc/gitea/app.ini

Input:

[repository]
DISABLE_STARS = true

Restart Gitea

sudo systemctl restart gitea

Test Privacy Settings

Create a dummy user account(s).

Log into it to see what other users see.

~~#### Caution~~

~~Following other users can also reveal users and their activity~~

~~- [x] Caution users about following other users~~

~~(Fixed in Gitea 1.17.4. See also go-gitea/gitea#21849 🔗. Of course, followed users can still inadvertently reveal followers.)~~

Suggestion

ALL users enroll in Two-Factor Authentication

Part XII: Options

Quality of life improvements...

Compute Engine (Continued)

Autocompletion

Can help you remember commands and run commands more quickly

Back to the SSH browser window

Create and edit a file named .inputrc

nano $HOME/.inputrc

Input exactly:

"\e[A": history-search-backward
"\e[B": history-search-forward

Start a new session

bash

Test autocompletion by typing some characters you previously typed, then pressing the up/down arrow key.

Repeat these steps for other users (e.g., gitea)

For the gitea user, first run the command: sudo su gitea
To return to your service account, run: exit

Enable Push to Create for Users

Can help if users already have a local repository set up

Edit Gitea's configuration file

sudo nano /etc/gitea/app.ini

Input:

[repository]
ENABLE_PUSH_CREATE_USER = true

Restart Gitea

sudo systemctl restart gitea

All done!

Extended Resources

Affinity Designer: https://affinity.serif.com/en-us/designer/ 🔗
Gitea Documentation: https://docs.gitea.io/en-us/ 🔗
Google Cloud Documentation: https://cloud.google.com/docs 🔗
Inkscape: https://inkscape.org 🔗
Minimal Ubuntu: https://canonical.com/blog/minimal-ubuntu-released 🔗

Future Research

Potentially hosting Gitea on Google Cloud in Minimal Ubuntu LTS on ARM

Known Issue

For Gitea 1.19.0+, Safari users who have multiple tabs open (e.g., Gitea repo in one tab and Gitea wiki in another) may be abruptly logged out. ~~Current workaround: Disable "Prevent cross-site tracking."~~ (Workaround failed.) Replacing MP4 files with GIF files partially helped, but users still eventually get logged out. Clearing browsing history temporarily works. (See issue #24176 🔗. ~~Mitigating issue by using Google Chrome.~~ Clicking on "Remember This Device" at login worked. ~~Now, a proper fix is coming: pull request #24330~~ Fixed in Gitea 1.19.4!)

Name		Name	Last commit message	Last commit date
Latest commit History 57 Commits
LICENSE		LICENSE
README.md		README.md

License

saegl5/gitea-gcloud-ubuntu

Folders and files

Latest commit

History

Repository files navigation

Host Gitea on Google Cloud in Minimal Ubuntu LTS (Example)

Table of Contents

Part I: Create an Instance

Enable 2-Step Verification

Create a New Project

Create a Billing Account, and Link It to the Project

Enable APIs

Compute Engine

Access It

Open Ports

Create an Instance

Cloud Domains

Cloud DNS

Back to the Compute Engine

Back Up the Instance

Part II: Set Up the Instance

Compute Engine (Continued)

Connect to the Instance

Check and Upgrade Packages

Install and Set Up Packages

Nano

Caddy

Gitea

Part III: Additional Measures to Secure Gitea

Compute Engine (Continued)

Close Public Access to Port 3000

Block Brute Force Attacks

Mitigate the Risk of Cross-Regional Outages

Mitigate Snapshot Restoration Error

Enable CAPTCHA

Checklist

Part IV: Enhance the Instance

Compute Engine (Continued)

Customize the Logo and Favicon

Part V: Enhance the Instance (Cont.)

Compute Engine (Continued)

Customize the Home Page

Customize the Theme

Customize the Font

Part VI: Enhance the Instance (Cont.)

Compute Engine (Continued)

Schedule Snapshots

Part VII: Upgrading Packages, Collections and Ubuntu, and Retesting Functionality

Compute Engine (Continued)

Upgrading Nano, Caddy, Gitea, Iptables, Crowdsec, Crowdsec Collections, Node.js, Make, etc.

Excluding Ubuntu Packages

Upgrading Ubuntu Releases

Retesting the Domain

Retesting Brute Force Protection

Part VIII: Testing

Compute Engine (Continued)

Part IX: Maintenance

Compute Engine (Continued)

Redirect Gitea for Maintenance

Part X: Troubleshooting

Compute Engine (Continued)

Troubleshooting the Domain

Check Gitea

Example: "UNIQUE constraint failed: webauthn_credential.lower_name, webauthn_credential.user_id"

Check Caddy

Troubleshooting a Security Vulnerability

Troubleshooting Images Not Loading and Being Logged Out

Part XI: Privacy

Compute Engine (Continued)

Hide Administrator Visibility and Activity

Hide Regular Users' Visibility and Activity

Disable Stars

Test Privacy Settings

Suggestion

Part XII: Options

Compute Engine (Continued)

Autocompletion

Enable Push to Create for Users

Extended Resources

Packages