Installation Manager

The Installation Manager is a guided alternative to the manual Docker Compose setup described in the preceding chapters. It handles host preparation (Docker, Docker Compose), registry login, image pulls and container startup automatically, then opens a web UI where you configure each Datavault Builder environment — target database connection, ports, services, secrets — without editing docker-compose.yml by hand.

Hint

The manual flow remains the canonical reference. The Installation Manager is the recommended path for new installs when your environment allows running a bootstrap script that installs Docker on your behalf.

When to use this vs. the manual flow

Use the Installation Manager when

• You are installing Datavault Builder on a fresh Linux host and want the fastest path to a running stack.

• You prefer a graphical interface over editing YAML.

Stick with the manual flow when

• Company policy forbids running bootstrap scripts that install packages.

• You want explicit control over every Docker / Compose option from the start.

Prerequisites

A subset of the Requirements. The Installation Manager handles Docker setup itself, so the prerequisites are lighter than the manual flow.

Host

• 64-bit Linux distribution. The script has been validated against Ubuntu, Debian, Fedora, Rocky, AlmaLinux, CentOS, openSUSE, Arch and Alpine. WSL2 is also supported.

• Hardware sizing per Requirements (Disk: 50 GB; Memory: 16-32 GB; CPU: 4-8 x86_64 cores).

• sudo rights — required the first time only, to install Docker and to add your user to the docker group. Subsequent runs are sudo-free.

Network

• Outbound HTTPS to install.datavault-builder.com (download the script) and to docker.datavault-builder.com (pull the images).

Hint

Air-gapped install? The script detects no internet at startup and walks you through transferring images via docker save / docker load or skopeo. The web UI can then continue from those locally-loaded images.

Target database

• An empty database must exist on your target engine (Postgres, MSSQL, Oracle, Exasol, Snowflake, BigQuery, Fabric SQL, Databricks) with the engine-specific prerequisites listed under Target database in Requirements (collation, extensions, sizing, etc.).

• Admin credentials with permission to create users, roles, schemas and objects on that database. You enter them once on the “Installation Credentials” screen when you click Run Installation; they are used only for the install and are not stored.

• The actual DVB schema, technical users and metadata objects (what Preparing target database describes step by step) are created automatically by Run Installation — you do not run those scripts by hand.

Verifying the download (optional but recommended)

Every release of the Installation Manager bootstrap script is signed with Sigstore cosign. You can verify the file before running it to make sure it came from Datavault Builder and was not tampered with in transit.

Public key fingerprint and verification

The current dvb-cosign.pub fingerprint (SHA-256 over the DER-encoded public key) is:

aca763ec83b9288515363650a29dcec0fead6eaa9de3c126be37c2db35df6d8b

This fingerprint is the trust anchor for the entire verification flow. As long as you fetched this documentation from docs.datavault-builder.com — a host served separately from install.datavault-builder.com — an attacker who compromises the install server alone cannot also forge it.

Note

Older Datavault Builder versions may have been signed with a previous key. If you are installing an older release, refer to that release’s documentation for the matching fingerprint.

1. One-time: install cosign on the machine that will run the verification (Linux amd64 example):

   curl -sSfLo cosign https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64
   chmod +x cosign
   sudo mv cosign /usr/local/bin/
   

   For other platforms see https://docs.sigstore.dev/cosign/installation/.

2. Download the public key and confirm its fingerprint matches the value shown above. A key downloaded and used without this check proves nothing — a compromised or spoofed server could serve a matching fake key alongside a fake signature:

   curl -fsSLO https://install.datavault-builder.com/dvb-cosign.pub
   openssl pkey -pubin -in dvb-cosign.pub -outform DER | openssl dgst -sha256
   

   Expected output:

   SHA2-256(stdin)= aca763ec83b9288515363650a29dcec0fead6eaa9de3c126be37c2db35df6d8b

   If the value does not match, stop — do not trust this key — and contact Datavault Builder support.

3. Optional: cross-check the key against our signed key statement, recorded in the public Sigstore Rekor transparency log. This confirms the key’s authenticity independently of trusting install.datavault-builder.com alone:

   curl -fsSLO https://install.datavault-builder.com/dvb-cosign-key-verification.txt
   curl -fsSLO https://install.datavault-builder.com/dvb-cosign-key-verification.sigstore.json
   
   cosign verify-blob \
     --key dvb-cosign.pub \
     --bundle dvb-cosign-key-verification.sigstore.json \
     dvb-cosign-key-verification.txt

   Expected output: Verified OK. The bundle contains a Rekor inclusion proof, so this check works fully offline — no live call to the transparency log is required.

Once the key is verified, use it to check the script:

1. Download the script and its detached signature, then verify against the public key you just trusted:

   curl -fsSLO https://install.datavault-builder.com/datavault-builder-installation.sh
   curl -fsSLO https://install.datavault-builder.com/datavault-builder-installation.sh.sig
   
   cosign verify-blob \
     --key dvb-cosign.pub \
     --signature datavault-builder-installation.sh.sig \
     datavault-builder-installation.sh

   Expected output: Verified OK (exit code 0). On mismatch, do not run the script — report it to Datavault Builder support.

2. Run the (now verified) script:

   bash datavault-builder-installation.sh
   

Hint

Skipping verification is allowed but not recommended. The unsigned one-liner in the next section still works — verification is an additional layer you opt into when the threat model requires it.

Running the bootstrap script

1. Open a terminal on the host that will run Datavault Builder and execute:

   sudo bash <(curl -fsSL https://install.datavault-builder.com/datavault-builder-installation.sh)
   

   Hint

   • No chmod +x is required — bash file.sh ignores the execute bit.

   • The <(...) form (process substitution) preserves interactive prompts. A plain pipe curl ... | bash would consume stdin and break them.

   • If you prefer a local copy you can re-run later, use two steps instead:

     curl -fsSLO https://install.datavault-builder.com/datavault-builder-installation.sh
     sudo bash datavault-builder-installation.sh
     

2. The script then walks you through:

   • Internet check. If offline, it prints step-by-step guidance for transferring images via docker save / docker load or skopeo.

   • Docker installation. If Docker or Docker Compose is missing or below the minimum version (20.10.13 / 2.3.3), the script installs or upgrades them via your distribution’s package manager (Ubuntu/Debian/Fedora/RHEL family/openSUSE/Arch/Alpine). Falls back to https://get.docker.com if needed.

   • Docker group membership. Adds your user to the docker group so subsequent docker commands run without sudo. If you weren’t in the group before, the script re-execs itself via sg docker so the new membership takes effect immediately — no logout required.

   • DVB version, web UI port, privileged mode, envs directory. Each prompt remembers its previous value, so re-running the script defaults to your earlier choices.

   • Registry login. Prompts for your Datavault Builder registry credentials and runs docker login. Cached logins are reused after confirmation.

   • Access mode. Choose between SSH tunnel (most secure), self-signed HTTPS, or HTTPS with a certificate you provide. See Access modes below.

   • Container startup. Pulls the Installation Manager image and starts it in a container named installation-manager.

3. When the script finishes it prints the URL for the web UI plus, for SSH-tunnel mode, the exact ssh -L command to run on your workstation.

Note

The bootstrap script only installs and starts the Installation Manager itself. The Datavault Builder application images (api, core, connectionpool, …) are pulled later, when you generate the Docker Compose bundle from inside the web UI.

Access modes

The Installation Manager web UI has no built-in authentication, so the access mode you pick is the access control. Pick the mode that matches who can reach your network.

Warning

The same access-control caveat applies to the Datavault Builder web UI itself once an environment is started up. The Installation Manager simply controls how the management UI is reached; the application’s own authentication is configured separately during environment setup.

Mode	Security posture	Behaviour
SSH tunnel (default)	Most secure. Only users with SSH credentials to this host can reach the UI.	The container binds to 127.0.0.1 only. Reach the UI by forwarding a port from your workstation: ssh -i <key> -N -L 127.0.0.1:<port>:127.0.0.1:<port> user@server. The script prints the exact command for your host.
HTTPS — self-signed	Trusted networks only. Reachable by anyone on the host’s network. Convenient for local-LAN / on-site use. Do not expose to the public internet without a reverse proxy that adds authentication.	The container binds on all interfaces with a generated self-signed certificate. Accessible at https://<server-ip>:<port>; your browser will display a certificate warning the first time.
HTTPS — provided cert	Same network exposure as self-signed, plus the cert is CA-trusted (no browser warning). Still no auth — pair with a reverse proxy for public exposure.	The container binds on all interfaces using a certificate and private key file that you supply (CERT_FILE and KEY_FILE).

Hint

Self-signed gives you encryption in transit, but no proof of server identity — a network-level attacker can present their own certificate during the first connection without an automatic warning that something changed. For internet-facing deployments, use HTTPS — provided cert with a real CA-signed certificate and put a reverse proxy with authentication in front.

Configuring an environment in the web UI

Once the Installation Manager is reachable in your browser, the workflow looks like:

1. Create or open an environment. Each environment maps to a separate folder on disk containing the generated docker-compose.yml, .env and any secrets. You can host many environments side by side on the same machine.

2. Fill in the section forms. The form layout mirrors the manual configuration that Configuring services describes — the same environment variables, just guided. The UI handles:

   • DVB User — initial admin email, name and password (mirrors GUI_USER_EMAIL / GUI_USER_NAME / GUI_USER_PASSWORD in the manual flow).

   • Network ports — picks free ports on the host with live availability checks.

   • Target database — engine, host, connection string and authenticator credentials. Each engine has the same prerequisites described in Requirements (Target database section).

   • Additional services — toggles for Grafana, Prometheus, WebDAV, Git, gRPC connectors. Equivalent to the ENABLE_* environment variables.

   • System security — admin and authenticator passwords for the target database. The UI can generate them for you.

   • SSL — separate from the Installation Manager’s own access mode; controls whether the Datavault Builder web UI itself runs over HTTPS.

3. Run Installation. The Run Installation button creates the DVB schema, technical users and metadata objects on the target database — the same work Preparing target database describes manually. How admin credentials are collected depends on the engine:

   • Postgres / MSSQL / Oracle / Exasol / Fabric SQL — you enter admin credentials on the Installation Credentials screen. The credentials are used only for the install and are not stored.

   • Snowflake / Databricks — the UI launches an SSO browser flow; you authenticate as an admin in your identity provider and the install runs without you typing credentials.

   • BigQuery — the install uses the service-account key you uploaded during the Target database form step.

   In every case the engine-side prerequisites listed under Target database in Requirements (collation, extensions, sizing, admin role, etc.) must already be satisfied — Run Installation does not create the database itself, only the DVB objects inside it.

4. Generate Docker Compose files. Clicking “Generate Docker Compose Files” writes docker-compose.yml and .env into the environment folder, with a recorded hash so the UI can detect later manual edits.

5. Start the stack. If you enabled privileged mode at install time, you can click “Start” from the UI; otherwise run docker compose up -d in the environment folder yourself.

6. Open the application. The DVB web UI is reachable on the port you configured. Initial credentials are the GUI_USER_NAME / GUI_USER_PASSWORD you set in the form. From here on, use the application as described in Application Configuration.

Importing existing environments

If you already have a docker-compose.yml from a previous manual install (for example one produced by following Starting Up The Application), the Installation Manager can reconstruct its UI representation:

• Automatic on first run — the bootstrap script scans the host’s envs directory after startup and prompts to import any DVB compose files it finds.

• Rescan — the Rescan button on the landing page scans the envs directory for newly added compose files.

• Reimport — if a compose file has been manually edited since the UI last generated it (the UI shows a ⚠ icon), the Reimport button re-reads the file and updates the UI settings to match. The original files are preserved as *.im.bak.

Note

Elements that the GUI cannot represent (custom services, extra volumes, ad-hoc Docker overrides) are flagged with a custom badge after import. They are preserved in the generated docker-compose.yml only as long as the environment is not regenerated from scratch. Regenerating after manually adding custom elements will drop them — use Configuring services to express what you need through standard knobs where possible.

Differences from the manual flow

A quick map of what the Installation Manager handles for you vs. what you still do yourself:

Task	Manual flow	Installation Manager
Install Docker / Docker Compose	You do it (Preparing Host)	Automatic
docker login to the DVB registry	You do it	Prompted, then cached
Pull container images	docker compose pull	Automatic, on environment start
Author docker-compose.yml / .env	You edit a provided template	Generated by the UI from form input
Generate encryption keys	You run the provided openssl commands (see the Generate System Encryption Keys step in Starting Up The Application)	Generated automatically when you click Generate Docker Compose Files
Prepare the target database	You run the scripts in Preparing target database by hand	Run Installation button does the same work, prompted for admin credentials
Choose ports / passwords / which optional services to enable	Edit the .env file	Form fields in the UI
Start the stack	docker compose up -d	One click in the UI (privileged mode) or the same command in the environment folder

The end state — a running Datavault Builder backed by your target database — is identical in both flows. Anything the manual chapters explain about configuration variables (Configuring services, Application Configuration) applies unchanged: the Installation Manager is a different way to author the same files.