Book a demo
Book a demo
Login

Operations PostgreSQL + Docker workloads

Operate a self-hosted database workload

Review exposure, backup strategy, access, version changes, and restore validation. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A team runs a PostgreSQL one-click workload for an internal app. It needs least-privilege access and a logical backup whose restore succeeds independently of a container snapshot.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Identify the running database

Where
xCloud Docker site and PostgreSQL server
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Template, PostgreSQL version, volume path, listen address
Action
Confirm the actual database template, version, storage and network exposure. Record application dependencies and current error status.
Expected result
A concrete instance and exposure map.
Verify
Compare app connection target with configured host/port without revealing passwords.
If it fails
If the database is publicly exposed unintentionally, restrict access before other work.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · PostgreSQL database roles

Step 2 of 5

Review roles and grants

Where
PostgreSQL role catalog and app connection config
Permissions
Authorized Postgresql application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
App role, database, schema, allowed operations
Action
List roles and privileges. Use a dedicated test/app role with only needed CONNECT, schema usage and table rights; avoid superuser shortcuts.
Expected result
A least-privilege access plan.
Verify
Run an allowed SELECT and a denied operation with the test role.
If it fails
If the role can modify unrelated schemas, reduce grants and retest.

Sources: PostgreSQL database roles · PostgreSQL SQL dump and restore

Step 3 of 5

Create a logical recovery point

Where
PostgreSQL pg_dump and secure backup storage
Permissions
Authorized Postgresql application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Database name, dump format, storage, maintenance owner
Action
Using authorized database credentials and the version-appropriate client, create a pg_dump archive or SQL dump. Protect it and separately record cluster roles required for restore.
Expected result
A PostgreSQL-consistent logical backup with timestamp.
Verify
Check dump command exit status, file size and format; never log credentials.
If it fails
If dump fails, fix permissions/storage and do not substitute an unverified raw copy.

Sources: PostgreSQL database roles · PostgreSQL SQL dump and restore

Step 4 of 5

Restore into isolation

Where
Separate PostgreSQL test instance
Permissions
Authorized Postgresql application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Dump, test roles, empty target database
Action
Create an empty isolated target with required roles, restore with psql for plain SQL or pg_restore for an archive, then compare schema and selected row counts.
Expected result
A demonstrated database restore.
Verify
Run representative app read and write tests against the test DB only.
If it fails
If ownership or extensions fail, correct test prerequisites and update runbook.

Sources: PostgreSQL database roles · PostgreSQL SQL dump and restore

Step 5 of 5

Set ongoing operations

Where
xCloud Docker Backup and database runbook
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Dump cadence, volume snapshot, upgrade window
Action
Document both Docker snapshot scope and logical dump schedule, credential rotation, access review and upgrade rehearsal. Test recovery after version changes.
Expected result
A database-specific maintenance owner and recovery path.
Verify
Check latest dump and Completed Docker backup independently.
If it fails
If app and DB snapshots have different times, define reconciliation before restoring either.

Sources: Back up and restore Docker apps · Docker backup operations and storage constraints · PostgreSQL database roles

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized Postgresql administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases