Add git backup to remote repository (closes #996)

[EduardSchwarzkopf]

What: Automated git backup to a remote repository via SSH with configurable schedule.

Why: Addresses the feature request in #996 — users wanted an optional way to auto-commit page saves and push them to a remote git repository for backup purposes, similar to Otterwiki's experimental repository management feature.

Changes:

• New internal/backup/ package — Git repository operations, scheduled backup runner, configuration, status tracking, and gitignore handling
• Admin API routes — GET /api/admin/backup/status and POST /api/admin/backup/push endpoints
• Frontend UI — Backup settings page accessible from user dropdown
• Documentation — README updated, docs/docker-backup.md added
• Configuration — CLI flags and env variables for remote URL, branch, SSH key, interval, author

Configuration

CLI Flags

Flag	Description	Default
--git-backup	Enable automated git backup	false
--git-backup-remote	SSH remote URL for the backup repository	""
--git-backup-branch	Git branch to push to	main
--git-backup-author-name	Git commit author name	LeafWiki Backup
--git-backup-author-email	Git commit author email	[email protected]
--git-backup-interval	Backup interval in minutes	60
--git-backup-ssh-key-path	Path to SSH private key file	""
--git-backup-ssh-key	Raw SSH private key (PEM)	""
(new) --git-backup-ssh-known-hosts	Known hosts for MITM protection	""

Environment Variables

Variable	Description
LEAFWIKI_GIT_BACKUP	Enable automated git backup
LEAFWIKI_GIT_BACKUP_REMOTE	SSH remote URL for the backup repository
LEAFWIKI_GIT_BACKUP_BRANCH	Git branch to push to
LEAFWIKI_GIT_BACKUP_AUTHOR_NAME	Git commit author name
LEAFWIKI_GIT_BACKUP_AUTHOR_EMAIL	Git commit author email
LEAFWIKI_GIT_BACKUP_INTERVAL	Backup interval in minutes
LEAFWIKI_GIT_BACKUP_SSH_KEY_PATH	Path to SSH private key file
LEAFWIKI_GIT_BACKUP_SSH_KEY	Raw SSH private key (PEM)
LEAFWIKI_GIT_BACKUP_SSH_KNOWN_HOSTS	Known hosts for MITM protection

Example usage

./leafwiki \
  --git-backup=true \
  [email protected]:user/leafwiki-backup.git \
  --git-backup-branch=main \
  --git-backup-author-name="LeafWiki Backup" \
  [email protected] \
  --git-backup-interval=60 \
  --git-backup-ssh-key-path=/path/to/id_rsa

Or via environment variables:

LEAFWIKI_GIT_BACKUP=true
[email protected]:user/leafwiki-backup.git
LEAFWIKI_GIT_BACKUP_SSH_KEY_PATH=/path/to/id_rsa

Admin API

When git backup is enabled, two admin-only REST endpoints are available:

Method	Endpoint	Description
GET	/api/admin/backup/status	Returns backup status: lastBackupAt, lastError
POST	/api/admin/backup/push	Triggers an immediate backup push (returns 202 Accepted)

Restoring from backup

To restore your wiki from a git backup:

1. Stop the LeafWiki server
2. Navigate to your data directory
3. Use git log to view backup history and git checkout <commit> to restore
4. Restart the LeafWiki server

Note: Only root/ and assets/ are backed up. The SQLite database is not included.

[perber]

Let me know when you are done.
I think we should release this in v0.11.0. Hopefully this is fine for you.

[EduardSchwarzkopf]

absolutely fine. Should I update the versions in the README from v0.10.0 to v,0.11.0 for the backup and reverse proxy features?

Flag	Description	Default	Available since
--jwt-secret	Secret used for signing JWTs (required)	–	–
--host	Host/IP address the server binds to	127.0.0.1	–
--port	Port the server listens on	8080	–
--data-dir	Directory where data is stored	./data	–
--admin-password	Initial admin password (used only if no admin exists) (required)	–	–
--public-access	Allow public read-only access	false	–
--hide-link-metadata-section	Hide link metadata section	false	–
--inject-code-in-header	Raw HTML/JS code injected into tag (e.g., analytics, custom CSS)	""	v0.6.0
--custom-stylesheet	Path to a .css file inside the data dir, served publicly as /custom.css or ${base-path}/custom.css	""	v0.8.5
--allow-insecure	⚠️ Allows insecure HTTP usage for auth cookies (required for plain HTTP)	false	v0.7.0
--access-token-timeout	Access token timeout duration (e.g. 24h, 15m)	15m	v0.7.0
--refresh-token-timeout	Refresh token timeout duration (e.g. 168h, 7d)	7d	v0.7.0
--disable-auth	⚠️ Disable authentication & authorization (internal networks only!)	false	v0.7.0
--base-path	URL prefix when served behind a reverse proxy (e.g. /wiki)	""	v0.8.2
--max-asset-upload-size	Maximum size for asset uploads (e.g. 50MiB, 50MB, 52428800)	50MiB	v0.8.5
--enable-revision	Enable revision history / page history	false	v0.9.0
--enable-link-refactor	Enable link refactoring dialog and rewrite flow	false	v0.9.0
--max-revision-history	Maximum revisions kept per page; 0 means unlimited	100	v0.9.0
--enable-http-remote-user	Enable reverse-proxy authentication via HTTP header	false	v0.10.0
--http-remote-user-header-name	HTTP header carrying the username from a trusted proxy	Remote-User	v0.10.0
--trusted-proxy-ips	Comma-separated list of trusted proxy IPs/CIDRs (e.g. 127.0.0.1,172.18.0.0/16)	""	v0.10.0
--http-remote-user-logout-url	URL the frontend redirects to after logout in proxy-auth mode	""	v0.10.0
--git-backup	Enable automated git backup to a remote repository	false	v0.10.0
--git-backup-remote	SSH remote URL for the backup repository (optional; omit to use local-only git history)	""	v0.10.0
--git-backup-branch	Git branch to push to	main	v0.10.0
--git-backup-author-name	Git commit author name	LeafWiki Backup	v0.10.0
--git-backup-author-email	Git commit author email	[email protected]	v0.10.0
--git-backup-interval	Backup interval in minutes	60	v0.10.0
--git-backup-ssh-key-path	Path to SSH private key file	""	v0.10.0
--git-backup-ssh-key	Raw SSH private key (PEM)	""	v0.10.0

[EduardSchwarzkopf]

alright, i have updated the code. I hope i got everything. Let me know if there is still some things missing.

[perber]

Hi @EduardSchwarzkopf,

thanks!
The proxy configuration will be in v0.10.0. I added a proxy setup with dex enabled into the hacks folder to verify if it is working as expected.

It would be could if you could create a separate PR with the flag documentation of the proxy settings. I would keep the Git configuration still in this PR, to be ready for the v0.11.0 release.

I will checkout the branch and let it run on my system and test it a bit manually before merging it. Hopefully soon ;)

If you are interested to support more let me know!

One issue I'm facing at the moment, as the flags are growing not sure if it makes sense to keep them like that. If you are interested to do a proposal and implementing it.

Let me know!

But we still need to consider how it could be started in a few seconds without providing a huge configuration file.
So, I'm not sure at the moment how to do it best and if this is a good direction either. Or just grouping the flags.

Maybe like Paperless-ngx? https://docs.paperless-ngx.com/configuration/

They allow a configuration file & flags. Maybe this is the way to go.

[EduardSchwarzkopf]

It would be could if you could create a separate PR with the flag documentation of the proxy settings. I would keep the Git configuration still in this PR, to be ready for the v0.11.0 release.

Alright, will remove this from my PR then and provide a new PR.

If you are interested to support more let me know!

Sadly i do not have that much time to be an active maintainer, but I might provide more support in the future, when i see the need for a new feature/fix :D

One issue I'm facing at the moment, as the flags are growing not sure if it makes sense to keep them like that. If you are interested to do a proposal and implementing it.

Yes, I see the point, having this managed via a config or .env file is fine for the moment. Long term, I'd suggest moving this into a settings page, so the user can manage this via UI?

[perber]

Alright, will remove this from my PR then and provide a new PR.

Perfect, thanks!

Sadly i do not have that much time to be an active maintainer, but I might provide more support in the future, when i see the need for a new feature/fix :D

Happy to hear ;)

Yes, I see the point, having this managed via a config or .env file is fine for the moment. Long term, I'd suggest moving this into a settings page, so the user can manage this via UI?

Here I need to think a bit deeper, because as a K8s admin, I hate having my configuration not managed via GitOps. So it depends, but I need to think about it.

[EduardSchwarzkopf]

Here I need to think a bit deeper, because as a K8s admin, I hate having my configuration not managed via GitOps. So it depends, but I need to think about it.

100%, considering the point that the setup itself requires some sort of technical knowledge, I'd 100% second your idea with a configuration file. Maybe to have the pluses of both worlds, the app can provide a small overview of enabled features and their values, similar to Firefox's about:config`. Another benefit of this is that it also provides a bit of a sanity check.

[perber]

@EduardSchwarzkopf thanks for rebasing it. I will check it out the upcoming days. I reworked a bit the Readme. Based on your PR, regarding releases badge :)

[EduardSchwarzkopf]

No problemo. I'm just not too sure about the big backup section in README tbh.

Maybe move it into /docs?

[perber]

I need to spin up anyway a LeafWiki instance for the public documentation.
I would leave the backup in the readme for now.

If you take a look at the bitnami sealed secrets repo https://github.com/bitnami-labs/sealed-secrets. They have a pretty huge readme already.

I guess this is OK for now. I think it is already good to have it documented.

[perber]

I will work on your branch if it is ok.
Just to test things and stuff, regarding Git.

[EduardSchwarzkopf]

Yes, sure, go ahead, I don't mind at all. Hit me up, when you need something from my end

[perber]

I have to do a patch release and some smaller improvements. So not sure when I will get to that, but you already have the functionality. So I guess it is not urgent to you

[EduardSchwarzkopf]

gut ding will weile haben

@perber I'm not in a rush here. My backups are running anyway. This feature is nothing I'm desperate to have. You are doing great work, so don't rush anything :)