How to Self-Host CloudBeaver in 2026: Database Drivers, Workspace and Access

The shortest CloudBeaver demo proves that a process listens on port 8978. Production needs stronger evidence. It must pass this scenario even after the container has been replaced: finish administrator setup, install the needed driver, connect by private hostname and execute a read-only query.

CloudBeaver is being deployed for a clear purpose: browser database client for Postgres, MySQL and more. Its most common deployment trap is that workspace permissions fail or container DNS cannot resolve database hosts, so public URL handling and durable state receive the same attention as image startup.

Restore CloudBeaver on an empty host

List the state before the first real record is created: workspace, users, connection definitions and credentials storage. Mount /opt/cloudbeaver/workspace before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Confirm the mount by writing harmless data, replacing CloudBeaver and reading it back.

Snapshots are valuable for quick rollback, but an independent backup is needed when the host or volume disappears. Restore into an empty environment with the pinned image and verify that workspace, users, drivers and connections return while every underlying database follows its own backup plan. Use persistent volumes and snapshots to keep those two recovery mechanisms distinct.

Launch CloudBeaver with observable defaults

The following command makes the container boundary visible without pretending to provision every external service.

docker run -d \
  --name cloudbeaver \
  --restart unless-stopped \
  -p 127.0.0.1:8978:8978 \
  -v cloudbeaver-data:/opt/cloudbeaver/workspace \
  -e CB_SERVER_NAME=CloudBeaver \
  dbeaver/cloudbeaver:latest

Before opening ingress, inspect the resolved environment, mounts and listener. Add the reviewed connection settings for private routes and database drivers for every target database; use private names for private services. A successful launch ends when you can finish administrator setup, install the needed driver, connect by private hostname and execute a read-only query, not when docker ps prints Up.

What CloudBeaver depends on

The CloudBeaver HTTP process listens on 8978; keep that port on the application network and publish only the platform route. The network contract for CloudBeaver is private routes and database drivers for every target database. Keep private endpoints on internal DNS, permit only required outbound calls and give CloudBeaver a scoped service credential.

Write the boundary down as a short contract: who owns the requirement, which credential is used, what timeout is acceptable and how failure appears. Then run this transaction: finish administrator setup, install the needed driver, connect by private hostname and execute a read-only query. Observe workspace state, driver downloads, concurrent sessions and network latency to each database during the run, because that workload gives a more useful starting size than an idle container.

Keep internal and external URLs straight

The public boundary for CloudBeaver should be one canonical hostname, automatic TLS and one internal target on 8978. Set the server URL and proxy headers for the public HTTPS origin so clients return to an address the service recognizes.

If the acceptance transaction fails, classify the first error. DNS, certificate and 502 problems belong to the TLS validation checklist. The condition “workspace permissions fail or container DNS cannot resolve database hosts” belongs to the application side after a request has successfully reached CloudBeaver.

A production acceptance run for CloudBeaver

Do not make first-user traffic the acceptance test for CloudBeaver. Prepare harmless sample state and run the complete action “finish administrator setup, install the needed driver, connect by private hostname and execute a read-only query”. Note the exact public URL, result, image reference and log interval associated with the run.

Replace the container and repeat without rebuilding data. Next, recover onto an empty host; the recovery condition is that workspace, users, drivers and connections return while every underlying database follows its own backup plan. Observe workspace state, driver downloads, concurrent sessions and network latency to each database in every pass and define an alert around degradation of the transaction rather than around idle container metrics.

One final check should fail on purpose: temporarily deny the test identity access to private routes and database drivers for every target database. Verify that the resulting CloudBeaver message identifies the relevant boundary instead of triggering data deletion or an endless restart. Restore the valid condition and confirm the same sample transaction succeeds. Keep this short drill in the release checklist.

Diagnose a healthy-looking CloudBeaver

The first useful operational metric for CloudBeaver is whether it can finish administrator setup, install the needed driver, connect by private hostname and execute a read-only query. Pair that with saturation signals for workspace state, driver downloads, concurrent sessions and network latency to each database. A process-only probe should not call expensive dependencies or restart the container because an upstream is briefly unavailable.

Treat upgrades as data changes because CloudBeaver workspace migrations and driver compatibility should be tested before changing image versions. Pin versions, rehearse on restored state and keep the previous image available until a rollback remains valid. When workspace permissions fail or container DNS cannot resolve database hosts, preserve logs from before the restart; they usually contain the causal message.

Security decisions specific to CloudBeaver

Do not inherit security assumptions from a local tutorial. CloudBeaver's specific concern is allowing anonymous access to production database connections. Production should therefore disable anonymous administration, use individual users and grant database accounts only the permissions each connection needs.

CB_SERVER_NAME controls behavior rather than confidentiality; validate its type and value, and store genuine CloudBeaver credentials separately. Scope filesystem and network access, protect setup endpoints and define upload, request or execution limits around workspace state, driver downloads, concurrent sessions and network latency to each database.

A Dockup deployment still needs an CloudBeaver acceptance test

Dockup's one-click CloudBeaver deployment should make replacement safe: the route continues to target 8978, secrets are not baked into the image and persistent paths return on the new container. The same deployment can run on Dockup compute or an attached machine.

Complete the app-specific work by connecting and testing private routes and database drivers for every target database, applying the canonical public address and running this acceptance check: finish administrator setup, install the needed driver, connect by private hostname and execute a read-only query. Add the restore result to the runbook before real users arrive.

Frequently asked questions

What does CloudBeaver need for a production deployment?

Route the CloudBeaver container on port 8978 through one HTTPS origin. The supporting network requirement is private routes and database drivers for every target database. Do not call CloudBeaver ready until you can finish administrator setup, install the needed driver, connect by private hostname and execute a read-only query.

Which CloudBeaver data belongs in a backup?

Persist /opt/cloudbeaver/workspace and include workspace, users, connection definitions and credentials storage in the same recovery manifest. A clean CloudBeaver restore passes only when workspace, users, drivers and connections return while every underlying database follows its own backup plan.

Does CloudBeaver require HTTPS behind a reverse proxy?

Use HTTPS for the public CloudBeaver origin and keep port 8978 on the internal route. Apply the CloudBeaver setting correctly: set the server URL and proxy headers for the public HTTPS origin. For CloudBeaver, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a CloudBeaver upgrade be tested?

Restore current CloudBeaver state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because CloudBeaver workspace migrations and driver compatibility should be tested before changing image versions. Keep the previous CloudBeaver image until its data-migration and rollback boundary are understood.