Git Forge

Offshore Gitea Hosting

Your own Git forge with issues, pull requests, actions and packages, on an offshore server you administer.

Your source code is the one asset you most want to keep control of, and on a commercial forge it lives under someone else’s terms of service, jurisdiction and takedown process. Gitea gives you the same workflow on your own server. Choose the location and resources for your forge, and review the service terms that apply to your project.

What you get

  • The full workflow: issues, pull requests, actions and a package registry
  • Familiar to anyone who uses GitHub, with no seat pricing
  • Resources sized for your forge, including repositories, packages and concurrent activity
  • Offshore, DMCA ignored, no KYC, paid in crypto

Get it running

Pick a small VPS

Choose capacity for repositories, LFS objects, packages and concurrent users. Build runners add their own resource requirements; include them separately when planning the server.

Install it in one click

Install Gitea from the catalog with the hostname you will keep. That hostname becomes the base for clone URLs, webhook callbacks and OAuth redirects, so it is not a casual choice.

Claim the admin account

Set the admin user and password during the install so the instance comes up already configured, rather than dropping into an open setup wizard.

Close registration and start pushing

Once your account exists, turn registration off so only admins can create users. Then push your repositories and wire up auto-deploy on git push.

The first account to register becomes the admin

On a fresh install, self-registration is open so you can create that first account, and that first signup gets administrator rights. On a public hostname, whoever gets there first wins. Set the admin credentials during the install, or register immediately and then disable registration.

A forge holds more than code

Repositories accumulate secrets in old commits, CI variables, deploy keys and package tokens. Keep it patched, review who has access, and never rely on a repository being private as your only protection for a credential. If something leaked into history, rotate it rather than deleting the file.

Pair it with a Tor address

Gitea can publish a Tor v3 .onion address for access through Tor. A second address does not disable the public web or SSH endpoints. Review the intended access paths, exposed ports and firewall rules before treating the forge as reachable only through Tor. See how to publish a Tor .onion site.

Protect the whole forge

Git clones do not contain the complete forge. Include the database, repositories, configuration and any attachments, packages or LFS data you use. Follow Gitea’s backup procedure for your installed version: its documentation requires the service to be stopped for a consistent backup.

The integrated Impreza app backup currently requires a running deployment. Do not treat that file copy as a replacement for Gitea’s consistent backup procedure. Keep a tested native recovery set. For a migration, verify repository access, issues, pull requests, SSH/HTTPS clone URLs, webhooks and runners before enabling production traffic and jobs.

Diagnose the forge and delegate platform access

Use app inspection and supported Gitea CLI operations to investigate the deployment. Discover what the integration exposes before selecting a command. CLI runs require a running app and manage permission; collect their results and verify the affected forge function after a change.

For an assistant working through Impreza MCP, restrict delegated access to the intended task. Impreza deployment permissions and Gitea repository permissions are separate. A limited platform credential does not create a Gitea user, narrow a repository token or replace the forge’s own access controls.

Check runner and deployment boundaries

Keep repository access, runner credentials and delegated app access separate. Review which repositories may start jobs and which credentials those jobs receive before enabling automation.

For an app deployed from the forge, follow private Git deployment and verify the supported authentication method. A working clone does not establish that a branch preview can use the same private credentials. Keep the existing forge recovery plan alongside the app deployment plan.

Start now

Spin up an offshore VPS and install Gitea from the catalog, or read the documentation.

Ready to build privacy-first?

No KYC, no email required, crypto payment. Deploy an offshore server in minutes, or do it all by chat with the Impreza agent.