Repository visibility defaults may expose private projects unintentionally in Forgejo

Short answers first

1. Can Forgejo require explicit visibility selection during repository creation? No. Forgejo (inheriting Gitea's configuration model) has no setting that forces the creation form to require a deliberate click on a visibility option. The form always pre-selects a value derived from your defaults, so a user can click straight through and accidentally create a public repository.

2. How do template repositories handle visibility? Visibility is not blindly inherited from the source template. When you create a repository from a template, the creation form offers a visibility choice that defaults per your instance configuration — the template's content is copied, but the new repository's visibility is whatever the form says when you submit.

3. What prevents accidental public exposure? Since you can't mandate a choice, you change the default: set the default visibility to private in app.ini, and optionally restrict who may publish publicly at all. Details below.

The practical fix: make private the default

In app.ini, under the [repository] section:

[repository]
DEFAULT_PRIVATE = private
DEFAULT_PUSH_CREATE_PRIVATE = private

DEFAULT_PRIVATE accepts last (remember the user's previous choice), private, or public. Setting it to private means the creation form pre-selects private, so publishing publicly requires a deliberate change. DEFAULT_PUSH_CREATE_PRIVATE covers repositories created implicitly by pushing to a non-existent repo — an easy exposure path to overlook. Restart Forgejo after editing.

Reducing exposure further

Forgejo/Gitea support a limited visibility state: repositories and users hidden from anonymous visitors but visible to logged-in users. If your instance is team-internal, setting user or organization visibility to limited or private constrains what members can publish publicly — though note this affects user profiles too, not just repositories. Check your version's admin dashboard under the organization and user settings for the visibility field.

Verify on your instance

Option names and admin UI paths vary between Forgejo versions, so confirm against your deployed version's config cheat sheet. Concretely:

1. Grep your config: grep -A5 '\[repository\]' /path/to/app.ini and check both keys above.
2. Open the repository creation form in the web UI and observe which visibility option is pre-selected before submitting.
3. Create a throwaway repo from a template and confirm the result matches the form selection, not the template's own visibility.
4. Audit what already exists: DEFAULT_PRIVATE only affects new repositories. Use the admin dashboard's repository list filtered by public visibility to catch projects already exposed.

Assumptions and caveats

This reflects Forgejo's inherited Gitea behavior as generally documented; exact key names should be confirmed against your version. The core limitation stands: Forgejo offers safe defaults and visibility restrictions, but no mandatory explicit-selection step in the creation flow. If that hard requirement matters to you, the realistic options are the private default plus user/org visibility limits, or a policy enforced outside Forgejo (e.g., periodic audits via the API).