Introduce a Plugin System for gib (community-driven, safe and extensible) #11
Description
gib is designed to be a flexible, developer-friendly backup tool, but today its behavior is fully defined by the core binary.
Introducing a plugin system would allow the community to extend gib in powerful ways without bloating the core, enabling use cases such as:
Custom storage backends (GCP, Google Drive, custom APIs, etc.)
Smart file handling (e.g. SQLite dumps instead of raw file copies)
Domain-specific backup and restore logic
Experimental features developed outside the core project
High-level Goal
Allow users to install and use plugins via a simple CLI interface:
gib install
Plugins should be:
Optional
Composable
Easy to develop
Safe to execute on the user’s machine
Plugin Capabilities (Examples)
A plugin may expose any subset of the following capabilities:
- Custom storage backends
Plugins may implement new storage exporters, allowing backups to be written to:
Cloud providers (e.g. GCP)
SaaS platforms (e.g. Google Drive)
Custom or self-hosted services
This enables community-driven storage support without baking everything into core.
- File-level hooks (backup)
Plugins may optionally export:
on_file_backup(file) -> result
This hook is called for each file during backup and may:
Decide whether the core backup logic should continue for this file
Replace the backup process entirely
Transform the file (e.g. dump a database)
Define a custom upload path or metadata
Example use case:
Detect SQLite files
Run a SQLite dump
Backup the dump instead of the raw .sqlite file
- File-level hooks (restore)
Similarly, plugins may export:
on_file_restore(file) -> result
This allows plugins to:
Restore transformed files correctly
Rebuild databases from dumps
Apply custom logic during restore
Continuing the SQLite example:
Detect dump file
Restore database using proper SQLite commands
Design Principles
Plugins are first-class citizens, but fully optional
Core behavior remains simple and predictable without plugins
Plugins should not require recompiling gib
The system must scale to many plugins without complexity explosion
Critical Consideration: Security & Execution Model
How plugins are executed is the most critical part of this feature.
We must carefully design:
How plugins are installed
How they are executed
What they are allowed to access
How failures are isolated
Key concerns:
Plugins will run on the user’s machine
They may execute arbitrary logic
They must not silently compromise user data or system security
Possible directions (non-exhaustive):
Sandboxed execution (WASM, isolated processes, restricted APIs)
Explicit permission models
Clear trust boundaries and documentation
Strong defaults and safe failure modes
This must be designed carefully before implementation.
Summary
This issue proposes adding a safe, open and extensible plugin system to gib, enabling the community to:
Add new storage backends
Customize backup/restore behavior per file
Build powerful integrations without touching core
The main challenge is designing a secure execution model, which should be treated as a first-class concern.