DatabasesEverywhere overview

DatabasesEverywhere is a database-hosting daemon designed to sit behind a panel. It gives customers isolated databases without giving them an entire server, while the panel remains responsible for users, billing, and customer-facing records.

Start here

Install a node to prepare Docker or Podman, install the daemon, and start its service.
Configure the node to set secrets, images, capacity reserves, storage paths, and backups.
Integrate the API to create and manage database instances from a panel.
Add data operations for imports, exports, backups, downloads, and recovery.
Add live monitoring with scoped WebSocket tokens, metrics, and health checks.

What it provides

Seven supported database engines.
Database imports and exports.
Manual and automatic physical backups.
Live WebSocket monitoring and log streams.
Image updates and assisted major-version upgrades.
Per-instance CPU, memory, PID, and disk limits.
Node-wide allocation and host-pressure metrics for schedulers.
Reserved memory and disk headroom to protect the host.
Signed, short-lived artifact download links.
Local SQLite metadata with no additional control-plane database.

Supported databases

PostgreSQL

PostgreSQL uses its native TCP protocol at the public gateway and logical SQL dumps for portable exports.

MariaDB and MySQL

MariaDB and MySQL use their native TCP protocols. MySQL is a distinct protocol and uses the supported mysql:8.4 LTS baseline.

Redis

Redis uses RESP at the gateway. Its exports and backups are physical archives rather than logical SQL-style dumps.

MongoDB

MongoDB uses the MongoDB wire protocol and native archive dumps. MongoDB and ClickHouse instances require at least 1024 MiB of memory and 1024 MiB of disk.

ClickHouse

ClickHouse supports native TCP and HTTP internally. DatabasesEverywhere exposes it through an isolated, hash-verified socket bridge.

Qdrant

Qdrant uses gRPC and physical snapshot-based data operations. Its isolated container is reached through the same socket-bridge design as ClickHouse.

Isolation model

Every database instance runs in its own container with network_mode=none. Containers do not receive a network interface and never publish backend ports.

The daemon exposes one public gateway listener per database protocol and routes authenticated traffic to the correct private Unix socket. ClickHouse and Qdrant use a statically linked, hash-verified bridge that can connect only to non-zero loopback targets and can create sockets only under /run/dbev.

Remote imports use short-lived acquisition workers. The target database container stays network-isolated throughout the operation.

Legacy bridge-network or TCP-backed instances are not silently converted. On upgrade they are stopped and quarantined so an operator can preserve the data, delete the old instance explicitly, recreate it, and import the preserved artifact.

Resource protection

Each instance receives explicit CPU, memory, PID, and disk limits. The node also reserves memory and disk outside the customer allocation pool so creating or enlarging an instance cannot consume the host's final operating headroom.

Disk enforcement is selected automatically on every boot. Btrfs, ZFS, and project-quota-enabled XFS, ext4, or f2fs use native quotas. Other supported filesystems use the bundled FuseQuota helper. There is no unprotected fallback mode.

Runtime support

Docker is the production-ready container runtime.
Podman is available through its Docker-compatible API and is ready for testing in rootful and rootless modes.
A direct systemd instance runtime is planned; the DatabasesEverywhere daemon itself already runs as a systemd service.
Official binaries support x86-64, ARM64, and RISC-V 64 Linux with glibc 2.35 or newer.
Windows is not a daemon target because the service depends on Linux containers, Unix sockets, cgroups, and filesystem quota facilities.

Panel and daemon responsibilities

The panel owns customers, permissions, billing, and the mapping between a customer record and an instance_id. The daemon owns containers, runtime metadata, gateways, limits, artifacts, and backups.

The two communicate over an authenticated JSON HTTP API. Browser-facing live data uses short-lived, scoped WebSocket JWTs so the node token never needs to be exposed to a customer.

Security reporting

Do not disclose a vulnerability in a public issue. Report it privately through GitHub Security Advisories or a private Discord ticket, and confirm it reproduces on the latest release.

Development commands

Run the complete test suite and create a release build with:

bash

cargo test --all-targets
cargo build --release

For local configuration checks and daemon development:

bash

cargo run -- --config config.local.yml check-config
cargo run -- --config config.local.yml daemon

The explicit Linux-oriented aliases used by CI are:

bash

cargo check-linux
cargo test-linux
cargo build-linux