macOS - Software Lifecycle - Install DBeaver Community

What the DBeaver deployment Worklet does

This Automox Worklet™ deploys DBeaver Community Edition to macOS endpoints without user prompts. DBeaver is a free, open-source universal SQL client that supports MySQL, PostgreSQL, MariaDB, SQLite, Oracle, SQL Server, Snowflake, Redshift, BigQuery, and any other database that exposes a JDBC driver. Shipping a single client to every developer and database administrator eliminates the patchwork of vendor-specific tools that otherwise grows across a fleet.

The Worklet checks for /Applications/DBeaver.app, retrieves the DMG from the Automox software cache, mounts the image with hdiutil attach, copies the DBeaver.app bundle into /Applications using cp -vrp, then detaches the volume and validates the result. The runtime is the bash interpreter on the endpoint, invoked by the Automox agent, so no logged-in user session is required.

Because the evaluation phase is idempotent, scheduling this Worklet on a recurring policy is safe. Endpoints that already have DBeaver report compliant on the next run and skip remediation. Endpoints where a user moved DBeaver out of /Applications, or where the app was never installed, are flagged and brought back into the baseline on the next evaluation window.

Why deploy DBeaver across your macOS fleet

Database administrators and data engineers typically connect to several database engines across a normal week, mixing Postgres, MySQL, Snowflake, Redshift, Oracle, and SQLite. Without a standardized client, each engineer installs whatever their preferred vendor ships. The support surface fragments across pgAdmin, MySQL Workbench, Sequel Pro, SQL Developer, and ad-hoc CLIs, and the security team inherits a list of unmanaged tools to track. DBeaver Community collapses that list to one signed application backed by a single set of JDBC drivers.

Scope this Worklet to your macOS endpoint group, and every new hire, every reimaged machine, and every endpoint that drifts out of compliance receives DBeaver back in /Applications on the next evaluation without manual operator work.

How DBeaver deployment works

1. Evaluation phase: The Worklet runs evaluation.sh, which tests whether /Applications/DBeaver.app exists as a directory ([[ -d /Applications/DBeaver.app ]]). If the bundle is present the script echoes a compliance message and exits 0, so the endpoint is reported compliant in Automox and no remediation runs. If the directory is missing, the script exits 1 and Automox schedules the remediation script for the next policy window or the next FixNow invocation.

2. Remediation phase: remediation.sh re-checks /Applications/DBeaver.app and short-circuits if the app is already present. Otherwise it calls /usr/local/bin/wdk ottopm download DBeaver to pull the signed DMG from the Automox software cache, parses the downloaded_file_path out of the JSON result with /usr/local/bin/wdk ottoq, then runs hdiutil attach on the DMG, copies /Volumes/DBeaver Community/DBeaver.app into /Applications with cp -vrp, and detaches the volume with hdiutil detach (with a 5-second retry if the first detach reports the disk is busy). A final [[ -d /Applications/DBeaver.app ]] check returns exit 0 on success or exit 1 with an Activity Log message on failure.

DBeaver deployment requirements

• macOS 10.15 (Catalina) or later, Intel or Apple Silicon (DBeaver ships a universal binary)

• Automox agent 1.42.22 or later (the script depends on the wdk ottopm and wdk ottoq tooling shipped with that release)

• Network reachability to the Automox software cache from the endpoint

• Root context for the Automox agent (the default agent context already meets this; hdiutil attach and writes to /Applications require it)

• Free disk space on the system volume for the DMG plus the extracted application (~500 MB headroom is sufficient)

• DBeaver Community ships its own bundled OpenJDK runtime under DBeaver.app/Contents/Eclipse/jre/, so no separate Java install is required on the endpoint

Expected state after DBeaver deployment

After a successful remediation, /Applications/DBeaver.app exists on the endpoint and launches without prompting for Java. The application bundle is owned by the user that the cp -vrp ran under (root in the default agent context), so Gatekeeper recognizes the signed bundle on first launch and macOS does not quarantine it. Subsequent policy runs report the endpoint compliant on evaluation alone and the remediation script does not re-run, which keeps Activity Log noise low.

Validate the deployment from the macOS Terminal with ls -la /Applications/DBeaver.app, mdls -name kMDItemVersion /Applications/DBeaver.app to confirm the installed version, and codesign -dv --verbose=4 /Applications/DBeaver.app to verify the signature is intact. For audit evidence, capture the Automox Activity Log entry for the policy run together with the codesign output; together they show both that the install ran and that the bundle on disk is the one the Worklet placed there.