The fundamental objects of the application
Almost everything you work with in Fulgurite can be tied back to one of the building blocks below.
Repository
A Restic backend known to the application, with its path, secret, alert threshold and notification policy.
Backup job
A task that describes what to back up, to which repository and with which options: schedules, retention, hooks, retries, notifications and local or remote execution.
Copy job
A replication task via restic copy to another destination, useful for offsite backups or a second target.
Snapshot
A state saved in a repository. It can be explored, compared, downloaded, retagged, deleted or restored.
Restore
A local or remote recovery operation, full or partial, tracked with status, destination, logs and author.
Scheduler and worker
The scheduler decides what to run on each cron pass. The worker processes the internal queue and certain background tasks.
Lifecycle of a backup in Fulgurite
Understanding this cycle makes the product's architectural decisions much easier to read.
- Create a repository. You register a Restic backend with its secret.
- Create a job. You describe the sources, the target, the retention options, notifications and the retry policy.
- Trigger. The job runs manually or via the central cron according to the configured scheduling time zone.
- Snapshot produced. The repository grows, the application refreshes its indexes and its runtime status.
- Browse. The user explores the snapshot, searches for a file or compares two versions.
- Restore. The user restores all or part of the snapshot locally or remotely, and the operation is added to the history.
Roles, permissions and scopes
Fulgurite combines a role-based logic, a permission matrix and finer visibility scopes on repositories and hosts.
| Level | What it covers | Examples |
|---|---|---|
| Role | The account's hierarchical position. System roles are compared by level. | viewer, operator, restore-operator, admin |
| Permission | Precise application rights used to display or authorize actions. | repos.manage, restore.run, scheduler.manage |
| Repo / host scope | Visibility restriction on a subset of repositories or hosts. | An operator can manage only certain repositories. |
repo_scope and host_scope scopes silently filter the visible resources. A scoped user sees neither in the interface nor via the API the repositories or hosts that fall outside their scope: the application does not display an "access denied" error — those resources are simply absent from the list returned to them. This is an intentional design, useful for isolating teams on a shared instance.Quick glossary
Central cron
A single system cron entry that calls the scheduling engine. There is no separate cron line per job.
Dedicated worker
A CLI process responsible for processing the internal queue, with a heartbeat, detection of stale workers and optional systemd management.
Notification policy
Declarative configuration of the channels to use for a given event profile, with optional inheritance.
Retry policy
The strategy for retrying a job on error, decided based on a classification of outputs and return codes.