Host Private Git and SVN Repositories on a VPS — Secure, Simple, and Scalable

Managing your own source control servers — Git and SVN — on a VPS gives organizations full control over code, metadata, and access policies while avoiding third‑party lock‑in. With modern VPS offerings, it’s practical to host private repositories securely and cost‑effectively. This article walks through the technical foundations, typical deployment scenarios, tradeoffs between approaches, and practical guidance for selecting a VPS plan. It is written for site owners, enterprise teams, and developers who need a robust, scalable private SCM platform.

Why host Git and SVN on a VPS?

Hosting repositories on a VPS provides several strategic advantages over using SaaS services: complete data sovereignty, flexible authentication integrations, custom backup and retention policies, and the ability to optimize performance for your workflow. For teams with compliance requirements or that build software for internal systems, these benefits often justify the effort of self‑hosting. A VPS isolates your SCM from other tenants and gives you root-level control to tune storage, backups, and network settings.

Basic architectures and protocols

Two main categories of server deployments dominate self‑hosted SCM: lightweight SSH‑based setups and full‑featured web apps that provide repositories plus UI, issue trackers, and CI/CD.

Git over SSH

Git was designed to work well over SSH. The simplest setup is a Linux account per user or a shared account with forced command restrictions. Production setups commonly use an access layer such as Gitolite or a Git server inside a management service (Gitea, Gogs, GitLab) to map SSH keys to repository permissions.

• SSH keys: Public keys stored on the server are the primary authentication mechanism. Use ed25519 or RSA 4096 for stronger security. Avoid password-based access for Git pushes.
• Restricted shells: Tools like git-shell or forced commands prevent users from obtaining a shell while still allowing Git operations.
• Transport: git clone/push/pull over SSH is efficient and keeps traffic encrypted by default.

Git and HTTP(S)

Serving Git over HTTPS is common when integrating with web workflows or when users are behind restrictive networks. HTTP requires a web server configured to handle smart HTTP Git requests (most web servers support this via cgi or modules). A reverse proxy such as Nginx or Apache can provide TLS termination and load balancing.

• Use a valid TLS certificate (Let’s Encrypt for automated renewals).
• Protect endpoints with authentication (basic auth, OAuth, or token-based).

SVN: svnserve vs Apache mod_dav_svn

Subversion provides two common delivery methods:

• svnserve: A lightweight daemon that speaks the SVN protocol over TCP. Good for simple setups and lower overhead.
• Apache + mod_dav_svn: Integrates SVN with HTTP(S), enabling web-based access control, SSL, and easier integration with authentication backends like LDAP. It’s heavier but more flexible for enterprise use.

Practical deployment options

Choose from three practical deployment models depending on team size and feature needs.

Minimal SSH-only Git server

This option is ideal for small teams and provides the lowest resource footprint.

• Install Git, create a git user and bare repositories under /srv/git/.
• Collect public keys, put them in ~git/.ssh/authorized_keys with forced commands to limit actions.
• Implement backups using rsync or filesystem snapshots.

Pros: simple, low CPU/memory usage. Cons: limited management UI, access control granularity is manual.

Managed lightweight Git services (Gitea / Gogs)

Gitea and Gogs are lightweight self‑hosted Git web services that provide a GitHub‑like UI with issues, pull requests, and repository management without heavy resource demands.

• Run as a systemd service, with Nginx as a reverse proxy and TLS terminated there.
• Support both SSH and HTTP(S) transports and can connect to an external database or use embedded SQLite.
• Enable webhooks to integrate with CI tools like Jenkins, Drone, or a self‑hosted GitHub Actions runner.

Pros: small footprint, rapid setup. Cons: fewer enterprise features compared to GitLab.

Full platform: GitLab (self‑managed)

GitLab offers a complete DevOps platform (Git hosting, CI/CD, container registry, issue boards). It demands more CPU, RAM, and I/O but simplifies team workflows at scale.

• Recommend at least 4–8 vCPU and 8–16 GB RAM for small production teams; larger orgs need more.
• Consider using an object storage backend (S3 compatible) for artifacts and LFS objects.
• Use PostgreSQL and Redis tuned for your workload, and enable backups using GitLab’s rake tasks and scheduled snapshots.

Pros: integrated features. Cons: heavier resource consumption and more complex upgrades.

Security hardening

Security is critical for private repositories. A breach can expose IP and credentials. Key practices include:

• SSH key policy: Enforce strong key types and lifetimes. Reject weak RSA keys. Periodically rotate keys.
• Network controls: Use a firewall (UFW, firewalld, iptables) to allow only needed ports (22, 80/443, and admin ports restricted to specific IPs).
• Fail2ban: Protect SSH and web login endpoints against brute force attacks.
• Least privilege: Run services as dedicated users, restrict filesystem permissions, and use capabilities rather than root where possible.
• TLS & HSTS: Always use HTTPS for web access and API calls. Enable HSTS to prevent protocol downgrade attacks.
• Authentication integrations: For enterprises, integrate with LDAP/AD or SAML so access is centrally managed.
• Audit logging: Enable detailed logs for repository access and administrative operations; ship logs to a central log server.
• Containerization: Consider running Git/SVN services in containers for easier isolation and reproducible deployments.

Data durability and backups

Repositories are small but critical. A robust backup plan uses a combination of techniques:

• Repository-level backups: Use git bundle or git clone –mirror for Git; use svnadmin dump for SVN. Schedule daily incremental dumps and weekly full backups.
• Filesystem snapshots: Use LVM snapshots or cloud provider volume snapshots for point-in-time recovery of repositories and databases.
• Database backups: For web services using MySQL/Postgres, schedule consistent DB dumps and ensure replication or offsite backups.
• Offsite copies: Store backups in a separate geographic region or object storage (S3) to survive datacenter incidents.
• Test restores: Periodically validate backups by performing test restores and running repository integrity checks (git fsck, svnadmin verify).

Scaling and performance considerations

As repositories and user base grow, plan for:

• Disk I/O: Git operations can be I/O heavy, especially with large repositories and many small files. Use SSDs, and consider provisioned IOPS on cloud volumes.
• Network bandwidth: If you have many concurrent pushes/pulls, ensure sufficient outbound bandwidth and consider rate limiting or CDN caching for downloads (releases, large assets).
• Horizontal scaling: Deploy a read‑only Git mirror on additional servers for heavy cloning traffic; use a load balancer in front of web services and scale app workers separately.
• Object storage: Offload large files via Git LFS and use remote object storage to reduce main disk usage.

Choosing the right VPS plan

Selecting a VPS for SCM hosting depends on the deployment model you choose and the team’s size. Key parameters to evaluate:

• CPU: Git operations are mostly CPU‑light but background tasks (garbage collection, CI runners) benefit from multi‑core setups. For GitLab, prefer 4+ vCPUs for small teams.
• Memory: 2–4 GB RAM suffices for small Gitea instances; GitLab typically requires 8–16 GB for production workloads.
• Storage: Use SSDs with sufficient IOPS. Prioritize disk speed over raw capacity for responsiveness. For heavy artifact storage, choose larger disks or networked object storage.
• Bandwidth: Look at monthly transfer limits and peak network performance. High‑throughput teams should pick plans with generous or unmetered bandwidth.
• Snapshots and backups: Choose a provider that supports snapshots or automated backups to simplify recovery.
• Datacenter location: Place the VPS close to your users to reduce latency; for US teams, a USA VPS can improve performance.

For example, a reliable small production setup might begin with a VPS offering 4 vCPU, 8 GB RAM, and NVMe SSD storage. If you plan to run CI runners or host many large artifacts, increase CPU/RAM and use object storage for binary assets.

Operational best practices and automation

Automate routine tasks to reduce human error and improve reliability:

• Configuration management: Use Ansible, Puppet, or Terraform for reproducible server provisioning and configuration.
• Infrastructure as code: Keep server manifests and service templates in a separate private repository with restricted access.
• Monitoring and alerting: Monitor disk usage, CPU, memory, and repository queue sizes. Alert on failed backups and long GC times.
• Maintenance windows: Schedule GC and backup tasks during off‑peak hours and communicate planned outages to users.

When to choose Git vs SVN

Git is the dominant modern SCM with distributed workflows, branch‑centric development, and excellent tooling. SVN remains relevant for large binary monorepos or legacy integrations where centralized locking semantics are needed. Consider SVN if you have existing Subversion workflows or require folder‑level permissions that are easier to express in mod_dav_svn. Otherwise, Git should be the default for new projects.

Summary

Self‑hosting Git and SVN on a VPS is a practical, secure, and scalable solution for teams that require control over their source control environment. From a minimal SSH‑only Git server to a full GitLab install, you can tailor the deployment to match your budget, compliance needs, and team size. Focus on strong SSH/TLS practices, robust backups, and thoughtful resource allocation — especially disk I/O and memory — to keep operations smooth.

If you’re evaluating infrastructure to host your repositories, consider VPS providers that offer SSDs, predictable bandwidth, snapshot backups, and datacenter options close to your users. For U.S.‑based teams, a USA VPS with NVMe storage and automated backups is a sensible starting point; see VPS.DO’s offerings for details and specifications at https://vps.do/ and their USA VPS plans at https://vps.do/usa/.