Your first GitHub backup
in under 10 minutes.

CYBBACK offers two ways to get started. Both unlock the full GitHub feature set.

Option A — Free trial

1. Open cybback.com/essai-gratuit.
2. Fill in your work email, company and a password. Click Start free trial.
3. Confirm via the verification email.
4. On the trial selection screen, pick GitHub. Your trial workspace is provisioned instantly.

Option B — Paid licence (Stripe checkout)

1. Go to cybback.com/tarifs and pick the GitHub plan that matches the number of GitHub owners (user / organisations) to protect.
2. Click Subscribe. Stripe Checkout supports cards, SEPA and invoicing on annual plans.
3. Your licence is active immediately — visible under Account → Subscription.

CYBBACK reads your GitHub data through a Personal Access Token. Pick the type that matches your governance — both classic and fine-grained PATs are supported.

Option A — Classic PAT (simplest)

1. Open github.com/settings/tokens/new.
2. Note: CYBBACK Backup. Expiration: 90 days (set a calendar reminder to rotate).
3. Tick the repo scope (covers all repository contents, issues, PRs, releases, webhooks). Add read:org if you want to back up org-owned repos.
4. Click Generate token and copy the value (it will not be shown again).

Option B — Fine-grained PAT (recommended for orgs)

1. Open github.com/settings/personal-access-tokens/new.
2. Resource owner: your user, or the organisation you want to back up.
3. Repository access: All repositories or specific ones.
4. Permissions (Repository): Contents: Read, Metadata: Read, Issues: Read, Pull requests: Read, Webhooks: Read, Actions: Read & write (write needed only to restore variables).
5. Click Generate and copy the value.

Paste the PAT into CYBBACK

1. Open app.cybback.com/dashboard/github-backup → Configuration.
2. Paste the PAT and click Validate. CYBBACK calls GET /user to confirm the token works and fetches your username + accessible orgs.
3. The PAT is encrypted (AES-256-GCM) and stored in the CYBBACK vault.

CYBBACK can back up every repository the PAT can see, or only a hand-picked subset. You can also tune which categories of data to capture per backup.

Scope

• All my repos (default) — every repo where the PAT has access (own + collaborator + org member).
• Manual selection — click Load repos, then tick by owner or by individual repo. Useful when you only want to protect production repos and skip personal forks.

What to include

Each backup can include or skip these categories independently:

• Source code — full git history (git bundle --all), all branches and tags.
• Settings — visibility, default branch, protected branches, topics.
• Teams — team name, slug, permission level (org repos only).
• Webhooks — URL, events, hash secret, active state.
• Workflows — Actions workflow definitions metadata. The YAML files themselves live in the code bundle.
• Actions variables — name + value (restorable via API).
• Actions secret names — names only. GitHub never exposes the values via API; we keep the names so you know what to recreate after restore.
• Issues / Pull requests / Releases — read-only snapshots (state, labels, comments, reviews).

Want full data sovereignty? Point CYBBACK at your S3-compatible bucket — AWS S3, GCS, Scaleway, OVH, Wasabi, MinIO. Your data, your provider, your region.

Provision the bucket

1. In your S3 provider, create a private bucket (no public access, versioning recommended).
2. Create an access key / secret key with permissions limited to that bucket.
3. Note your endpoint URL and region.

Configure CYBBACK

1. Open Dashboard → Storage.
2. Select My own S3 storage.
3. Fill the form, click Test connection, then Save.

• Required IAM actions: PutObject, GetObject, DeleteObject, ListBucket.
• Resilience: CYBBACK stores an encrypted snapshot of S3 credentials with each backup. Old backups remain restorable even after you switch providers.
• Disk usage: a typical mirror of 100 active repos (~2 GB combined) takes ~500 MB on S3 thanks to git's natural compression.

You're now fully configured. Time to run your first GitHub snapshot — manually for instant peace of mind, then schedule recurring runs.

Manual backup

1. Go back to the Dashboard tab.
2. Click Run backup now. The job appears with status pending, then running.
3. Progress is streamed live: PAT validated, repos enumerated, bundles uploaded, metadata snapshots saved.

Schedule automatic backups

1. From Dashboard → Schedules, click New schedule.
2. Service: GitHub. Frequency: Daily / Weekly / Custom (cron).
3. Pick a window (e.g. 04:00 Europe/Paris) and click Save.

Track your backups

• Real-time: the Events page streams every operation across all services via SSE.
• Notifications: success / failure / drift alerts via email, Slack and webhooks.
• Drift detection: alerts on suspicious patterns — mass repo deletions, force-pushes erasing history, sudden permission changes between runs.

CYBBACK restores from any previous GitHub snapshot. Push a single repo back to its original owner, fork it to an alternate user/org, or roll back the entire account in case of compromise.

The 3-step restore flow

1. Selection. Open the snapshot, browse the repos, tick what you want to recover. Pick the categories to restore (code, settings, webhooks, workflows, variables).
2. Options. Choose your safety net:
   • Dry-run — simulate, no GitHub API write, no git push.
   • Force overwrite — git push --mirror --force, replaces the target history. Use only if you trust the snapshot.
   • Target owner — leave empty to restore to the original owner, or specify another user/org. Combine with a repo-name suffix (-restored) to avoid collisions.
3. Execution. The async worker downloads the bundle from S3, pushes via git push --mirror, then recreates webhooks + Actions variables via REST. A summary shows what was created, updated or skipped.

Best practices

• Always start with a dry-run — the worker reports exactly what it would push without touching GitHub.
• Restore to an alternate owner first for major DR scenarios. Validate the result, then plan a controlled cutover.
• Force overwrite is irreversible on the target. The original repo's history is gone after a successful --force push.