# Portabase self-hosted backup and restore for databases and volumes

> Portabase is a self-hosted TypeScript dashboard for scheduling and managing backups across common databases and Docker volumes. Its main constraint is that Redis and Valkey support backup but not restore.

**Portabase/portabase** — Portabase - Database backup & restore tool for PostgreSQL, MySQL, MsSQL, MariaDB, Firebird SQL, SQLite, MongoDB, Redis and Docker Volume 

- Repository: https://github.com/Portabase/portabase
- Website: https://portabase.io
- Stars: 1,850 · Forks: 138
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/portabase-portabase

## Portabase's backup scope and intended operators

Portabase addresses the operational problem of creating, scheduling, and restoring backups when an installation uses more than one storage engine. A team might have PostgreSQL for application records, Redis for caching, MongoDB for documents, and Docker volumes for persistent service state. Managing each workflow with unrelated scripts can leave credentials, schedules, retention, and recovery status in separate places. Portabase puts those operations behind one self-hosted dashboard and works with separate Portabase agents for database operations.

The target users are operators, DevOps engineers, and administrators responsible for recovery procedures. Portabase is also relevant to teams that host databases in containers but want a common control plane outside each database container. It is not presented as a database server, query client, or general-purpose replication system. Its responsibility begins with backup and restoration.

The documented stable support is broad, but its scope is not unlimited. PostgreSQL covers versions 12 through 18, MySQL covers 5.7, 8, and 9, MariaDB covers 10 and 11, MongoDB covers 4 through 8, SQLite covers 3.x, Firebird covers 3.0, 4.0, and 5.0, and Microsoft SQL Server covers 2017, 2019, 2022, and Azure SQL. Redis 2.8+ and Valkey 7.2+ are also listed as stable. Docker Volume support requires Docker Engine 20.10 or later.

## How Portabase separates dashboard operations from agents

Portabase uses a web dashboard as its control surface and Portabase agents as the components that manage database operations. That separation lets the dashboard coordinate backup work while the database-facing component executes commands with access to the relevant server or container. The README describes agent integration as the mechanism for handling operations securely and efficiently, although this installation overview does not publish a complete protocol or deployment walkthrough.

The repository layout places the dashboard in a TypeScript and Next.js application. The root `package.json` defines the Next.js development and production commands, while `drizzle.config.ts`, `src/`, `app/`, and `components/` indicate an application backed by a relational metadata store managed with Drizzle. The development Compose file provisions PostgreSQL 17 on host port `5433`. It also defines `tusd`, Mailpit, Azurite, and a fake Google Cloud Storage server, which indicates that the development environment exercises uploads, mail, and multiple object-storage implementations rather than storing every artifact in one backend.

The database listing distinguishes backup support from restoration support. PostgreSQL, MySQL, MariaDB, MongoDB, SQLite, Firebird, MSSQL Server, and Docker Volume have restore marked as supported. Redis and Valkey do not. Consequently, Portabase can produce backups for those two cache-oriented engines without providing a documented in-product path back into Redis or Valkey.

## Database and Docker Volume backup boundaries

Portabase is most useful when an operator wants backup policy handled consistently across several engines, but support should be checked at the engine and version level. The README directs users to the Database Servers documentation for version-specific backup and restore details. That qualification matters because the support table establishes an engine range, while the underlying backup format and restore method can vary by database release.

Docker Volume backup addresses a different kind of state from a logical database dump. The project lists Docker Engine 20.10+ and marks Docker Volume restore as supported, but the overview does not describe file-level consistency, open-file handling, volume discovery, or coordination with an application quiesce step. Those details cannot be inferred from the support label. Operators with live databases may need an application-specific way to pause writes before taking a volume snapshot, although the repository excerpt does not confirm whether Portabase performs that step.

Redis and Valkey are the clearest boundary. A backup-only listing is useful for retaining cache data, but it does not satisfy a complete recovery requirement. Teams whose Redis data is authoritative should treat Portabase as incomplete for that workload unless they already have a separate, tested restoration process. The same limitation applies to Valkey 7.2+.

## Portabase development installation and first launch

The README recommends Docker and offers an automated CLI, Docker Run, Docker Compose, Unraid Community Apps, and Kubernetes with Helm. It links each route to the Portabase installation documentation but does not include the commands for those production routes in the repository overview. For a source-level first use, the repository exposes a development Make target and pnpm scripts.

The development cluster target runs the repository's development entrypoint. The Makefile binds that operation to `docker/entrypoints/app-dev-entrypoint.sh`, which should start the supporting services before the application is launched:

```bash
make up
```

The `package.json` defines the development server on port `8887` and uses Next.js with Turbopack. The repository defines this development script:

The local project URL is also fixed in the environment example as `http://localhost:8887`. After the process starts, the reader should open that address. The example environment defines a local PostgreSQL metadata connection and default administrator values, but the visible `.env.example` excerpt does not provide a copy command, so it would be inaccurate to invent one.

For a production deployment, use the documented Docker Run or Docker Compose instructions rather than treating the development cluster as an installation package. The development Compose file contains `latest` images, local credentials such as `changeme`, mail and storage simulators, and host ports intended for development. Those settings are evidence about the development architecture, not a production security template.

## Portabase versus independent database-native tooling

The practical alternative is to use each database engine's native backup utility in its own scripts or automation service. PostgreSQL, MySQL, MongoDB, Firebird, MSSQL, and other engines ship mechanisms tailored to their own formats and versions. An operator can schedule those utilities with cron, a CI runner, Kubernetes jobs, or an orchestration platform, then send outputs to object storage according to that platform's rules.

The approach differs in control-plane design. Native scripts can avoid running a central dashboard and a Portabase agent, and they may provide direct access to engine-specific options without translating commands through Portabase. Portabase instead groups supported engines under a self-hosted interface and uses agents for execution. That is useful for heterogeneous estates and operators who prefer a shared backup catalog. It also adds components that must be deployed and connected.

Neither approach should be selected solely from the number of supported engines. A single-database operator may get less value from Portabase's common interface. A multi-engine operator should compare restore behavior, object-storage destinations, encryption requirements, scheduling semantics, and failure notifications against the native tools already used in production. The repository excerpt does not document encryption settings, retention policy syntax, or notification channels, so those points require verification rather than assumption.

## Portabase release activity, upgrades, and licence implications

The repository is not archived, and its last push was on 2026-10-13. The release record also shows version 1.32.0 on 2026-10-13, version 1.31.1 on 2026-10-11, and version 1.31.0 on 2026-09-29. These facts indicate recent development, but they do not define the upgrade procedure or compatibility policy between Portabase and its Rust agents.

The repository links a separate `Portabase/agent-rust` project. Version-specific database behavior may depend on that agent, and release pairing should be checked before an upgrade. Release 1.32.0 is associated with MSSQL backup as DACPAC and restoration over an existing database. That release note is feature-specific, not a general migration guarantee.

Portabase is licensed under `Apache-2.0`, and the README says funded features remain open source under that licence. The source tree also includes a `LICENSE` file. Teams redistributing the software should review the licence text and notices applicable to their distribution. Existing database licences and agent components are separate from the dashboard licence and are not addressed by the repository overview.

## Operational checks before adopting Portabase

The first adoption check should be the recovery requirement, not the dashboard appearance. The support table makes a sharp distinction between engines with restore support and those with backup only. Redis and Valkey therefore need a separate recovery path if their data must be returned to service from a Portabase backup. For every other listed engine, the Database Servers documentation is the stated source for version-specific details.

Deployment also involves more than running the dashboard. The architecture links it to Portabase agents, so network reachability and permissions must be established between the relevant components. The visible repository configuration does not document the complete agent enrollment flow, so no flag, enrollment token, or network port should be assumed.

Finally, Docker Volume backup should be treated as a storage operation rather than automatically equivalent to a consistent database dump. The excerpt does not state how Portabase handles concurrent writes. A production evaluation must therefore confirm the intended backup method for each workload, perform restoration into an isolated destination, and compare the result with the service's own consistency rules. Those are specific recovery checks for Portabase's supported engines, not assumptions inferred from its broad support table.

## Conclusion

Portabase suits operators who want a self-hosted dashboard, agents, scheduled backups, and supported restore operations without writing a separate wrapper for each database engine. It is a poor fit for environments that require Redis or Valkey restoration through Portabase. Before adoption, verify your exact engine version, required destination, agent connectivity, and the relevant entry in the version-specific Database Servers documentation.

## FAQ

### Which databases and storage types can Portabase back up?

Portabase lists stable backup support for PostgreSQL, MySQL, MariaDB, MongoDB, SQLite, Redis, Valkey, Firebird, Microsoft SQL Server, and Docker Volume. Supported versions differ by engine and are shown in the README support table.

### Can Portabase restore Redis and Valkey backups?

No. The README marks backup support as stable for Redis and Valkey, but its support table marks restore as unsupported for both engines.

### How is Portabase installed for self-hosting?

The README lists an automated CLI, Docker Run, Docker Compose, Unraid Community Apps, Kubernetes with Helm, and a development setup. Docker must be installed before following the documented setup routes.

## Sources

- [License: Apache-2.0](https://github.com/Portabase/portabase/blob/main/LICENSE)
- [Portabase/portabase on GitHub](https://github.com/Portabase/portabase)
- [Project website](https://portabase.io)
- [README](https://github.com/Portabase/portabase/blob/main/README.md)
- [Releases](https://github.com/Portabase/portabase/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/portabase-portabase