@commercient/dlake

The command-line client for Commercient Data Lake / Data Hub — a backend-as-a-service for Microsoft SQL Server. Point it at your ERP, CRM and database data and get instant REST and GraphQL APIs, row-level security, per-tenant API keys, and MCP access for AI agents — one governed database per customer.

dlake drives all of it from the terminal: sign up, build and expose schema, run SQL, export tables, manage keys, and administer the platform. Human-readable tables by default, --json everywhere for scripting, and agent skills that teach an AI assistant to use it correctly.

npm install -g @commercient/dlake
dlake register start --generate-password --email [email protected] \
  --company "Acme Co" --phone "+1 555 111 2222" \
  --consent-crm-backup --consent-erp-backup --consent-phone
# already have a tenant?
dlake login --domain mycompany --api-key dlk_...

Also published as datalake — the same CLI under a shorter name.

• Product overview: https://datalake-ms-dab.commercient.com/datalake/
• CLI reference and guides: dlake guide cli, dlake guide help
• Agent skills: dlake skills list, dlake skills install

Install

postinstall (install.js) resolves your platform to a runtime id (win-x64 / linux-x64 / linux-arm64 / osx-arm64 / osx-x64), downloads the matching binary into bin/, and bin/dlake.js execs it — forwarding argv, stdio, and the exit code.

The binary is 30–70 MB, so the install can take a few minutes; it prints the resolved platform, a progress line every 10 seconds, and the verified size when it finishes. npm install --silent suppresses that narration (warnings and failures are still printed).

That download is the package's install script. Newer npm versions skip install scripts for packages you have not allowed, leaving only an npm warning, so allow this one by name:

npm install -g --allow-scripts=@commercient/dlake @commercient/dlake

If a command answers "dlake binary not found" after an install, the download step did not run: repeat that install line, or run npm rebuild @commercient/dlake.

Windows PowerShell

• PowerShell's default execution policy blocks the .ps1 wrapper npm installs for global commands. Allow local and signed scripts for your own account once: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned.
• A bare leading @ is PowerShell's splatting operator, so quote @file arguments: --columns "@columns.json".

Agent skills

The CLI ships its own agent skills — they are embedded in the binary, so they need no network and no separate download:

dlake skills list                  # what is bundled, one line each
dlake skills install               # write them where your agent harness reads skills
dlake skills show dlake            # print one to stdout, no filesystem write

install auto-detects the harness directory ($CLAUDE_CONFIG_DIR/skills, then ~/.claude/skills, ~/.codex/skills, .opencode/skill) and tells you which it chose; --dir <path> names one explicitly. Existing files are refreshed — each one is reported as created, updated or unchanged — so re-running after an upgrade brings your skills up to date. Pass --skip-existing to keep local edits; the run then lists every file it left alone.

The twenty bundled skills teach an agent to drive this CLI: dlake (operating a tenant), dlake-integration-setup (standing up a new integration), dlake-normalsync (ERP table selection), dlake-odbcsync (the non-SQL-Server source agent), dlake-apisync (API sources), dlake-syncagent (the on-premises Sync Agent on the customer's own ERP server), dlake-crmpro (the forward sync leg) with a skill per destination — HubSpot, Salesforce, Shopify, Zoho CRM, Dynamics CRM, MDC and Magento — and dlake-txdownloaderpro (writeback) with a skill per source CRM — Salesforce, HubSpot, Dynamics CRM, Zoho CRM and Shopify.

A skill is a folder: its SKILL.md, plus any child pages beneath it. Each of the twelve destination skills carries one erps/<erp>.md child page per source ERP — 330 in all — listed in an ERP table in the parent’s own text. The parent is what an agent triggers on; the child is what it reads once it knows which ERP the tenant was registered with. dlake skills show <skill>/erps/<erp> prints one, and install writes every child beside its parent. The same skills are browsable on GitHub: dlake-cli/skills.

macOS

The macOS binaries ship code signed (since 0.5.2) — no post-install step is needed. If an older or cached download ever aborts intermittently at startup on Apple Silicon (System.AccessViolationException ... InitializeCulture), that is the signature missing: reinstall the package, or re-sign the binary once with codesign --force --sign - "$(npm root -g)/@commercient/dlake/bin/dlake".

Configuration

| Env var | Default | Purpose | |---|---|---| | DLAKE_DOWNLOAD_BASE | https://datalake-ms-dab.commercient.com/downloads/dlake | Binary mirror base URL | | DLAKE_VERSION | this package's version | Which binary version to fetch (may not be older — see below) | | DLAKE_SHA256 | — | Operator-pinned expected digest (64 hex); skips the manifest entirely | | DLAKE_ALLOW_MIRROR_CHECKSUMS | off | Trust a mirror's own SHA256SUMS (unsafe — see below) | | DLAKE_ALLOW_DOWNGRADE | off | Permit DLAKE_VERSION older than this package |

Download URL layout: <base>/<version>/<rid>/dlake[.exe].

Integrity / trust model

The downloaded binary is verified against a SHA-256 digest before it is made executable or moved into place, over HTTPS only, with redirects restricted to allowlisted hosts.

Where that digest comes from matters. Mirroring the binary with DLAKE_DOWNLOAD_BASE does not move the SHA256SUMS manifest: the manifest is always fetched from the canonical host (datalake-ms-dab.commercient.com), and the mirror's host is not even in the allowlist for that fetch. If both halves came from the mirror, the checksum would prove only that the mirror is self-consistent — anyone who can set the env var could serve a malicious binary and its matching digest. Splitting them means a mirror can only serve bytes the publisher already vouched for.

Two explicit escape hatches exist for installs that genuinely cannot reach the canonical host. Both print a warning banner:

• DLAKE_SHA256=<64-hex> — verify against a digest you obtained out of band. This is the recommended air-gapped option.
• DLAKE_ALLOW_MIRROR_CHECKSUMS=1 — restore the old behaviour and take the manifest from the mirror too. This transfers full trust to the mirror host.

Version floor. DLAKE_VERSION may pin the same or a newer build, but an older one is refused: an out-of-date binary can be perfectly checksummed and still carry fixed vulnerabilities. Install the matching @commercient/dlake@<version> instead, or set DLAKE_ALLOW_DOWNGRADE=1 if the downgrade is deliberate.

Supported platforms

• Windows x64 (win-x64)
• Linux x64 (linux-x64)
• Linux ARM64 (linux-arm64)
• macOS Apple Silicon (osx-arm64)
• macOS Intel (osx-x64)

Other platforms (e.g. Windows on ARM) fail fast with a clear message naming the detected platform and arch — the installer never falls back to a mismatched binary.

Development

rid.js holds the pure resolution logic (mirrors the C# RidResolver); run its checks with node test-rid.js. install.js exports its pure trust-policy helpers (version floor, checksum provenance, temp-path generation); run their checks with node test-install.js. npm test runs both. See ../../docs/cli.md for the full CLI guide.