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 7 for document storage, single-node
- Redis 7 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 do not use the web-app HTTPS certificate or Tor mirror flow. Each database install has its own TLS certificate; still restrict network access explicitly. New Redis installs require TLS and do not accept plaintext on the same port. Redis installs made before this default keep their existing setting. A website certificate does not secure a separate database connection.
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. Other engines and unsupported configurations 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.
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.