Part of the Sovereign Stack · Family: Sovereign
Sovereign Code
Host your company’s source code in a managed GitLab environment in Europe or on your own servers. Control access and check changes for passwords and access keys.
Where your code is hosted
- Keep project files and their change history in company-controlled repositories.
- Set who may read, change, review and release the code.
- Agree hosting, backups and checks that help prevent exposed passwords and access keys.
How it works
- Create company accounts and move the agreed projects with their history.
- Review changes and run checks before they reach the main version.
- Keep an inventory, remove unnecessary access and test project recovery.
Scroll sideways to read the full drawing.
Your team’s code, under company control.
- Your development team
- Employees and partners
- Company project accounts
- Access for the right people
- Sovereign Code
- Company-controlled GitLab
- Review protected branches
- Check for exposed access keys
- A project you can recover
- Keep project history
- Review and remove access
- Back up and test restoration
Choose European hosting or your own servers; document administrator access.
- Repository
- A project’s files and their change history.
- Secret
- A password, token or access key that allows software to use another service.
- Check before saving
- Checks on the developer’s machine that help identify exposed credentials.
- Protected branch
- A shared version of the code with rules for reviewing and accepting changes.
- Signed commit
- A code change with a cryptographic signature whose identity must be verified.
- CLOUD Act
- Clarifying Lawful Overseas Use of Data Act. US law concerning electronic evidence; provider obligations cannot be inferred from storage location alone.
Who can access and change the code?
A repository contains a project’s files and their change history. We use company accounts, access rules and protected branches so changes follow the agreed review process.
Checks on the developer’s machine and in the shared workflow help identify passwords and access keys. We agree where each check runs; an exposed key also needs revocation and investigation.
Move your existing projects
We inventory the repositories, people and integrations first. The migration plan covers code history, issue records where supported, automation, access and backups.
Before switching teams over, we check that they can retrieve code, propose a change and run the agreed release process.
A lesson from our own project
A student working on one of our projects copied the repository to a personal GitHub account. It contained a SendGrid access token. The provider later told us that the token had been found in a public repository and revoked.
The practical lesson is to use company accounts, check for exposed credentials and keep an inventory of projects. Revoking the token did not remove copies of the code.
Hosting choices also need a review of the provider, administrator access and relevant legal obligations; a storage country alone is not a complete answer.
Technical details
For IT people: GitLab, self-hosted or EU-hosted, pre-commit secret scanning, protected branches, signed commits, repository inventory.
Training for your team
- Length
- Half a day
- For whom
- Development leads and teams
- On the programme
- Use company accounts, check credentials and review migration and access.
Related security topics
Explore the practical measures and references related to this service.