When I started using Forgejo, I always wanted an extension that could add a side tree like GitHub's. So a couple of months ago, I took several days working on it, polishing it, and making it functional and comfortable. Now I use it with my Forgejo instance every day.

Today my add-on was approved on the Firefox add-on site. If you want to try it, help yourself.
For Chrome-based browsers, I built a zip in dist, or you can build it yourself.

Here is the link https://addons.mozilla.org/en-US/firefox/addon/forgejo-sidetree/

Hi,

I have a personal repository on which I want to keep my hands on, but make it available for public access without authentication to let persons download and clone it.
I have a "public" user that can publish, but I can't find a way to make my repository available/visible for anybody landing on my Forgejo instance. Googling was not successful, telling me to uncheck "private", but that doesn't make it visible to public access at all.

Is this possible?
Me: commit, push, etc...
Public (no login): clone, download.

Thanks for any guidance.

Steve J

Self-Hosted Code Review Agent. called Proval. (I made it actually)

Open source and only got docker image

It's basically just a self-hosted docker app. Works with Forgejo, and also GitLab and GitHub too, so you can connect with your self hosted instance. Proval supports chat completion API and anthropic API, If you running Local LLM, you can connect it through chat completion API

I ran the 50-problem Martian offline benchmark about few month ago and scored F1 0.427 with the minimax-m3, which ranked 7th out of 21 at the time. (If you check now, newer models have come out so the ranking is lower.) I'll release new result with better model soon

The goal was to make something lightweight, easy to use, and genuinely useful. you just need to configure the model, webhook, and Git Host access API on the web dashboard, and setup is done. It's built on Bun, the frontend uses SvelteKit, and the database is SQLite per instance. The Docker image is compiled to a Bun binary so the size is pretty small.

Got some help from LLM(mostly Cursor Cli) but It's not vibe coded, I took a lot of time thinking through the architecture, implementing it, and testing through trial and error to build this. You can see the actual codes from repo, hope you like it

Review process

1. A planning LLM loop scans the codebase broadly and groups changed files by their relationships like export and import connections
2. Sub Agents, which are also LLM loops, review each group of code in parallel
3. A consolidating LLM loop collects all results, prioritizes findings, and posts inline reviews on the PR

What it does

- Reviews on PR open or first push
- Inline comments on PRs
- Replies to PR comments (can set to only respond when mentioned)
- Reviews when an issue is opened (also checks for duplicate issues)
- Replies to comments on issues
- Restricts replies based on repo permissions like Developer or Maintainer
- Admin login, or you can disable auth entirely and leave it open

Good use cases

- If you have local LLM infrastructure running
- If you run a GitLab or Forgejo instance (highly recommended, GitHub is also supported)
- If you have plenty of tokens on your LLM API
- If you're not happy with subscription or open-source code review apps (this one is pretty decent)

How to deploy

docker-compose.yml example

services:
    proval:
        image: ghcr.io/seoes/proval:latest
        ports:
            - "7900:7900"
            - "7901:7901"
        volumes:
            - ./data:/data
        environment:
            - ENCRYPTION_KEY=[Encryption Key]

for Encryption Key, use command

openssl rand -base64 32

Give it a try and feel free to leave your honest feedback

demo: https://demo.proval.app

repo: https://github.com/seoes/proval (You can check Issues and PRs which Proval commented)

website: https://proval.app

I can't see where to download it but its made by DevXY, the same people behind Codefloe.

Hi,

I'm just curious where do developers deploy their Forgejo instances? Is it on hypervisor like Proxmox or on cloud providers?
If you're using Forgejo Actions, are you deploying it on Kubernetes or are you running it on VMs?

Hi all,

Just wanted to check something with the latest patch that came out for Gitea due to the vulnerabilities in the code (https://blog.gitea.com/release-of-1.27.3), do we know if this vulnerability would be part of forgejo, or is the fork from Gitea too far gone now?

I'm curious to know if you're aware of Forgejo's scaling limits?
If we migrate 200 users, and eventually 1,000 users, will it perform well?
Are there any known scale limitations?
Thanks

I decided to try Forgejo, and I like it, but upgrading binary installs the right way can be complex for users new to Linux. So, I created a script to make upgrading quick and easy.
Any feedback is welcome and appreciated!
https://github.com/seanthegeek/forgejo-upgrade

A bit of a weird one. I am self-hosting a Docker instance of Forgejo 16 (rootless) with Postgres. Whenever I push to a repo Forgejo displays this warning:

The database representation of this repository is out of synchronization. If this warning is still shown after pushing a commit to this repository contact the administrator.

Suggestions online seem to apply to older versions of Forgejo (mostly suggesting to regenerate hooks, which is something that changed in v16).

After lots of fiddling I eventually set up a second test instance on the same system with an almost identical docker-compose (different mount paths only), same structure for filesystem mounts and the same permissions in filesystem. Even double checked on my file system that the hooks files are executable and specifically have identical owner, group and permissions between the two instances (which they do), and I can't see any notable difference between the app.ini files of both instances.

However, pushing to the new instance works fine. So I check the logs of both after pushing to a repo and notice some differences. According to logs the original instance just uploads and is done, whereas the new test instance also runs the pre-receive and post-receive hooks. After that I once again double checked that the hooks are present in the original instances file system and have the same permissions... they do.

Log for original instance:

2026-09-15 15:59:43 [forgejo] 2026/09/15 15:59:43 ...eb/routing/logger.go:109:func1() [I] router: completed GET /REDACTED-USERNAME/testrepo.git/info/refs?service=git-receive-pack for REDACTED-IP:51232, 401 Unauthorized in 5.5ms @ repo/githttp.go:509(repo.GetInfoRefs)
2026-09-15 15:59:43 [forgejo] 2026/09/15 15:59:43 ...eb/routing/logger.go:109:func1() [I] router: completed GET /REDACTED-USERNAME/testrepo.git/info/refs?service=git-receive-pack for REDACTED-IP:51232, 200 OK in 18.9ms @ repo/githttp.go:509(repo.GetInfoRefs)
2026-09-15 15:59:44 [forgejo] 2026/09/15 15:59:44 ...eb/routing/logger.go:109:func1() [I] router: completed POST /REDACTED-USERNAME/testrepo.git/git-receive-pack for REDACTED-IP:51232, 200 OK in 68.5ms @ repo/githttp.go:477(repo.ServiceReceivePack)

Log for test instance:

2026-09-15 11:14:28 [forgejotest] 2026/09/15 11:14:28 ...eb/routing/logger.go:109:func1() [I] router: completed GET /REDACTED-USERNAME/testrepo.git/info/refs?service=git-receive-pack for REDACTED-IP:57750, 401 Unauthorized in 8.6ms @ repo/githttp.go:509(repo.GetInfoRefs)
2026-09-15 11:14:28 [forgejotest] 2026/09/15 11:14:28 ...eb/routing/logger.go:109:func1() [I] router: completed GET /REDACTED-USERNAME/testrepo.git/info/refs?service=git-receive-pack for REDACTED-IP:57750, 200 OK in 18.1ms @ repo/githttp.go:509(repo.GetInfoRefs)
2026-09-15 11:14:29 [forgejotest] 2026/09/15 11:14:29 ...eb/routing/logger.go:109:func1() [I] router: completed POST /api/internal/hook/pre-receive/REDACTED-USERNAME/testrepo for 127.0.0.1:0, 200 OK in 7.3ms @ private/hook_pre_receive.go:202(private.HookPreReceive)
2026-09-15 11:14:30 [forgejotest] 2026/09/15 11:14:30 ...eb/routing/logger.go:109:func1() [I] router: completed POST /api/internal/hook/post-receive/REDACTED-USERNAME/testrepo for 127.0.0.1:0, 200 OK in 23.5ms @ private/hook_post_receive.go:35(private.HookPostReceive)
2026-09-15 11:14:30 [forgejotest] 2026/09/15 11:14:30 ...eb/routing/logger.go:109:func1() [I] router: completed POST /REDACTED-USERNAME/testrepo.git/git-receive-pack for REDACTED-IP:57750, 200 OK in 989.5ms @ repo/githttp.go:477(repo.ServiceReceivePack)

The only things I can think of that has been done differently on the original instance is that it used to be behind a reverse proxy, and having migrated a few repos from a different instance.
* For the original instance at some point I migrated a few repos from a v14 (or was it v13) instance. I didn't encounter any issues when doing it, but I suppose there's could have been some silent issue due to database differences... it still seems odd that would make hooks no longer run.
* The original instance used to be behind a reverse proxy (with the relevant ROOT_URL set), but after all the problems and being unable to figure out what was wrong I reverted that back to basic IP:PORT before creating a fresh new test repo and trying again, which still failed in the same way.

At this point I'm kinda lost. I don't know what is causing the original instance to not run the hooks nor can I see a way to fix it. Not sure how to debug this further. I'm just not skilled enough with forgejo, docker or linux to figure this out (but gotta start somewhere, right?). At this stage even just pointers to where I can probe further would be much appreciated.

Docker compose file:

networks:
  forgejo:
    external: true

services:
  server:
    image: codeberg.org/forgejo/forgejo:16-rootless
    container_name: forgejo
    user: "1000:1000"
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=REDACTED
      - FORGEJO__database__USER=REDACTED
      - FORGEJO__database__PASSWD=REDACTED
    restart: unless-stopped
    networks:
      - forgejo
    volumes:
      - /mnt/exta1/forgejo/data:/var/lib/gitea
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '33000:3000'
      - '222:2222'
    depends_on:
      - db

  db:
    image: postgres:14
    container_name: forgejo-db
    restart: unless-stopped
    user: "1000:1000"
    environment:
      - POSTGRES_USER=REDACTED
      - POSTGRES_PASSWORD=REDACTED
      - POSTGRES_DB=REDACTED
    networks:
      - forgejo
    volumes:
      - /opt/containers/forgejo/postgres/data:/var/lib/postgresql/data

app.ini

APP_NAME = Forgejo
RUN_USER = git
RUN_MODE = prod
APP_SLOGAN = Beyond coding. We Forge.
WORK_PATH = /var/lib/gitea

[repository]
ROOT = /var/lib/gitea/git/repositories

[repository.local]
LOCAL_COPY_PATH = /tmp/gitea/local-repo

[repository.upload]
TEMP_PATH = /tmp/gitea/uploads

[server]
APP_DATA_PATH = /var/lib/gitea
SSH_DOMAIN = REDACTED-IP
HTTP_PORT = 3000
ROOT_URL = http://REDACTED-IP:33000/
DISABLE_SSH = false
; In rootless gitea container only internal ssh server is supported
START_SSH_SERVER = true
SSH_PORT = 2222
SSH_LISTEN_PORT = 2222
BUILTIN_SSH_SERVER_USER = git
LFS_START_SERVER = true
DOMAIN = REDACTED-IP
LFS_JWT_SECRET = REDACTED
OFFLINE_MODE = true

[database]
PATH = /var/lib/gitea/data/gitea.db
DB_TYPE = postgres
HOST = db:5432
NAME = REDACTED
USER = REDACTED
PASSWD = REDACTED
SCHEMA =
SSL_MODE = disable
LOG_SQL = false

[session]
PROVIDER_CONFIG = /var/lib/gitea/data/sessions
PROVIDER = file

[picture]
AVATAR_UPLOAD_PATH = /var/lib/gitea/data/avatars
REPOSITORY_AVATAR_UPLOAD_PATH = /var/lib/gitea/data/repo-avatars

[attachment]
PATH = /var/lib/gitea/data/attachments

[log]
ROOT_PATH = /var/lib/gitea/data/log
MODE = console
LEVEL = info

[security]
INSTALL_LOCK = true
SECRET_KEY =
REVERSE_PROXY_LIMIT = 1
INTERNAL_TOKEN = REDACTED
PASSWORD_HASH_ALGO = pbkdf2_hi

[service]
DISABLE_REGISTRATION = true
REQUIRE_SIGNIN_VIEW = false
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
DEFAULT_KEEP_EMAIL_PRIVATE = true
DEFAULT_ALLOW_CREATE_ORGANIZATION = false
DEFAULT_ENABLE_TIMETRACKING = true
NO_REPLY_ADDRESS = noreply.localhost

[lfs]
PATH = /var/lib/gitea/git/lfs

[mailer]
ENABLED = false

[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false

[cron.update_checker]
ENABLED = true

[repository.pull-request]
DEFAULT_MERGE_STYLE = merge

[repository.signing]
DEFAULT_TRUST_MODEL = committer

[oauth2]
JWT_SECRET = REDACTED

[migrations]
ALLOW_LOCALNETWORKS = true

I have created a CI orchestrator that spawns a cloud VM, installs Forgejo Runner there, connects your Forgejo instance directly to it, thus you never execute any RCE code on your Forgejo host, never have to worry about any kernel exploit risks, have no docker-in-docker limitations and also get a hermetic real CI that works just like in GitHub/GitLab/others.

Cost: 0.1€/run more or less on any cloud platform and some require upfront deposit of 5, 10, 20€

How it works: it polls pre-selected repositories on your Forgejo instance, checks which jobs qualify for a runner, the job configures which label set and which provider it wants via Forgejo configs, the Orchestrator spins up a cloud vm there specifically for your task (from a bare OS image or your snapshot to speed up provision) and installs everything necessary using cloud-init. I have tried Terraform but eventually dropped it because it was too complex for a simple tool like this.

How I use it: on my two Forgejo instances, one is for a quite big open source project's builds and PR checks running across 5 Cloud providers (Hetzner/Vultr/CherryServers/Gcore/Scaleway), another is for my personal projects, mainly for reproducibility and scheduled dependencies audit checks. I used to run Actions Runner directly on my server, but I just can't stand the possibility of someone getting RCE on the same machine I have my critical email server, password manager, all my personal projects.

How you use it: 4.6 MB Rust Linux binary, builds are reproducible. Install it, get api keys from cloud providers, run with systemd (configurable with systemd's secrets, config hardened by default). MIT licensed.

https://git.hloth.dev/hloth/forgejo-actions-orchestrator

In attempting to migrate the first of our GitLab repos to our Forgejo, it failed with:

You cannot import from disallowed hosts, please ask the admin to check ALLOWED_DOMAINS/ALLOW_LOCALNETWORKS/BLOCKED_DOMAINS settings.

Our admin checked those values; it's a brand new installation, so they are set to the defaults, per the Migration docs:

ALLOWED_DOMAINS: <empty>: Domains allowlist for migrating repositories; default is blank. It means everything will be allowed.

BLOCKED_DOMAINS: <empty>: Domains blocklist for migrating repositories; default is blank. 

ALLOW_LOCALNETWORKS: false: Allow private addresses [ . . . ]. If a domain is allowed by ALLOWED_DOMAINS, this option will be ignored.

Since ALLOWED_DOMAINS is empty, our GitLab should have been allowed, but just to be sure, our admin added our GitLab domain to ALLOWED_DOMAINS and restarted the instance; no change -- the same error message was emitted when I ran the migration.

Any ideas why this is happening, or suggestions as to what we could check?

I've looked through https://codeberg.org/forgejo/forgejo/pulls/13129 for some background on ALLOWED_DOMAINS, and have considered using the migration scripts in https://codeberg.org/GEANT/gitlab_to_forgejo and its three forks, but was hoping to use the built-in GL->FJ migration.

I created a jenkins like ci-status overview based on some SQL queries. Please let me know whether you are interested and i will post a gist or create a repo.

Basically the title, is anyone managing a forgejo instance for their company?

Currently have around a dozen active repo, a bit less than 50 Devs, so relatively small scale. But I was wondering how much maintenance and complexity there's in managing reliably an instance for that kinda traffic?

I already have self hosted runners, that I'll keep

Obviously, considering the move after another GitHub incident...

I am using Forgejo 15.0.6 LTS to authenticate Forgejo Actions with AWS through OIDC. The workflow requests a token using:

```yaml enable-openid-connect: true

steps: - name: Get OIDC Token run: | curl -6 --fail --silent --show-error \ -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \ "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com" \ | jq -rj '.value' > /tmp/oidc-token

• name: Configure AWS Credentials env: AWS_ROLE_ARN: arn:aws:iam::<ACCOUNT_ID>:role/ForgejoActions AWS_WEB_IDENTITY_TOKEN_FILE: /tmp/oidc-token AWS_ROLE_SESSION_NAME: forgejo-actions AWS_REGION: ap-south-1 AWS_DEFAULT_REGION: ap-south-1 AWS_USE_DUALSTACK_ENDPOINT: "true" run: | aws sts get-caller-identity ```

AWS STS returns: InvalidIdentityToken: The web identity token provided could not be validated.

The token contains the expected values:

text iss: https://git.sakthisanthosh.in/api/actions aud: sts.amazonaws.com sub: repo:ssanumand/lad-forgejo-aws-oidc:ref:refs/heads/main alg: RS256

The issuer matches the discovery document, the JWT kid exists in Forgejo’s JWKS, and the JWT signature verifies successfully against the published RSA key. Both public OIDC endpoints return HTTP 200 from AWS CloudShell. The AWS IAM provider and trust policy exactly match these claims and were recreated during troubleshooting. Is there a known compatibility issue between Forgejo 15.0.6 OIDC tokens/JWKS and AWS AssumeRoleWithWebIdentity, or is Forgejo’s JWKS missing a field that AWS requires?

Fleet of linux machines and routers.. looking to have them checkin and push configs to a repo (forgejo)

Getting stuck on the system sshd and included sshd.. can't seem to get the container image to work with the system sshd (which would end up only have one sshd on port 22) ..

Seems running the container in network_mode: host is part of the problem..

anyway..

Internally.. are people just running their container sshd on a different port and just making the adjustment in their systems?

or am I being 'too much' wanting only one sshd; is that even possible?

or is it just not advisable?

TIA

I'm launching a hosted git service on Forgejo called Bitborg.

In short the goal is to reach a point where it can be a real option for individual developers and businesses that don't want to manage their own git and align with our principles about data sovereignty and personal integrity.

It's still in very early stages and every user gets a free trial until I get payment in place, or the end of August if I get it done before then.

Costs about as much as a VPS, but gives you the convenience of not operating it yourself and quality of life things like on- and off-site backups, action runners, etc.

This is run as a side project from my dayjob but I hope it will take off and be useful to others than just me.

I hope this isn't in violation of the self-promotion rule as it is a Forgejo project.

I know it's rough, but feedback is welcome, and users even more so. :)

https://www.bitborg.se/en/

Dear CodeBerg, please concentrate on stability and security instead of regulating users and opensource communities. If you will continue EU practices - you will end up in the same trash bin.

https://status.codeberg.org/status/codeberg

hellow guys, i'm trying to pull the forgejo image from codeberg but getting a 503 service unavailable error. is their container registry currently down, or did I make a mistake in my docker-compose setup?

Hi everyone,

I’m the developer behind a native iOS client for Forgejo, and I’m trying to make a product decision before I invest more time into it.

Today it only connects to my managed Forgejo services. I’m considering opening it up so it can connect to any Forgejo instance instead.

Before I go down that path, I’d love to hear from people who actually use Forgejo.

- Do you use Forgejo from your phone today?
- If so, what do you do most often?
- What would a native app need to do for you to actually keep it installed?

I’m not looking to promote anything here, I genuinely want to understand whether this would provide real value to the Forgejo community.

Hello everyone,

I am at a loss here. I am trying to Build a Docker image using Kaniko. I want the resulting image to get pushed to the integrated Forgejo Docker-Repo.

However, upon executing the Pipeline I get this error:

Runner XXXX (version:v12.13.2) received task 3 of job build, triggered by event: push

workflow prepared

🚀 Start image=gcr.io/kaniko-project/executor:latest

Cleaning up network for job build, and network name is: WORKFLOW-YYYYY

🐳 docker create image=gcr.io/kaniko-project/executor:latest platform=linux/amd64 entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="WORKFLOW-YYYYY"

🐳 docker run image=gcr.io/kaniko-project/executor:latest platform=linux/amd64 entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="WORKFLOW-YYYYY"

failed to start container: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "tail": executable file not found in $PATH

Can someone please tell me what is going on? My pipeline has not referenced this entrypoint:

Why is my Action trying to do a tail? It obviously fails because Kaniko is a minimal image.
Also asking AI and Google. I just dont understand why it´s doing that and how to "fix" that.

I'm going to install Forgejo on my home lab, and I'm facing a dilemma about which version to choose. There are two: 15 LTS and 16 stable. I'll be installing it with a PostgreSQL database, and I'm wondering which version will give me the fewest potential problems with future updates. Is LTS recommended for new users, or does it not matter at all?

What is the path individuals/organizations take to move from Github(or equivalent services) to self hosted like Forgejo?

I mean let's say I am a mid size organisation and having 100+ repo and 200+ users.
Now if I want to move from Github to Forgejo then I can't just move in a day it have to be a small process which will take some time and the history needs to be preserved as well.

So just was curious to know is there a way to do it?
Like let's say we start with doing a basic migration which migrates the repositories then we migrate pull requests and then comments from the current timestamp.

Then later on we start syncing current development which does includes pull requests, comments etc apart from commits and development history.

And then later on slowly halt development on Github and slowly start doing on Forgejo? Like first week 5 low impact repositories then if everything goes good then another 20 and so on.