Do I need a domain name?

Yes. Gitea embeds its public URL in the clone links it displays, in webhook payloads, in OAuth2 callbacks and in package registry endpoints, so it has to know a stable address. Point an A record such as `git.example.com` at your VPS before deploying; HTTPS certificates are then issued and renewed automatically.

How do I clone and push over SSH?

The container exposes Git-over-SSH on port 2222 rather than the standard port 22, which stays reserved for administering the VPS itself. Add your public key in Gitea under Settings → SSH Keys, then use `git clone ssh://git@git.example.com:2222/team/api.git`. To drop the explicit port from every command, add a `Host git.example.com` block with `Port 2222` to your local `~/.ssh/config`.

Can I import my existing GitHub repositories?

Yes. New → Migration takes a GitHub, GitLab, Gitea or plain Git URL and imports the code with its full history; for GitHub and GitLab you can also bring over issues, pull requests, labels, milestones and releases by supplying an access token. You can also set up a pull mirror, which keeps a read-only copy continuously in sync with the upstream repository.

How do I run CI/CD pipelines?

Gitea Actions is enabled per repository and reads workflow files from `.github/workflows`, using the same YAML syntax as GitHub Actions — most simple pipelines run unchanged. Jobs execute on `act_runner` instances that you register against your Gitea URL, so build capacity is whatever hardware you give it: no minute quota, no shared queue. Actions from the GitHub marketplace are fetched by URL and many work as-is, but there is no compatibility guarantee for the more exotic ones.

How much RAM does Gitea need, and how do I back it up?

A team-sized instance is comfortable on 2 GB: Gitea idles on a few hundred megabytes and PostgreSQL uses the remainder. Everything that matters is in two Docker volumes — `gitea_data` (repositories, LFS objects, uploaded avatars and config) and `gitea_db` (PostgreSQL) — so a backup is a snapshot of those two volumes, ideally with a `pg_dump` of the database taken first for a consistent restore point.

Kick off a software project quickly.

Gitea

Your own GitHub, self-hosted on a single VPS — repositories, pull requests, CI/CD and a package registry, with no per-seat billing.

2 GB RAM 1 vCPU (2 vCPU with Actions runners) Port 3000 Available

Source code

Tech stack

DockerGoPostgreSQL 16

Minimum RAM2 GB

Minimum CPU1 vCPU (2 vCPU with Actions runners)

Default port3000

Compatible OSubuntu-24.04

Gitea is a lightweight, self-hosted Git service written in Go and released under the MIT licence. It gives you the whole GitHub workflow — repositories, branches, issues, pull requests, code review, wiki, releases — on infrastructure you control, from a single binary that starts in seconds and idles on a few hundred megabytes of RAM.

On a ServOrbit VPS, Gitea runs as two containers: `gitea/gitea` for the application and `postgres:16-alpine` for the database. The web UI is served on port 3000 behind the nginx vhost with HTTPS, and Git over SSH listens on port 2222 so `git clone` and `git push` work with your usual public key. Repository data and the PostgreSQL database each live in a named Docker volume, so a full backup is a volume snapshot.

Beyond hosting code, Gitea bundles two things that usually cost extra elsewhere. Gitea Actions is a CI/CD engine that reads the same workflow YAML as GitHub Actions — existing `.github/workflows` files run almost unchanged on a runner you install yourself. And the built-in package registry speaks npm, Docker/OCI, Maven, NuGet, PyPI, Composer, Cargo and Helm from the same instance that hosts your code. Organisations, teams and protected branches let you reproduce a whole company's Git setup without a monthly per-developer subscription.

Key features

Complete Git platform: repositories, branches, tags, issues, pull requests, code review, wiki and releases — the workflow your team already knows.

Gitea Actions: CI/CD built in, compatible with the GitHub Actions workflow syntax — reuse your existing `.github/workflows` files on a runner you host.

Built-in package registry: npm, Docker/OCI, Maven, NuGet, PyPI, Composer, Cargo and Helm, served from the same instance as your code.

Organisations, teams and fine-grained permissions: per-repository access rules, protected branches, required reviews and code owners.

Git over HTTPS and SSH: clone and push through the nginx vhost, or straight over SSH on port 2222 with per-user public keys.

Repository mirroring: pull mirrors keep an upstream GitHub or GitLab repository in sync; push mirrors publish yours outward automatically.

Authentication that fits your stack: local accounts, LDAP, SMTP, OAuth2 (GitHub, GitLab, Google, generic OIDC) — and Gitea can itself act as an OAuth2 provider for your other apps.

Written in Go, MIT-licensed: one binary, no runtime to maintain, and a few hundred megabytes of RAM for a team-sized instance.

When to use this solution?

1

Private company Git server

Host every internal repository on your own VPS instead of a SaaS account billed per developer. Client projects, proprietary code and unreleased work stay inside infrastructure you own, in a jurisdiction you choose. Onboarding a new developer is creating an account, not adding a paid seat — the cost of the instance does not change when the team grows.

2

CI/CD without a per-minute bill

Gitea Actions reads the same workflow syntax as GitHub Actions, so your existing `.github/workflows` files run with little or no change. Install a runner on the same VPS or on a dedicated build machine and every push, tag and pull request triggers your pipeline — with no build-minute quota and no queue shared with other customers.

3

Internal package and container registry

Publish private npm packages, Docker images, Maven artifacts or PyPI wheels straight to the instance that already hosts your code: `docker push git.example.com/team/api:1.4`. One set of credentials, one backup, one URL for source and artifacts — instead of a separate registry service per ecosystem.

Deploy Gitea on your VPS

Guide optimized for ServOrbit Cloud VPS.

01

Order a ServOrbit VPS

2 GB of RAM is a comfortable starting point for a small team: Gitea itself idles on a few hundred megabytes and PostgreSQL takes the rest. Plan more headroom if you intend to run Gitea Actions runners on the same machine, since builds are the heaviest part of the workload.

02

Point a domain at the VPS

Gitea needs a domain name: clone URLs, webhooks, OAuth callbacks and the package registry all embed the public address of the instance. Create an A record such as git.example.com pointing to your VPS IP — TLS is issued and renewed automatically once the app is deployed.

03

One-click deploy from the marketplace

Open your ServOrbit dashboard → Marketplace → Development → Gitea → Deploy. Docker pulls gitea/gitea and postgres:16-alpine, generates the database credentials, and the web UI answers on port 3000 behind the HTTPS vhost within a minute.

04

Create the admin account and your first repository

Open your domain in a browser: the first account registered becomes the site administrator. From Site Administration you can then close public registration, wire up LDAP or OAuth2, and set the default branch protection rules before inviting your team. Create a repository and push to it: git remote add origin [email protected]:2222/team/api.git.

05

Add a runner for Gitea Actions

CI is off until a runner is registered. Generate a token in Site Administration → Actions → Runners, then start gitea/act_runner on the VPS or on a separate build host pointing at your instance URL. Push a workflow file to .github/workflows/ci.yml and the job appears in the Actions tab on the next commit.

Frequently asked questions

For the day-to-day workflow, yes: repositories, branches, issues, pull requests with review and approvals, wiki, releases, protected branches, webhooks, CI/CD through Gitea Actions and a package registry are all built in. What you give up is the GitHub ecosystem around the product — the public marketplace of third-party Actions, Copilot, Dependabot and the network effect of public open-source. For private company code, that ecosystem is rarely what you were paying for.