Using Managed Databases with the Resource Manager

Understand how Resource Manager fits managed databases, database users, and deployment targets into the hosting workflow.

Introduction

Use this tour when the project needs more than a server and you want the managed database side explained in Resource Manager terms. The goal is to connect provider-managed databases, database users, environment strategy, and the handoff into the rest of the Wappler database workflow.

Provision the database service as infrastructure first

Manage database users alongside the service

Keep provider database setup distinct from app schema design

Managed databases belong in the hosting plan

A managed database is part of the deployment architecture, not just an afterthought once the app is done. Resource Manager is where that hosted database service becomes part of the same infrastructure story as the server and target path.

`Add New Database` and `Add New User` are operational hosting actions

The Add New Database and Add New User actions belong to provider-managed resources because they prepare the database service the app will rely on later. These actions are about provisioning and access on the hosting side, not yet about table design or migrations inside the app schema.

Create the hosted database resource first

Create the users or credentials that should access it

Do the app-schema work only after this operational layer exists

Resource Manager provisioning is not the same as schema design

Keep two different jobs separate. Resource Manager prepares the provider-managed database service and its users. Database Connections and Database Manager are where you connect the app to that service, design tables, and manage migrations. Mixing those layers makes the deployment story harder to reason about.

Resource Manager provisions the hosted database service

Database Connections attach the project to that service

Database Manager handles tables, fields, seeds, and migrations

Environment strategy still matters for managed databases

The same target strategy rules apply here as with other databases. Small solo workflows may tolerate a simpler shared setup, but team, staging, or release-oriented projects are usually safer when development and production point to separate managed databases or separate users and credentials per environment.

Separate environments reduce accidental live impact

Credentials and users should match the target they serve

Managed databases still need the same release discipline as self-hosted ones

Next steps

Return to the Resource Manager hub when you are ready for the next panel subject. That keeps the Resource Manager path sequential and makes the panel hub the place where the next topic is chosen.

Open the Database Manager lifecycle for schema and migrations

Return to the cloud-server lifecycle for the full hosting picture

Continue into database connection setup when the service is ready