Communityoplossing

How to Use MariaDB or PostgreSQL with Nextcloud on ZimaOS

A ZimaOS 1.3.3 user asked for step-by-step guidance to make MariaDB or PostgreSQL work with Nextcloud. The thread received no technical solution, so current ZimaOS packaging behavior is important context.

What Was the Nextcloud Database Problem?

In April 2025, a ZimaOS 1.3.3 user reported that neither MariaDB nor PostgreSQL seemed to work as expected with Nextcloud and asked for a step-by-step configuration. A second user repeated the same question in January 2026, but the community thread never received a technical answer.

That means the original discussion does not establish a working database hostname, username, password, network, port, or volume configuration for connecting a separately installed database container to the ZimaOS Nextcloud package.

Are MariaDB and PostgreSQL Available on ZimaOS Today?

Yes. The current ZimaOS App Store lists MariaDB and PostgreSQL as installable database applications. ZimaOS also provides a Nextcloud package. However, installing these apps separately does not by itself wire one container into another application as a shared dependency.

For the current application model, see the ZimaOS App Store guide.

Why Doesn't a Separate Database Automatically Connect to Nextcloud?

Current ZimaOS developer documentation explicitly notes that shared services and pre-installed or recommended dependencies are not supported as an automatic App Store dependency model at this stage. Apps are generally packaged as self-contained Docker deployments, or their required services are included in the application's own compose definition.

This is the key limitation behind the original question: a MariaDB or PostgreSQL app can run successfully on ZimaOS while still being completely separate from the Nextcloud deployment.

What Has to Match for an External Database to Work?

Setting Why it matters
Database engine The Nextcloud deployment must support the database engine you choose.
Database host Nextcloud needs a hostname or container-network address that can actually reach the database service.
Port The database must listen on the expected MariaDB/MySQL or PostgreSQL port inside the relevant network.
Database name A database must exist or be created for the Nextcloud instance.
User and password The credentials entered in Nextcloud must match the database account and permissions.
Docker network Two separately installed containers must share a reachable network path before container hostnames can resolve between them.
Persistent storage Database files must remain on persistent storage through updates and container recreation.

What Is the Safer ZimaOS Deployment Path?

If you only want a working Nextcloud instance, start with the current packaged Nextcloud deployment instead of installing an unrelated database container first. If you specifically need an external MariaDB or PostgreSQL server, treat Nextcloud and the database as one planned stack and verify all environment variables, networks, credentials, and persistent paths together.

ZimaOS supports custom application installation for users who need to control a Docker deployment beyond the one-click package. For a database-dependent service, a complete upstream or AIO deployment is generally easier to reason about than two independently installed App Store entries whose dependency relationship is not defined.

Frequently Asked Questions

Does ZimaOS currently offer MariaDB and PostgreSQL?

Yes. Both are available as database applications in the current ZimaOS ecosystem.

Will installing MariaDB automatically make Nextcloud use it?

No. Separate App Store installations do not automatically create a database dependency or configure Nextcloud to use that database.

Did the original community thread contain a verified step-by-step fix?

No. The thread contained the question and a later user with the same requirement, but no confirmed configuration was posted.

Should I edit database or Nextcloud settings without knowing the current container network and persistent paths?

No. Confirm the current application configuration first so a change does not disconnect the database or place important data in non-persistent storage.