Gitea Woodpecker

Search the Azure Marketplace for Gitea + Woodpecker CI DevOps Stack, choose the plan, and create the VM.

In the networking step, attach a network security group (NSG) that allows inbound TCP 22 (SSH) from your management network. Also allow TCP 80 (Woodpecker UI) and TCP 3000 (Gitea) from the client networks that need them.

For production, put a TLS-terminating reverse proxy or Azure Application Gateway in front of ports 80 and 3000.

RG="devops-prod"; LOCATION="eastus"; VM_NAME="gitea-woodpecker-01" IMAGE_URN="sac1647283583153:gitea-woodpecker-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name devops-vnet --address-prefix 10.104.0.0/16 --subnet-name devops-subnet --subnet-prefix 10.104.1.0/24 az network nsg create -g "$RG" --name devops-nsg az network nsg rule create -g "$RG" --nsg-name devops-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name devops-nsg --name allow-woodpecker --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 80 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name devops-nsg --name allow-gitea --priority 120 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 3000 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:gitea-woodpecker-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name devops-vnet --subnet devops-subnet --nsg devops-nsg --public-ip-sku Standard

ssh azureuser@<vm-ip>

On first boot, woodpecker-firstboot.service generates a Gitea administrator password that is unique to your VM. It also generates fresh server secrets, an agent secret and an OAuth client secret. The login is written to a root-only file. No shared or default credentials ship in the image.

Read the file with sudo:

sudo cat /root/woodpecker-credentials.txt

The file records the Woodpecker URL, the Gitea URL, and the gitadmin username and password. Keep a copy somewhere safe.

Confirm that all four services are active:

systemctl is-active gitea.service woodpecker-server.service woodpecker-agent.service nginx.service

Check the Woodpecker health endpoint, which is open, and the bundled Gitea health endpoint through nginx:

curl -s -o /dev/null -w 'woodpecker healthz: %{http_code}\n' http://127.0.0.1/healthz
curl -s http://127.0.0.1:3000/api/healthz | head -c 40; echo

Confirm that the Gitea administrator login works. The first request returns 200 with credentials and the second returns 401 without them:

curl -s -o /dev/null -w 'with creds: %{http_code}\n' -u "gitadmin:<GITEA_ADMIN_PASSWORD>" http://127.0.0.1:3000/api/v1/user
curl -s -o /dev/null -w 'without creds: %{http_code}\n' http://127.0.0.1:3000/api/v1/user

Confirm that Woodpecker points at the bundled Gitea and that its /authorize endpoint redirects into the Gitea OAuth flow with the wired client id:

grep -E '^WOODPECKER_(HOST|GITEA_URL|GITEA_CLIENT)=' /etc/woodpecker/server.env curl -s -o /dev/null -w 'oauth redirect: %{redirect_url}\n' -m 10 http://127.0.0.1:8000/authorize | sed 's/&state=.*//'

Browse to http://<vm-ip>/. The Woodpecker sign-in page offers a single button that signs you in through the bundled Gitea forge.

Click the button and sign in with the gitadmin username and password from Step 4. Then click Authorize on the Gitea consent screen. You return to Woodpecker signed in. The bundled Gitea administrator is also the Woodpecker administrator.

Create a repository in the bundled Gitea at http://<vm-ip>:3000/ and add a .woodpecker.yml file to it. In Woodpecker, click Add repository, enable the repository, and push a commit.

Gitea's webhook triggers Woodpecker, and the agent runs each step in a Docker container. Here is a minimal pipeline:

steps: - name: smoke image: alpine:3.20 commands: - echo "hello from sac" - uname -sm

The run appears in Woodpecker with per-step logs and a green result when the container exits 0.

You can also run a pipeline locally against the Docker backend, without pushing, using the bundled CLI. This is handy for testing a .woodpecker.yml:

cat > /tmp/.woodpecker.yml <<'YAML' steps: - name: smoke image: alpine:3.20 commands: - echo "hello from sac" YAML cd /tmp && sudo WOODPECKER_BACKEND=docker woodpecker-cli exec --backend-engine docker .woodpecker.yml

To use an external GitHub, Gitea, Forgejo or GitLab forge instead of the bundled one, register an OAuth application on that forge.

Then edit /etc/woodpecker/server.env and set WOODPECKER_GITEA_URL (or the GitHub or GitLab equivalents), WOODPECKER_GITEA_CLIENT and WOODPECKER_GITEA_SECRET. Restart the server:

sudo systemctl restart woodpecker-server.service

• Encrypt web traffic. Terminate HTTPS in front of ports 80 and 3000 with Azure Application Gateway, a load balancer or your own reverse proxy. Alternatively, install a certificate with certbot on a public DNS name and front nginx.
• Backups. Back up /var/lib/woodpecker (Gitea repositories and both SQLite databases).
• Scaling. To run more pipeline steps in parallel, increase WOODPECKER_MAX_WORKFLOWS in /etc/woodpecker/agent.env or add more agents.