Host a database engine on an offshore VPS and control its configuration, access and maintenance. Choose the supported catalog engine for your application, and plan resources and recovery before moving production data.
What is available
- PostgreSQL and MySQL 8, the defaults for most application stacks
- MariaDB 11, wire-compatible with MySQL, community governed
- MongoDB 8 for document storage, single-node
- Redis 8 for cache, queues, sessions and pub-sub, with persistence on and TLS required on new installs
Get it running
Decide where the database lives
Choose placement based on isolation, capacity and recovery needs. The managed PostgreSQL/MariaDB connection workflow requires the app and provider on the same server and in the same project environment. Other layouts need their own networking plan; a container loopback address does not reach another container.
Install the engine
Install your engine from the catalog. The root password is generated (20 characters) and shown in the panel; MySQL and MariaDB also arrive with an appdb database ready to use.
Lock the port down before you connect anything
If the database has to be reachable from another machine, restrict the port with the firewall to that machine’s address only. An open 5432, 3306, 27017 or 6379 is found by scanners, not by luck.
Create a user per application
For an eligible image-mode custom app, review a managed PostgreSQL or MariaDB connection to create its dedicated database and login. The agent receives the managed connection without asking you to paste the provider administrator password. For other setups, create a limited user for each app and keep administrator credentials for administration.
Keep database ports private whenever possible. If another server must connect, allow only the required sources, use appropriate authentication and configure transport encryption where supported. For applications on the same host, choose a private container network or a deliberately configured local endpoint; do not assume a container loopback address reaches another container.
These catalog database deployments use their own TLS certificates, separately from the web-app HTTPS certificate and Tor mirror flow. Restrict database access explicitly: website HTTPS does not secure a separate database port.
On the current PostgreSQL recipe, enabling TLS required refuses unencrypted network connections before custom client rules can allow them, including physical replication. Review the provider’s connection card and compatible client settings. TLS does not replace authentication or firewall rules. Read the PostgreSQL connection guide for the managed workflow.
For published non-HTTP ports, Inbound access lets you restrict new external connections to selected IPv4/IPv6 source ranges per TCP or UDP port. Ports start open: confirm the rule and wait for enforced before relying on it. Keep authentication and TLS; the allowlist does not filter existing sessions or local container traffic.
New Redis installs also require TLS. Existing database deployments are not automatically reconfigured by a recipe update, and Redis installs made before its required-TLS default keep their existing setting. Review an older deployment before relying on the current recipe’s safeguards.
The Redis install keeps an append-only file so data survives a restart. If you are using it as a pure cache and would rather not persist anything, turn that off in your own configuration.
These are single-node deployments. Define recovery requirements for the actual database engine and version, and use its supported backup procedure. Replication and persistence solve different problems from backup; neither replaces a tested recovery point.
The Impreza app backup flow covers supported deployment files and adds verified engine-native dumps for eligible managed PostgreSQL/MariaDB bindings. A file copy alone does not prove database consistency. Eligible standalone PostgreSQL, MySQL, MariaDB and MongoDB catalog apps also support a separate verified logical-export backup. Redis and unsupported configurations still need their own native backup procedure. Validate representative data and application connections. For a move between compatible deployments, check version/schema compatibility and plan new writes and the final traffic switch separately.
Verified backups for standalone database apps
Back up an eligible standalone PostgreSQL, MySQL, MariaDB or MongoDB catalog app through the portal, API or MCP. The export must pass restoration into an isolated verification database before backup success and upload to your Impreza S3 storage. The deployment must reference the exact supported database image by digest; older installations can require support maintenance without a version upgrade.
Consistency remains engine-specific: PostgreSQL snapshots are per database, MySQL/MariaDB support InnoDB, and MongoDB standalone does not provide a point-in-time snapshot across collections. Restoring this format replaces the target app’s database data and interrupts service. It is separate from the binding recovery below, does not cover bundled databases inside other apps and does not add automatic failover. Follow verified database app backups for limits and the restore checklist.
Reviewed connections for PostgreSQL and MariaDB
Eligible image-mode custom apps can use a managed database connection to a PostgreSQL or MariaDB catalog provider on the same server and project environment. Review the target and confirm before applying. The platform delivers DATABASE_URL to the agent rather than returning it through the portal or MCP.
PostgreSQL uses separate ownership and login roles; MariaDB uses dedicated logins with grants scoped to the managed database. Rotation and removal have their own reviews and health requirements. Neither is a request to delete the database. These operations do not apply automatically to native MySQL, MongoDB, Redis or apps built from source recipes.
Read the PostgreSQL guide or the MariaDB guide before choosing the setup. These are operations on your server, not a promise of a fully managed DBaaS service.
Verified recovery into a new database
With agent 0.6.18+ and matching capabilities, eligible managed bindings add an engine-native dump and mandatory temporary restore verification to app backups. Recovery uses a new database, leaving the serving database and app connection unchanged until you plan a separate switch.
MariaDB verification supports InnoDB tables only and refuses views, triggers, routines, events and other table engines. Database and filesystem backups are not one atomic snapshot. This completed-dump workflow does not offer a point between dumps or automatic cutover. Use the dump recovery guide to review the source, target and application checks.
Eligible managed PostgreSQL bindings also have a separate point-in-time recovery workflow that saves base backups and WAL to the account’s Impreza S3 storage. Its reviewed restore creates another database; it does not repoint the application. This is PostgreSQL-specific, not a general promise for every database engine or deployment.
Check the database from the application
For supported deployments with the Impreza Agent online, use app inspection and maintenance to inspect status and logs. Discover the operations exposed for the selected deployment; do not assume the platform provides every native database command.
Validate a representative application query and its limited database user after maintenance. Monitor storage growth and connection pressure alongside container status. Keep the engine-specific recovery procedure above: an application health check is not a recovery test.
Start now
Spin up an offshore VPS and install your engine from the catalog, or read the documentation.