GitLab Backup S3
To run a gitlab backup s3 workflow, point the backup tool at a cloud bucket. Then give the host a cloud role or key that can write files there. Many teams set this up with a shared static key on the server. When those permissions are too broad, anyone on that server can read or delete past archives. How a gitlab backup s3 setup works GitLab builds a single archive file when you trigger a backup job. This archive holds your database dump, git repos, and uploaded files. First, the server writes
GitLab CI Security + Backup Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run a gitlab backup s3 workflow, point the backup tool at a cloud bucket. Then give the host a cloud role or key that can write files there. Many teams set this up with a shared static key on the server. When those permissions are too broad, anyone on that server can read or delete past archives.
How a gitlab backup s3 setup works
GitLab builds a single archive file when you trigger a backup job. This archive holds your database dump, git repos, and uploaded files. First, the server writes these files to a local disk folder. Next, the backup tool uploads the bundle to your remote object storage bucket.
To send the archive, the server needs cloud credentials with write permissions. Teams either store static access keys on the host or attach an instance role. Instance roles let the cloud provider hand out temporary tokens to the server. This removes the need to paste long-term secret keys into server config files.
You also must back up your server secret files outside the main archive. GitLab keeps encryption keys in local files on the host machine. If you lose those files, you cannot read encrypted database fields after a restore. Teams store these secret files in a separate safe place away from the bucket.
What native cloud roles solve and what they miss
Cloud bucket policies and instance roles control which hosts can reach your storage. You can set lifecycle rules to move old archives to cold storage. You can also turn on bucket versioning and object lock to block file deletion. These controls protect the stored files from outside attackers and accidental bucket wipes.
Still, storage roles only check identity when a host or user logs in. They do not inspect what individual commands or database queries do during a live session. When an engineer logs into the server to test a restore, they get full host rights. The cloud role cannot tell a routine check from a risky manual command.
GitLab CI Security + Backup Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
During a backup fix or restore test, engineers often query the database directly. Those database tables hold user emails, phone numbers, card numbers, and national IDs. Native bucket rules do not rewrite or mask those fields in query results. Teams also lack a clear log of every command run on the server.
Securing restore tests and server administration
A backup plan is only useful if your team tests restores often. Running a restore requires high privileges on both the server and the database. Engineers need to stop services, unpack archives, and run database checks to verify data.
Giving engineers standing admin credentials on the backup server creates a large risk. Anyone with that login can pull down full production archives at any time. Instead, teams should scope permissions to the exact task and log every action. When engineers query restored tables, data masking should rewrite emails and card numbers in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What files are left out of a standard GitLab backup archive?
The standard archive leaves out your server config file and encryption secret files. You must copy and save these local files in a separate safe location.
Should I use static keys or instance roles for S3 uploads?
Use cloud instance roles or workload identities whenever your hosting setup allows it. They rotate tokens on their own so you do not manage static keys.
How can I stop an admin account from deleting S3 backup archives?
Turn on bucket versioning and object lock in your cloud storage settings. Next, limit the server role so it can only write new objects, not delete them.