NEW BBS Manager for iOS: Get real-time backup alerts, manage schedules, monitor progress, even restore data while on the go. Learn more →
Security architecture

Protect the backups.
Limit the access.

Agents push encrypted backups to restricted repositories. Your server manages the work without holding login credentials for your endpoints.

Explore the architectureSee access controls
Your endpointsLinux · Windows · macOSEach agent has its own identity
HTTPS: poll for work ↓SSH: push backups ↓
Your backup serverBorg Backup ServerSchedules · permissions · retention
No inbound connection to endpoints
Restricted repositoryAppend-only agent access
Immutable Backups

Restrict what a
compromised agent can do

Every agent connects via SSH with forced commands that restrict it to borg serve --append-only. Agents can create new archives but can never delete, modify, or overwrite existing ones.

  • Agents are restricted to their own directory — no cross-client access
  • No shell access — agents cannot execute arbitrary commands
  • Only the server can prune old archives via retention policies
  • A fully compromised client cannot destroy existing backups
SSH Forced Command
# ~/.ssh/authorized_keys
command="borg serve --append-only \
  --restrict-to-path /var/bbs/home/{id}",
no-pty,no-agent-forwarding,
no-port-forwarding,no-X11-forwarding
ssh-ed25519 AAAA... bbs-agent
Result
Even with root access on the client, an attacker can only create new archives — never delete or modify existing ones.
Zero Trust

Server never connects
to your machines

BBS operates on a pull model — agents poll the server for work over HTTPS. The server never initiates SSH connections to clients and holds no credentials for client systems.

  • No inbound firewall rules needed on client machines — works behind NAT & firewalls
  • The server needs no endpoint login credentials to schedule backups
  • Agents initiate the connections, keeping endpoint ports closed
  • Server stores no SSH keys, passwords, or tokens for client machines
Traditional vs. BBS Architecture
Traditional Backup Server
Server SSHs into every client with root credentials. One compromise = full network access.
Borg Backup Server
Agents pull work from server over HTTPS. Server holds zero client credentials. No server-initiated endpoint connections.
Access controls

Give each person the access they need.

Assign clients and permissions to users. Require a second factor when they sign in.

Per-client permissions

Control backup, restore and maintenance access for each client.

BBS user permissions matrix showing separate permissions for each client
BBS product screenshot with fictional users and clients.

Two-factor setup

Pair an authenticator app and verify its code before enabling TOTP.

BBS two-factor authentication setup with a QR code and verification field
Setup screen from the isolated demo install.
Defense in Depth

Multiple layers of protection

From encrypted credentials to rate-limited APIs, every layer is hardened independently.

AES-256-GCM Encryption

Repository passphrases, SSH private keys, and TOTP secrets are encrypted in the database using AES-256-GCM with a server-specific application key.

Agent Isolation

Each agent gets a unique API key, dedicated SSH user, and restricted home directory. Agents can only access their own jobs and repositories.

OWASP Web Security

Parameterized queries (PDO), CSRF tokens with constant-time comparison, XSS escaping, command injection prevention via escapeshellarg, HttpOnly cookies.

Rate Limiting

Login attempts (5/5 min), 2FA verification (10/5 min), and agent API endpoints are all rate-limited by IP to prevent brute force attacks.

Role-Based Access

Admins get full system access. Users are limited to assigned clients with granular permissions for backup, restore, repo management, and maintenance.

Two-Factor Authentication

TOTP-based 2FA compatible with any authenticator app. Admins can enforce 2FA for all users. Recovery codes are bcrypt-hashed and single-use.

Data at Rest

Encryption at
every layer

Sensitive data is protected both in the database and in backup archives, using industry-standard encryption algorithms.

  • Database credentials encrypted with AES-256-GCM + server APP_KEY
  • Borg archives encrypted with repokey-blake2 (AES-256) by default
  • Passwords hashed with bcrypt — never stored in plaintext
  • 2FA recovery codes are also bcrypt-hashed and single-use
What's encrypted
Repository passphrases AES-256-GCM
SSH private keys AES-256-GCM
TOTP secrets AES-256-GCM
User passwords bcrypt
Backup archives AES-256 (Borg)
Managed Updates

Stay current with
security patches

Keep agents, Borg binaries, and the server itself up to date without touching a terminal. Updates are deployed from the web interface with automatic validation.

  • Agent updates deployed individually or in bulk from the web UI
  • Borg binary versions managed centrally with per-agent control
  • Server checks for new releases daily with web UI or CLI upgrade
  • Automatic rollback on failed agent updates
Update Targets
Agent Updates
Deploy new Python agent versions from the web UI. Single or bulk deployment with validation.
Borg Binary
Manage Borg versions centrally. Update individual agents or the entire fleet at once.
Server
Daily release checks with one-click upgrade from the web UI or CLI.
Architecture Summary

Security at every layer

A complete overview of how Borg Backup Server protects your infrastructure.

Layer
Protection
Client → Server
Append-only SSH, restricted to borg serve, no shell access
Server → Client
None — server never connects to clients (zero trust)
Agent API
HTTPS + API key auth + rate limiting + job ownership checks
Web Interface
CSRF tokens, bcrypt passwords, session security, rate limiting
Data at Rest
AES-256-GCM (credentials), AES-256 Borg encryption (archives)
Database
Parameterized queries, no raw SQL, emulated prepares disabled
Access Control
Role-based (admin/user) + per-agent granular permissions
Offsite
S3 sync with disaster recovery and orphaned repo detection
Updates
Centrally managed agent + Borg updates from web UI
Responsible Disclosure

Report a vulnerability

If you discover a security vulnerability in Borg Backup Server, please do not open a public issue. Report it privately instead.

Use GitHub's private vulnerability reporting to send the maintainers a description, steps to reproduce, and the potential impact. Include a suggested fix if you have one.

Report privately on GitHub

Read the security policy for reporting scope and response expectations.

In Scope
  • Authentication & session management
  • SQL injection, XSS, CSRF (OWASP Top 10)
  • Agent API authentication bypass
  • Credential exposure
  • Privilege escalation
  • Remote code execution
Out of Scope
  • Third-party dependency bugs
  • Physical access scenarios
  • Social engineering

We follow coordinated disclosure. Once a fix is released, the vulnerability will be documented in the release notes. Credit will be given unless you prefer to remain anonymous.

100% Open Source · MIT Licensed · Zero-Trust

See it in action

Spin up a live demo to explore the security features yourself. Full access, no credit card, no install.

Launch Demo Installation Guide
1-Minute Docker Setup Full Feature Access Secure & Isolated