GitLab Cloud Backup
You create a gitlab cloud backup by running an archive job and copying files to remote storage. For hosted accounts, you export project bundles through the API and save them in a bucket. Teams often run these jobs with admin keys that hold full read and write power. When those broad roles leak, an attacker can read or wipe all your code and data. How a native gitlab cloud backup workflow runs A complete backup must capture code repos, database rows, and uploaded files. In a self-managed setup
GitLab CI Security + Backup Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You create a gitlab cloud backup by running an archive job and copying files to remote storage. For hosted accounts, you export project bundles through the API and save them in a bucket. Teams often run these jobs with admin keys that hold full read and write power. When those broad roles leak, an attacker can read or wipe all your code and data.
How a native gitlab cloud backup workflow runs
A complete backup must capture code repos, database rows, and uploaded files. In a self-managed setup, a built-in utility packs these parts into one archive file. The server then sends that archive to a cloud bucket for safe keeping. Teams run this task on a daily timer so backups stay fresh.
On the hosted service, you do not have direct root shell access to the host. Instead, your team scripts an export task using project and group API tokens. The script triggers an export, waits for the file, and downloads the archive. Then it uploads the bundle to your own storage bucket in the cloud.
Both paths need strong secret keys to read data and write to buckets. The backup job must read every table in the database and every Git repo. It also needs a cloud storage key that can write large objects into your bucket. Admins often store these keys on the host server or inside a runner variable.
What native backup tools solve and where gaps remain
Native export and backup tools solve the basic problem of copying data off your main host. They bundle your Git history, issues, and wiki pages into a portable format. If a disk fails, you can pull the archive from your bucket and restore your state. This keeps your team safe from hardware loss or simple user mistakes.
Still, the native setup leaves a major security gap around who controls the backup process. Platform roles only check who logs in to start the job or read the host. They do not inspect what individual database queries or shell commands do in flight. An engineer who logs in to check a failed backup gets full host or database privileges.
GitLab CI Security + Backup Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
That person can run a drop command or pull raw customer rows by mistake. If an export script runs with a broad token, anyone who reads that token gains admin power. Native roles also fail to mask sensitive fields inside database dumps or query results. Email addresses, phone numbers, and card numbers sit in plain text when admins inspect live tables.
How to tighten backup permissions and protect live data
To reduce risk, split the roles for reading source data and writing to remote buckets. Give the storage key write-only rights on the bucket so it cannot delete past backups. Turn on bucket object locking so nobody can wipe old archives during an attack. Rotate your API tokens on a strict schedule and scope them to read-only export rights.
You should also limit how engineers check and fix broken backup jobs on live hosts. Do not hand out permanent root shell keys or broad database passwords to the whole team. Require human approval before anyone runs a manual restore command or queries the main database. Masking rules can also rewrite emails and phone numbers in query results during live checks.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does the hosted service back up my projects for me?
The provider keeps copies for their own disaster recovery across their fleet. Still, you cannot use their internal snapshots to restore a single deleted project. You must run your own project exports if you want account-level restore control.
What data is left out of a standard project export?
Project exports save Git repos, issues, merge requests, labels, and wiki pages. They leave out build artifacts, container registry images, and secret runner variables. You need separate scripts to copy your registry images and secret settings to safe storage.
How often should a team test a backup restore?
Your team should test a full restore into a staging host at least once a quarter. An untested archive can hide corrupt database tables or missing upload files. Regular drills prove that your keys, scripts, and archive files work when an outage hits.