Git Self Host
To run a git self host setup, deploy a source control app on your own server. You then set up network rules, storage disks, and user roles for your team. Most teams start by installing a source control tool on a Linux virtual machine. They create admin accounts and give broad read or write roles to developers. When roles are too broad, anyone can change server settings or read secret code. How a git self host architecture works A git self host system runs on a server that your team controls.
Self-Service Access Portals + Git Commit Signing (GPG, SSH): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run a git self host setup, deploy a source control app on your own server. You then set up network rules, storage disks, and user roles for your team. Most teams start by installing a source control tool on a Linux virtual machine. They create admin accounts and give broad read or write roles to developers. When roles are too broad, anyone can change server settings or read secret code.
How a git self host architecture works
A git self host system runs on a server that your team controls. The core system uses a web app, a background worker, and a database. It also writes code files to local disks or cloud storage buckets. Developers reach the server over the network using web links or SSH keys.
When a user pushes code, the server checks their SSH key or token. Next, the app checks the user role in its local database. Standard roles include guest, reporter, developer, maintainer, and owner. Each role controls who can read code, merge branches, or change project settings. Teams often link the server to an identity provider for single sign-on. This link lets users log in with their work email accounts. Once the role check passes, the server writes the new commits to disk. It then runs background jobs to update the web view and start build pipelines.
How to set up roles and host permissions
Start by placing your source control server inside a private network subnet. Only allow user traffic on the web port and the SSH port. Next, connect your identity provider so you do not manage local passwords. Map your existing team groups to project roles inside the source control app. Give most engineers the developer role so they can push to feature branches. Protect the main branch so only maintainers can merge approved code changes.
You must also lock down the Linux host that runs the git app. Only system admins should have SSH login rights to the underlying virtual machine. Set up automated backups that copy both the database and the code disks. Store those backup files in a separate account with strict read rules. Test your backup restore process every month to make sure it works.
Self-Service Access Portals + Git Commit Signing (GPG, SSH): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native roles solve and what they miss
Built-in roles do a good job of sorting users inside the web app. They stop junior developers from deleting projects or pushing straight to the main branch. Linking an identity provider also makes it easy to remove departed staff. When someone leaves the company, you disable their main account in one place.
Still, app roles only govern actions inside the git interface itself. Your admins still need direct access to the Linux host and backend database. They log in via SSH or database clients to run updates and fix bugs. Native git roles only check who logs in to the code app. They do not inspect what commands or queries admins run on the server. A single bad query on the backend database can wipe out project records. Also, shared SSH keys for host maintenance leave you with weak audit logs. You can see that someone logged in as the root user. You cannot see which person ran a specific command during that session. Standard host setups also expose raw user data like emails in database query results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do teams choose a git self host setup over cloud hosts?
Teams self host to keep full control over their source code and network rules. It helps them meet strict rules on where data lives and who reaches it.
How should we handle backups for a self hosted git server?
You must back up the database and the code storage disks at the same time. Copy these snapshots to an outside storage bucket and test restores often.
What is the biggest risk of running your own git server?
The biggest risk is unmanaged admin access to the underlying Linux host and database. Broad host access lets engineers bypass app rules and read or delete anything.