Gitea

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Gitea. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of t3.medium or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, then create or select a security group that allows inbound port 22 from your management network and inbound ports 80 and 443 from the networks your users use. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialization takes under a minute after the instance state becomes Running and the status checks pass.

Run the following command to launch an instance from the SecureAnyCloud Gitea Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID and <security-group-id> with a security group that opens ports 22, 80 and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.medium \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=gitea-01}]'

On success, the command prints a JSON document. Note the instance ID. Once the instance is running, retrieve its public address with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from Step 2. The SSH login user depends on the operating system of the AMI variant you launched.

AMI variant: Gitea 1.26 on Ubuntu 24.04. SSH login user: ubuntu.

The first-boot service runs before the SSH daemon is ready, so the credentials file is always in place when you first log in.

ssh <login-user>@<public-ip>
sudo cat /root/gitea-credentials.txt

The plain text file contains the Gitea URL, the administrator username (admin) and the password. From the same SSH session, confirm that the deployment is healthy by calling the open health endpoint:

curl -fsS http://127.0.0.1/api/healthz

{"status":"pass","description":"Gitea",...}

A "pass" status confirms that the full stack (nginx, the Gitea server and PostgreSQL) is serving.

Open a web browser and go to http://<public-ip>/. Gitea shows its sign-in page. Enter the username admin and the password from /root/gitea-credentials.txt, then select Sign In.

The Gitea sign-in page, with the per-instance administrator login created on first boot.

After you sign in, Gitea opens the dashboard. It shows your activity feed, your repositories and the contribution graph. The top bar links to Issues, Pull Requests, Milestones and Explore, and the + menu creates new repositories, migrations and organizations.

The Gitea dashboard, with the activity feed, repositories and contribution graph.

Select +, then New Repository. Enter a name and create the repository. Each repository includes code browsing, issues, pull requests, releases, packages, a wiki and Actions (built-in CI).

A Gitea repository, with code, README, issues, pull requests, actions and packages.

Push an existing local repository to Gitea over HTTPS:

git remote add origin http://<public-ip>/admin/<repo-name>.git
git push -u origin main

To push over SSH, add your public key under Settings -> SSH / GPG Keys in the web interface. Then use the SSH remote git@<public-ip>:admin/<repo-name>.git.

Open Site Administration from the avatar menu to add users and organizations. Open registration is disabled by default, so create accounts here or re-enable registration in the configuration.

Every action in the web app is also available through the REST API at http://<public-ip>/api/v1/. Generate a token under Settings -> Applications, then call the API with an Authorization: token <token> header. The interactive API docs (Swagger) are served at http://<public-ip>/api/swagger.

Serve Gitea over HTTPS in production so that logins and Git operations cannot be intercepted. The image ships with nginx, which certbot can configure automatically.

Before you start, create a DNS record that points your fully qualified domain name at the instance's public IP address. Then run:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d git.your-domain.example \
  --non-interactive --agree-tos -m you@your-domain.example \
  --redirect

When certbot finishes, set the root URL so that generated links and clone URLs are correct. Then restart Gitea:

sudo sed -i 's|^ROOT_URL = .*|ROOT_URL = https://git.your-domain.example/|' /etc/gitea/app.ini
sudo systemctl restart gitea

Gitea keeps its metadata (users, repositories, issues and settings) in PostgreSQL, and the Git repositories themselves under /var/lib/gitea/repositories. Back up both regularly:

sudo -u postgres pg_dump gitea > <backup-dir>/gitea-db-$(date +%F).sql
sudo tar czf <backup-dir>/gitea-repos-$(date +%F).tgz -C /var/lib/gitea repositories data

Gitea also has a built-in dump command that bundles everything into one archive: sudo -u git GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea dump -c /etc/gitea/app.ini. Ship the archives to an Amazon S3 bucket or another object store.

Because the database and the repositories are each on their own EBS volume, you can also take coordinated EBS snapshots. To upgrade Gitea, replace /usr/local/bin/gitea with a newer release and restart the service. Migrations run automatically on start. See https://docs.gitea.com/.

As your usage grows, you can:

• Move PostgreSQL to Amazon RDS for PostgreSQL and update the [database] section of /etc/gitea/app.ini
• Put the web tier behind an Application Load Balancer if you need high availability
• Enable Gitea Actions for built-in CI/CD and register runners for your build workloads

Each of these is documented in the official Gitea documentation at https://docs.gitea.com/.