Pruvon is a web UI for Dokku. It runs on the Dokku host itself and gives you a browser-based interface for app operations, service management, backups, logs, Docker visibility, and terminal access.

It is not a general-purpose server management panel. Pruvon assumes Dokku, Linux paths, and a service-style deployment on the target host.

• Dokku Web UI: Manage apps, services, and operational workflows from the browser
• Database Backups: Run and retain PostgreSQL, MariaDB, MongoDB, and Redis backups through Dokku plugins
• Logs and Terminal Access: Use browser-based logs and terminal sessions over WebSockets
• Docker Visibility: Inspect containers, images, and host resource usage
• Operational Tools: Manage SSH keys, templates, users, and related Dokku tasks

• A Linux host with Dokku already installed
• sudo or root access on that host
• systemd, nginx, and Dokku available on the host

The supported production path is the official installer. It does more than copy a binary: it lays out the service, config, logs, cron, sudoers policy, and systemd unit for you.

Install the latest release:

curl -fsSL https://pruvon.dev/install.sh | sudo bash

If curl is not available:

wget -qO- https://pruvon.dev/install.sh | sudo bash

Install a specific release:

curl -fsSL https://pruvon.dev/install.sh | sudo env PRUVON_VERSION=v0.1.0 bash

Create a fresh config with a custom listen address:

curl -fsSL https://pruvon.dev/install.sh | sudo env PRUVON_LISTEN=127.0.0.1:9090 bash

PRUVON_LISTEN only applies when the installer creates a new config file. If /etc/pruvon.yml already exists, the installer keeps the existing listen address.

Install or update from a local checkout:

git clone https://github.com/pruvon/pruvon.git
cd pruvon
sudo ./install.sh

Install a locally built binary instead of downloading a GitHub release:

make build
sudo env PRUVON_BINARY=builds/pruvon-linux-amd64 ./install.sh

install.sh will:

• download the matching Linux release archive from GitHub Releases unless PRUVON_BINARY is provided
• verify release archives against checksums.txt
• fetch the matching pruvon.yml.example and scripts/cron/pruvon-backup from the same tagged source tree unless overrides are provided
• install the binary to /opt/pruvon/pruvon
• create /usr/local/bin/pruvon as a symlink
• create the pruvon service user and required group memberships
• create /var/lib/pruvon, /var/log/pruvon, and /var/lib/dokku/data/pruvon-backup
• create /etc/pruvon.yml if it does not exist
• generate a random local admin password for a fresh install and store only its bcrypt hash in config
• rotate the bundled example admin password hash if an existing config still contains it
• ensure /etc/pruvon.yml is owned by the pruvon service user with 0600 permissions so settings changes can be persisted from the UI
• install the systemd unit, sudoers policy, daily backup cron script, and logrotate policy
• enable and start the pruvon systemd service

Any installer-generated admin password is printed once at the end of installation.

install.sh already enables and starts pruvon. After that, normal service operations are done with systemctl and journalctl.

Common commands:

sudo systemctl status pruvon
sudo systemctl start pruvon
sudo systemctl stop pruvon
sudo systemctl restart pruvon
sudo systemctl enable pruvon
sudo systemctl disable pruvon
sudo journalctl -u pruvon -f

Inspect the installed unit or create an override safely:

sudo systemctl cat pruvon
sudo systemctl edit pruvon
sudo systemctl daemon-reload
sudo systemctl restart pruvon

If you edit /etc/systemd/system/pruvon.service directly or create an override with systemctl edit, run daemon-reload before restarting the service.

On an installed system, the main config file lives at /etc/pruvon.yml.

The installer keeps that file owned by the pruvon service user with 0600 permissions so runtime settings changes can be written back safely.

Top-level sections:

• users: Local users, bcrypt password hashes, roles, scoped access, and optional GitHub usernames for SSH key sync.
• pruvon: Runtime settings such as the bind address.
• backup: Backup storage, schedule, database types, and retention.
• dokku: Reserved for future Dokku-specific settings. Leave it as {}.
• server: Legacy or reserved section. Leave it as null unless you know you need it.

After editing /etc/pruvon.yml, restart Pruvon:

sudo systemctl restart pruvon
sudo systemctl status pruvon

If you want to rotate the local admin password, generate a new bcrypt hash and replace the admin user's password in /etc/pruvon.yml.

Generate a hash interactively:

NEW_HASH="$(htpasswd -nBC 10 '' | tr -d ':\n')"
printf '%s\n' "$NEW_HASH"

Edit the config:

sudoedit /etc/pruvon.yml

Example:

users:
  - username: admin
    password: "$2a$10$...your-new-hash..."
    role: admin

Apply the change:

sudo systemctl restart pruvon

Avoid htpasswd -b ...; it exposes the plain-text password in shell history and process listings.

The standard install creates one daily cron job at /etc/cron.daily/pruvon-backup. That job runs:

pruvon -backup auto -config /etc/pruvon.yml

-backup auto does not create separate daily, weekly, and monthly timers. Instead, each daily run chooses exactly one rotation type:

• monthly if today matches backup.do_monthly
• otherwise weekly if today matches backup.do_weekly
• otherwise daily

Key settings in /etc/pruvon.yml:

• backup.backup_dir: Where backup archives are written
• backup.db_types: Which Dokku service types are included
• backup.do_weekly: Weekly rotation day. Use 1-6 for Monday-Saturday, and 0 or 7 for Sunday.
• backup.do_monthly: Day of month for monthly rotation
• backup.keep_daily_days: How many days of daily backups to keep
• backup.keep_weekly_num: How many weekly backups to keep
• backup.keep_monthly_num: How many monthly backups to keep

Run backups manually when needed:

sudo pruvon -backup auto -config /etc/pruvon.yml
sudo pruvon -backup daily -config /etc/pruvon.yml
sudo pruvon -backup weekly -config /etc/pruvon.yml
sudo pruvon -backup monthly -config /etc/pruvon.yml

The repository copy is still useful for local development and manual testing, but it is not the recommended production path.

Start from the example config when you are running from source:

cp pruvon.yml.example pruvon.yml
go run ./cmd/app -server -config pruvon.yml

Development requirements:

• Go 1.26+
• A recent golangci-lint installation if you want to run make lint

Build release artifacts for Dokku hosts:

make build

Build a host-native development binary if needed:

go build -o pruvon ./cmd/app

Common local verification commands:

make fmt
make vet
make test
make lint

make lint expects a recent golangci-lint installation compatible with the Go toolchain in use.

Create a release locally:

make release VERSION=v0.1.1 PREVIOUS_TAG=v0.1.0

This command will:

• regenerate CHANGELOG.md for the target version
• create a release commit such as release: v0.1.1
• build versioned Linux release archives in dist/
• create and push the git tag
• create the GitHub release and upload the archives plus checksums.txt

Release prerequisites:

• a clean git working tree
• gh auth login completed for the target GitHub account
• permission to push the current branch and the new tag to origin

If you want custom GitHub release notes instead of generated changelog text, pass a file path:

make release VERSION=v0.1.1 NOTES_FILE=/absolute/path/to/release-notes.md

Remove the installed service files but keep config, logs, backups, and the service user:

curl -fsSL https://pruvon.dev/uninstall.sh | sudo bash

Remove persistent data too:

curl -fsSL https://pruvon.dev/uninstall.sh | sudo bash -s -- --purge

Also remove the pruvon system user and group:

curl -fsSL https://pruvon.dev/uninstall.sh | sudo bash -s -- --purge --remove-user

If you already have a local checkout, sudo ./uninstall.sh is equivalent.

Default uninstall keeps /etc/pruvon.yml, /var/log/pruvon, and /var/lib/dokku/data/pruvon-backup so an accidental removal does not destroy operational data.

Release notes are generated from commit subjects.

Generate a changelog entry for a release:

make changelog VERSION=0.1.1 PREVIOUS_TAG=v0.1.0

If PREVIOUS_TAG is omitted, the generator uses the latest v* tag it can find.

Best results come from commit subjects with a conventional prefix such as:

• feat: ...
• fix: ...
• docs: ...
• refactor: ...
• test: ...
• chore: ...

These prefixes are grouped into changelog sections like Added, Fixed, Changed, Documentation, Tests, and Maintenance.

• Documentation
• Installation Guide
• Configuration Guide
• Operations Guide
• Security Guide
• CHANGELOG.md

Contributions are welcome. See CONTRIBUTING.md.

See SECURITY.md for vulnerability reporting.

Copyright (c) 2026 Pruvon. Licensed under AGPL-3.0.