Backups are one of those topics that often look simple from the outside.
You configure a job, it runs on a schedule, the logs look fine, and everyone feels reasonably safe.
Until the day you actually need to restore something.
That gap between “the backup job ran” and “the data can be recovered” is one of the reasons I started building Fulgurite.
What is Fulgurite?
**Fulgurite **is a self-hosted PHP web interface for managing Restic backups from a browser.
The goal is not to hide Restic or replace its CLI. Restic is already a great tool. The goal is to make day-to-day backup operations easier to manage, review, and verify, especially for self-hosted setups, homelabs, and small teams.
Fulgurite currently focuses on:
- Restic repository management
- Local and remote backup jobs
- Copy jobs for snapshot replication
- Snapshot browsing and restore workflows
- Scheduler and worker-based execution
- Logs and notifications
- User management with roles and scopes
- TOTP and WebAuthn support
- SSH key and host management
- API and signed webhook integrations
- Built-in themes
- English and French documentation
- Why build another backup interface?
- A lot of backup tooling answers the question:
Did the backup job run?
That is useful, but it is not enough.
The question I care about more is:
Can I actually recover the data?
That changes how you think about the product.
A dashboard should not only show that jobs are green. It should help answer whether the latest snapshots are recent enough, whether repositories are healthy, whether retention policies are configured, and whether restore paths have been tested.
This is why some of the planned features for Fulgurite are focused on operational confidence rather than just configuration:
- Backup health score
- Automated restore tests
- Past and future execution calendar
- Advanced log management
- Automated secret rotation
- Multi-workspace management
- Restore from backup copies
- Current project status
- The project is still early, but the repository has now been cleaned up and documented enough to share publicly.
The current repository includes the application core, public interface, operational scripts, tests, translations, and bilingual documentation.
Some things are intentionally not included yet, such as Docker packaging, website assets, GitHub metadata, and older planning documents. I want to review and integrate those properly instead of dumping everything into the repository at once.
Deployment
At the moment, Fulgurite targets PHP 8.2+.
The basic setup is:
Serve the public/ directory with a web server.
Make config/ and data/ writable by the PHP runtime.
Generate a setup bootstrap token.
Open the setup wizard in the browser.
Create the first administrator account.
Docker packaging is planned, but I am keeping it out of the clean repository until it is reviewed properly.
What I am looking for
I am mainly looking for feedback from people who operate backups in real environments, whether that is a homelab, a small business, a freelance setup, or internal infrastructure.
I would especially like feedback on:
What should a backup dashboard show first?
How would you define a useful backup “health score”?
How often should automated restore tests run?
What would make you trust, or not trust, a web UI around Restic?
Which features are essential before using this in production?
Repo: https://github.com/araneite/fulgurite
If you run Restic, Borg, Kopia, Proxmox Backup Server, or your own backup scripts, I would love to hear how you currently verify that your backups are actually restorable.
Top comments (0)