Workspace configuration export retains absolute file paths—how to make it portable?

To make a DBeaver workspace portable, you must use a post-export script to replace absolute paths within the metadata files, as DBeaver does not offer a built-in 'relative path' export option.

Why absolute paths are retained

DBeaver is built on the Eclipse RCP framework. When you export a workspace, the connection metadata and resource locations are stored in .metadata/.plugins/org.eclipse.core.runtime/.settings. These XML files often contain absolute paths to drivers, scripts, and local configurations (e.g., /home/user/.dbeaver/...). When this folder is mounted into a Docker container with a different filesystem structure, DBeaver fails to resolve these resources.

Steps to make the configuration portable

Since there is no native toggle to rewrite paths during export, the most effective method is to use a script to standardize the paths after export but before deployment:

1. Identify the target files: Locate the .xml files within the .settings directory of your exported workspace.
2. Perform path replacement: Use a tool like sed to swap the host-specific absolute path with a placeholder that matches your container's mount point.

# Example: Replacing a home path with a container-internal path
sed -i 's|/home/host-user/.dbeaver|/opt/dbeaver|g' workspace_export/.metadata/.../*xml

3. Standardize the Docker mount: Ensure your Docker volume maps the workspace to the exact path defined in your script (e.g., `/opt/dbeaver`).

Global network timeouts

DBeaver does not provide a single global setting to enforce network timeouts across all JDBC connections because timeouts are governed by the specific JDBC driver implementation (e.g., PostgreSQL uses loginTimeout, while MySQL uses connectTimeout).

To enforce consistent policies across a team, consider:

• Connection Templates: Creating a base connection template with the desired driver properties pre-set and sharing that template via the workspace.
• Environment Variables: Using environment variables in the connection properties if the driver supports them, allowing the container to inject the timeout value at runtime.

Diagnostic detail needed: To provide a more specific regex for path replacement, could you confirm if you are using custom local scripts or primarily driver-based connection paths?