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
Get it running
Decide where the database lives
Choose whether the database shares a host with the app or runs separately based on isolation, capacity and recovery needs. For containers on the same host, configure a private network explicitly; 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
Move the generated root password into your password manager, then create a limited user for each application with rights only on the database it needs. Keep root 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. Configure the engine’s supported transport encryption and restrict network access explicitly; 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 copies covered deployment files while the app is running. That alone does not prove transaction-consistent recovery of PostgreSQL, MySQL, MariaDB, MongoDB or Redis. Keep a native backup and 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.
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.