How to Self-Host Gitea or Forgejo for Personal and Team Git Hosting

Overview

This article gives you a durable framework for gitea self hosting and forgejo self hosting rather than a version-specific walkthrough that ages quickly. That matters because the real decision is usually not just “which app is better,” but “which app fits the way I work, the way my team collaborates, and the way I maintain servers.”

Both Gitea and Forgejo are widely considered strong self hosted GitHub alternative options for people who want control, privacy, and a smaller operational footprint. They are especially appealing for homelabs, developer VPS deployments, internal tools stacks, and privacy-conscious teams that do not need every enterprise platform feature.

At a high level, both platforms are a good fit when you want:

• Private Git hosting under your own domain
• Repository browsing, pull or merge workflows, and issue tracking in one place
• User and organization management without a heavy enterprise stack
• Webhook support for CI, automation, and deployment pipelines
• A simple interface that developers can learn quickly
• A container-friendly deployment model for Docker-based self-hosting

The more useful question is where the differences matter in practice. In a gitea vs forgejo comparison, your decision often comes down to project direction, your comfort with community governance, your expectations for long-term maintenance, and whether you want to keep migration flexibility open. For many personal deployments, either one will work well. For teams, the better option is usually the one that fits your preferred update cadence, contributor expectations, and operational confidence.

Before you deploy anything, define the role of the service. Is this:

• A personal Git home for side projects?
• A backup remote for code you also mirror elsewhere?
• An internal team collaboration platform?
• A lightweight CI entry point with runners?
• A central developer hub tied into documentation, containers, and deploy hooks?

Your answer changes everything from storage layout to access control to backup requirements.

Checklist by scenario

Use the checklist below to match your deployment style to your real needs. This is where most self-hosting decisions go right or wrong.

Scenario 1: Personal projects and solo development

If you are running a small instance for yourself, simplicity should win.

• Choose a single VPS or home server with reliable disk storage.
• Use Docker Compose unless you already prefer another deployment pattern.
• Keep the stack minimal: app container, database if required by your preference, reverse proxy, and backups.
• Use a domain or subdomain dedicated to Git hosting, such as git.example.com.
• Enable HTTPS from day one.
• Create one admin account and avoid creating unnecessary local users.
• Turn off open registration unless you truly need it.
• Store repositories and attachments on persistent volumes.
• Back up both the database and repository data together.

This is the cleanest path for a self hosted git server. It stays easy to migrate later and does not lock you into a larger platform than you need.

Scenario 2: Small team Git hosting

For a team setup, access control and reliability matter more than shaving off one container.

• Decide whether users will authenticate locally or through an external identity provider.
• Define organizations, teams, and repository permissions before inviting users.
• Document branch protection rules and repository naming conventions.
• Plan where runners or CI agents will live if you need build automation.
• Set repository retention expectations for archived and inactive projects.
• Use SMTP or another notification method so users receive password resets and workflow alerts.
• Set up monitoring for disk usage, memory pressure, and container restarts.

If this instance will support active collaboration, treat it like a production internal service even if the user count is small. A calm, predictable setup is better than a feature-rich but fragile one.

Scenario 3: Docker-first homelab deployment

Many readers looking into docker compose self hosted apps want a predictable, reversible setup. Gitea and Forgejo fit that model well.

• Keep your Compose file in version control.
• Mount named volumes or bind mounts for repositories, app data, and database data.
• Use a reverse proxy you already understand, rather than introducing a new one just for this app.
• Place the service on an internal Docker network.
• Only expose ports through the reverse proxy layer where possible.
• Use environment variables or secrets management consistently.
• Pin image tags deliberately and avoid blind latest-tag updates.

If you need help deciding between orchestration layers or deployment panels, compare your options before adding more abstraction. A control panel can help, but it can also hide important details. For that decision, see Portainer vs Coolify vs CapRover: Which Self-Hosting Control Panel Fits Best?.

Scenario 4: Publicly reachable VPS deployment

For an internet-facing setup, security and DNS deserve more attention than the application itself.

• Start with a hardened server baseline.
• Use a non-root administrative workflow.
• Configure your firewall before exposing the service.
• Use fail2ban or equivalent controls if your environment supports it.
• Keep SSH access locked down with keys, not passwords.
• Verify DNS records, reverse proxy routing, and TLS renewal.
• Decide whether SSH Git access should be public, private, or disabled in favor of HTTPS.

If you are not confident in your base system, begin with How to Set Up a Secure Ubuntu Server for Self-Hosting and Self-Hosted DNS and Domain Setup Checklist for Apps on Your Own Server before you publish a Git service on the open internet.

Scenario 5: Remote access without broad exposure

Some teams do not want to expose their Git platform directly to the public web. In that case:

• Decide whether users will connect through VPN, private mesh networking, or a tunnel.
• Document how Git over HTTPS and any optional SSH access will work remotely.
• Test clone, fetch, push, and web login flows from outside your local network.
• Make sure your chosen access method supports team onboarding without too much friction.

For this pattern, compare private connectivity options in Cloudflare Tunnel vs Tailscale vs WireGuard for Secure Remote Access.

Scenario 6: Migration from another Git platform

If you are moving from GitHub, GitLab, or another internal system, do not focus only on repository import.

• List what needs to migrate: repositories, issues, pull requests, releases, webhooks, deploy keys, runners, and user accounts.
• Check whether historical metadata matters for your team.
• Plan how old clone URLs will be communicated or redirected.
• Identify which projects need zero-downtime cutover and which can pause briefly.
• Decide whether you will run both systems in parallel during transition.

Migration is usually where platform differences become real. Keep your deployment boring and your rollback path clear.

What to double-check

Before calling your deployment finished, review these items. They are the details most likely to cause trouble later.

1. Storage layout

Your repositories are the core asset, but not the only one. Double-check where the following live:

• Git repository data
• Application configuration
• SSH keys and host keys if applicable
• Attachments, avatars, and release assets
• Database files or external database data
• Action or runner-related artifacts if you enable them

If you cannot point to each of these clearly, your backup plan is not finished.

2. Backup and restore workflow

Many self-hosted app owners have backups; fewer have tested restores. For Git hosting, that distinction matters.

• Back up repositories and database state together.
• Keep at least one off-server backup target.
• Write down restore steps in plain language.
• Test recovery to a disposable environment.
• Confirm that repository permissions and metadata survive restore.

Use Self-Hosted Backup Strategy Checklist for Docker and VPS Servers as a companion reference.

3. Authentication and account recovery

Self-hosted Git platforms often start small, then become unexpectedly important. Double-check:

• Whether admin access depends on a single user account
• Whether email delivery works for password resets
• Whether two-factor authentication is enabled where appropriate
• Whether registration is disabled if the service is private
• Whether external authentication mappings are documented

Store credentials securely. If you need a place to keep service credentials and recovery codes, review Best Self-Hosted Password Managers Compared.

4. Reverse proxy and clone URLs

Web access may work even when Git operations are misconfigured. Validate:

• The visible base URL matches your public domain
• HTTPS clone URLs are correct
• SSH clone URLs are correct if enabled
• Proxy headers and forwarded protocol settings are passed correctly
• Large repository pushes do not fail because of proxy body limits or timeout settings

This sounds minor until a team starts using the service every day.

5. Runner and automation expectations

Modern Git hosting is often judged by what happens after a push, not just by repository browsing. If you plan to use runners or actions-like automation, double-check:

• Where runners are hosted
• How secrets are passed to jobs
• Whether jobs can reach internal services securely
• How resource limits prevent a single build from exhausting the server
• How runner updates are managed separately from app updates

For many small teams, separating the Git service from build execution is the safer long-term choice.

6. Observability

You do not need enterprise monitoring, but you do need early warning.

• Track disk space carefully, especially where repositories and artifacts live.
• Monitor memory and CPU trends on smaller VPS plans.
• Alert on container restart loops or failed health checks.
• Watch certificate expiry and backup job failures.

A lightweight monitoring stack is often enough. See Best Self-Hosted Monitoring Tools for Small Servers and Homelabs for options.

Common mistakes

This section is the short list of problems that make a good self hosted developer tools setup feel unreliable.

Assuming Git data alone is enough to restore the service

Repositories matter most, but issues, access control, webhooks, releases, and configuration often matter too. If the platform is used for team work, a repo-only backup is incomplete.

Exposing the app too broadly

Not every service needs to be public. If only a small team uses the platform, private access over VPN or a controlled tunnel may be more appropriate than direct exposure.

Using unstable update habits

Frequent untested updates, ad hoc image pulls, and undocumented config changes create more downtime than the software itself. Use planned maintenance windows and keep notes on what changed.

Overcomplicating the first deployment

It is tempting to add SSO, object storage, multiple runners, and a custom mail flow on day one. For most teams, the right first version is simpler: working backups, a stable domain, good permissions, and one clear update process.

Ignoring SSH strategy

Decide early whether users will push over HTTPS, SSH, or both. This affects firewall rules, onboarding, key management, and user documentation.

Skipping migration drills

One of the benefits of Gitea or Forgejo is that they can remain relatively portable. Protect that advantage by keeping your deployment understandable enough that you can move it to a new VPS or host if needed.

Treating internal developer tools as low priority

Once a team depends on code hosting, it becomes critical infrastructure. Give it the same discipline you would give a file platform or project tracker. If you are building a broader internal stack, related tools like project management and file sync can be paired thoughtfully with your Git host. See Best Self-Hosted Project Management Tools Compared and Best Self-Hosted Google Drive Alternatives for File Sync and Sharing.

When to revisit

This is the practical maintenance section to return to whenever your workflows change. Revisit your Gitea or Forgejo setup when any of the following happens:

• Your instance shifts from personal use to team use
• You add runners, build automation, or deployment webhooks
• You move from a home server to a VPS, or from one VPS to another
• You change reverse proxy, DNS, or remote access methods
• You onboard external collaborators or contractors
• You start storing releases, packages, or larger binary assets
• Your backup target, retention policy, or restore process changes
• You are planning a new quarter, release cycle, or seasonal maintenance window

When you revisit, use this short action list:

1. Confirm who the platform serves now: just you, a small team, or a wider organization.
2. Review whether Gitea or Forgejo still aligns with your governance and maintenance preferences.
3. Audit clone URLs, domain settings, TLS, and remote access paths.
4. Test one real restore of the service into a temporary environment.
5. Check runner isolation, secrets handling, and resource controls.
6. Review admin accounts, disabled users, and authentication methods.
7. Document any customizations that would matter during migration.
8. Plan your next update window instead of updating reactively.

If you approach the topic this way, the choice between Gitea and Forgejo stays manageable. Both can be excellent tools. The better result usually comes not from picking the “perfect” platform, but from deploying one carefully, documenting it well, and revisiting it whenever your workflows or infrastructure change.