Velld

Self-hosted database backup automation, honestly reviewed. Built on real data from the GitHub repository and official documentation — no third-party reviews found at time of writing.

TL;DR

• What it is: A self-hosted database backup management tool with a web UI. Schedule automated backups, monitor status, compare backup diffs, and restore — all from one dashboard [1][2].
• Who it’s for: Developers and small teams running PostgreSQL, MySQL, MongoDB, or Redis who want scheduled backups with a UI instead of cobbled-together cron scripts and shell commands.
• Cost savings: Managed database backup services (AWS Backup, Azure Backup, Snapshooter, SimpleBackups) run $10–$50+/mo depending on database count and retention. Velld is $0 software on a VPS you already pay for.
• Key strength: Dead-simple deployment (one docker compose up -d), MIT license, and a built-in backup diff/comparison viewer that most tools in this category don’t have [1].
• Key weakness: 467 GitHub stars at time of review — this is a young, lightly-adopted project with one primary contributor. No independent community reviews found. Use it knowing you’re an early adopter [1].

---

What is Velld

Velld is a self-hosted web application for database backup management. You connect your databases through a UI, set cron schedules, and Velld handles the rest: running backups on schedule, pushing files to S3-compatible storage, tracking history, sending email notifications on failure, and letting you compare any two backups side-by-side [1][2].

The pitch is narrow and honest: “a database backup management and automation tool” [1]. No grand claims about AI, no venture-backed roadmap, no enterprise upsell. The README says what it does and moves on.

The technical stack is Go on the backend, Next.js on the frontend. Deployment is Docker Compose with prebuilt images. Credentials are encrypted at rest. There’s a REST API if you want to integrate with other systems [1][2].

What makes it different from just writing a bash cron job:

• A web UI with history, status, and storage metrics — you don’t need to SSH in to know if last night’s backup succeeded
• A backup comparison viewer with line-by-line diff — unusual for a tool at this stage
• Multi-database management from one place — one dashboard for all your Postgres, MySQL, and Mongo instances
• Email notifications on failure — no more silent missed backups

What makes it similar to a bash cron job: it’s small, it’s young, and the community around it is thin. If it breaks, you’re mostly on your own.

---

Why people choose it

No independent third-party reviews of Velld were found at the time of writing. The project has 467 GitHub stars and does not appear in any major self-hosted tool roundups, Reddit threads, or comparison articles yet. The analysis below is based on the GitHub repository, official documentation, and the product itself [1][2].

The typical person who would reach for Velld is running a small production database — a Postgres instance backing a SaaS side project, a MongoDB for a client app — and currently has one of three bad situations:

1. No backup at all. Running without backups because setting up pg_dump on a cron felt complicated and you haven’t gotten around to it.
2. Manual backups. Downloading dumps occasionally, storing them locally, losing track of what you have.
3. Overengineered setup. Scripts, S3 CLI commands, CloudWatch alarms, and email alerting duct-taped together and fragile.

Velld replaces all three scenarios with a UI that takes 10 minutes to deploy. The trade-off is that you’re trusting a 467-star project with your backup infrastructure, which is a real consideration — more on that in Pros/Cons.

---

Features

Based on the GitHub README and official documentation [1][2]:

Database support:

• PostgreSQL 9.6+
• MySQL 5.7+ and MariaDB
• MongoDB 4.0+
• Redis

Backup management:

• On-demand and scheduled backups (cron syntax)
• Multiple databases per connection
• Customizable retention policies — auto-delete old backups
• Backup file compression
• Connection testing before saving

Storage:

• S3-compatible storage integration — works with AWS S3, Backblaze B2, MinIO, Cloudflare R2, or anything S3-compatible

Monitoring and notifications:

• Real-time backup status on the dashboard
• Success rate tracking
• Storage usage metrics
• Email notifications for failed backups
• Detailed backup history log

Recovery:

• Download backup files from the UI
• Restore using standard database tools (Velld doesn’t wrap the restore process — you download the file and use pg_restore, mongorestore, etc.)

Advanced:

• Backup comparison with diff viewer — split and unified diff views, line-by-line change tracking [2]
• Encrypted credential storage
• RESTful API access

What’s missing (compared to enterprise backup tools):

• No point-in-time recovery (PITR) — this does full/logical dumps, not WAL streaming
• No restore-to-different-host workflow built in
• No backup integrity verification
• No compression format choices documented
• No webhook notifications — only email [2]

The diff viewer is the feature most likely to surprise you. The ability to open two backup files and see exactly what changed between Thursday’s backup and Friday’s backup is genuinely useful for understanding data drift, debugging regressions, and auditing. Most tools in this category don’t have it.

---

Pricing: SaaS vs self-hosted math

Velld itself is $0. MIT license, self-host it yourself [1].

Competing managed services for context:

• SimpleBackups: starts around $9–$15/mo for a single database, scales with storage and frequency
• Snapshooter: $10/mo base, $2–5 per additional database
• Pitr.dev / similar: $15–50/mo depending on database size and frequency
• AWS Backup + RDS snapshots: “free” in theory but you pay for storage (~$0.095/GB/mo for snapshot storage in us-east-1) plus setup complexity
• Cloudflare R2 + manual script: ~$0/mo for small datasets (R2 is free up to 10GB), but you build and maintain the script

Self-hosted Velld cost breakdown:

If you’re already running a VPS: the incremental cost is essentially zero. Velld runs alongside your app on the same server. Storage is whatever your S3-compatible storage costs — for most small databases, well under $1/mo.

If you’re spinning up a dedicated instance: a $4–6/mo Hetzner CX11 or DigitalOcean Droplet handles Velld comfortably. Plus S3 storage costs.

Concrete example: Three databases (one Postgres, one MySQL, one Mongo), daily backups, 30-day retention, average dump size 500MB each.

• SimpleBackups: ~$20–30/mo
• Self-hosted Velld on existing VPS + Backblaze B2: ~$0.50/mo in B2 storage, $0 for compute (already paying for the VPS)
• Annual savings: $240–360/year

That’s the math. The catch is your time — both setup and any future troubleshooting.

---

Deployment reality check

The README’s install path is two commands [1]:

curl -o docker-compose.yml https://raw.githubusercontent.com/dendianugerah/velld/main/docker-compose.prebuilt.yml
# create .env
docker compose up -d

This is about as simple as self-hosted deployment gets. The prebuilt images mean you don’t need to build anything locally.

The .env setup has one gotcha the README explicitly flags [1]:

The ENCRYPTION_KEY must be a 64-character hex string, and you can’t put $(openssl rand -hex 32) directly in the .env file — shell expansion doesn’t happen in .env parsing. You run the command first, copy the output, paste it in. The README is upfront about this, which is a good sign.

What you actually need:

• A Linux VPS or local server with Docker and docker-compose
• An S3-compatible storage bucket (Backblaze B2 is the cheapest option for most people — $0/mo under 10GB)
• An SMTP provider for email notifications (Postmark or Mailgun free tier works)
• Optionally: a domain and reverse proxy (Caddy is the easiest) if you want HTTPS access from outside localhost

What can go sideways:

There is no community to troubleshoot with. Stack Overflow has no Velld questions. There are no Reddit threads, no YouTube tutorials, no Discord. If you hit a bug, you’re reading the source code or opening a GitHub issue and hoping the maintainer responds. For a backup tool — which you only care about deeply when something goes wrong — this is the most important caveat [1].

The restore workflow requires standard database CLI tools. Velld downloads the backup file for you, but you run pg_restore or mongorestore yourself. This is reasonable but means non-technical operators aren’t fully served — they’d need to know which tool to use and how.

Realistic time estimates:

• Technical user with Docker experience: 15–30 minutes to a running instance with backups scheduled
• Non-technical user following documentation: 1–2 hours, longer if S3 configuration is unfamiliar

---

Pros and cons

Pros

• Actually MIT-licensed. No “fair-code,” no “source-available,” no commercial restriction. You can self-host, modify, embed, fork — whatever you want [1].
• Genuinely easy deployment. Two commands to a running instance is not an exaggeration. The prebuilt Docker images do what they say [1].
• Backup diff viewer. Line-by-line comparison of two backup files is a feature that commercial tools charge for, and it’s included here [2].
• Multi-database in one UI. Postgres, MySQL, Mongo, Redis — monitored from one dashboard. Most alternatives require separate tools per database type [1].
• S3-compatible storage. Not locked to AWS — works with Backblaze B2, MinIO, Cloudflare R2, or anything S3-compatible, which keeps storage costs low [1].
• Encrypted credentials. Database credentials aren’t stored in plaintext — important if you’re handing this off or running on a shared server [2].
• REST API included. If you want to integrate backup triggering into your CI/CD or deployment scripts, the API is there [1][2].

Cons

• 467 stars, unclear contributor count. The project is new and lightly adopted. One primary contributor visible in the repository. This is existential risk for a backup tool — what happens if development stops? [1]
• No independent reviews or community. Zero third-party validation at time of writing. You’re trusting the README and documentation alone.
• No restore automation. You download the file, you run the restore. Not a dealbreaker for technical users, but means the “Fast recovery” homepage claim is aspirational — you still need to know what you’re doing [2].
• No PITR (point-in-time recovery). This does logical dumps. If you need WAL-based PITR for Postgres, look at pgBackRest or Barman instead.
• Email-only notifications. No Slack, no webhook, no PagerDuty. Just email [2].
• No backup integrity verification. The tool doesn’t verify that a backup can actually be restored. You’d need to test this manually.
• Young documentation. The docs cover the basics but don’t go deep on edge cases, performance tuning, or large database handling.

---

Who should use this / who shouldn’t

Use Velld if:

• You’re a developer running one or more small-to-medium production databases and currently have no backup automation.
• You want a web UI to monitor backup status without SSHing into servers.
• You’re already paying $15–50/mo for a managed backup service and the savings math makes sense.
• You’re comfortable with Docker and can troubleshoot without community support.
• MIT license matters to you — no vendor lock-in, no future license changes.

Skip it (for now) if:

• You need enterprise-grade reliability guarantees and vendor support. Use a managed service like SimpleBackups or your cloud provider’s native backup solution.
• Your databases are large (100GB+). Logical dump performance at that scale needs careful testing and isn’t documented.
• Your compliance requirements mandate point-in-time recovery. This tool doesn’t do WAL streaming.
• You’re non-technical and need a guided restore workflow — the restore step requires CLI knowledge.
• Community support is non-negotiable. The project has no active forum, Discord, or Stack Overflow presence.

Skip it (pick a specialized tool) if:

• You only run PostgreSQL and want PITR: use pgBackRest or Barman.
• You only run MongoDB and need incremental backups: use Percona Backup for MongoDB.
• You need general-purpose file + database backups: use Duplicati or Restic with custom scripts.

---

Alternatives worth considering

For database-specific backup automation:

• pgBackRest — Postgres-only, but industry standard for PITR, compression, and large database handling. No web UI, pure CLI. Free, open source.
• Barman — Another Postgres-only option from the same general category. Mature, well-documented, free.
• Percona Backup for MongoDB — MongoDB-specific, handles sharded clusters and replica sets properly. Free, open source.

For a UI-driven experience closer to Velld:

• Backrest — Restic-based backup manager with a web UI. More general purpose (not database-specific), active development, larger community (~7K stars).
• Duplicati — GUI-driven backup for files and databases, long-established, supports many storage backends. Dated UI but proven reliability.

For managed services (no self-hosting):

• SimpleBackups — Clean UI, multi-database, $9–15/mo per database, no infrastructure to manage.
• Snapshooter — Similar positioning, supports Postgres/MySQL/Mongo, connects to DigitalOcean/Vultr droplets natively.

For the specific feature of backup comparison: No other self-hosted tool in this category ships this out of the box. If backup diffing is your primary need, Velld is currently the only self-hosted option with it built in.

---

Bottom line

Velld does one thing: it puts a clean web UI on top of the database backup workflow you should already have but probably don’t. The deployment is genuinely easy, the MIT license is clean, and the diff viewer is a legitimately useful feature you won’t find elsewhere in self-hosted tools. For a developer with a production database and no backup automation, it clears the bar — get it running in 30 minutes and stop worrying about whether last night’s dump ran.

The honest caveat is that it’s a young project with a thin community and no third-party validation yet. For a backup tool specifically, that matters: you’re most likely to care about it when something breaks, and “read the source code” is cold comfort when you’re trying to restore a crashed database at 2am. If that risk profile concerns you, either wait 12–18 months to see if the project gains community traction, or pay for a managed service. If you’re comfortable being an early adopter on non-critical infrastructure, the tool earns its place.

---

Sources

1. Velld GitHub Repository — README, feature list, installation instructions, MIT license. https://github.com/dendianugerah/velld
2. Velld Official Documentation — Introduction, feature overview, database support matrix, restore workflow. https://velld.vercel.app/docs