Install from the Docker image (download from S3)¶

The container alternative to the bare-metal install: download one self-contained ELTMaestro image from the public release bucket, load it into Docker, and run it. Everything — PostgreSQL, the engine, the SOAP meta-service, and Spark/Hadoop — runs inside the single container.

Prerequisites¶

A host with Docker installed and running (Linux recommended).
~6 GB free disk for the image, plus room for the data volumes.
Outbound HTTPS to download the image (or copy the tarball in for an air-gapped host).

Step 1 - download and load the image¶

Releases are published to https://eltmaestro.s3.amazonaws.com/docker/. Download the image tarball for the version you want and load it into Docker:

curl -fLO https://eltmaestro.s3.amazonaws.com/docker/eltmaestro-<VERSION>.tar.gz
docker load -i eltmaestro-<VERSION>.tar.gz
docker images eltmaestro

docker load registers eltmaestro:<VERSION> locally. The current image is eltmaestro-17.0.4.tar.gz; see Downloads for the exact URLs (the bucket isn't directory-browsable).

Step 2 - run the container¶

docker run -d --name eltmaestro --restart unless-stopped \
  -p 8181:8181 \
  -p 5432:5432 \
  -p 10000:10000 \
  -p 9080:8080 \
  -p 7077:7077 \
  `# optional diagnostic UIs — add only if you need them` \
  -p 9870:9870 \
  -p 9000:9000 \
  -p 8081:8081 \
  -v eltm-pgdata:/opt/iserver/server/pgsql/data \
  -v eltm-hdfs:/root/hdmaestro \
  -v eltm-data:/opt/iserver/data \
  eltmaestro:<VERSION>

What the ports are for (only 8181 is required — the rest are optional, by feature):

Port	Service
8181	SOAP meta-service over HTTPS — the desktop client connects here
5432	PostgreSQL audit DB
10000	Spark Thrift / HiveServer2
9080	Spark master UI (container 8080)
7077	Spark master RPC
9870	HDFS NameNode web UI
9000	HDFS NameNode RPC (filesystem access)
8081	Spark worker UI

The image EXPOSEs all of the above; the docker run above publishes them to the host. The three optional ports drive diagnostic UIs only — omit their -p flags for a minimal install (the desktop client needs just 8181). The `# ...` line is a shell no-op comment, safe to keep or drop.

Two things to know:

TLS works out of the box. The image bakes a self-signed keystore and starts the meta-service on HTTPS (SSL_ENABLED=true by default) — no keystore mount needed, and the desktop client accepts the self-signed cert automatically. To override: -e SSL_ENABLED=false for plain HTTP, or -e KEYSTORE_PATH=… -e KEYSTORE_PASSWORD=… for your own certificate.
The three named volumes hold all durable state — the audit DB, the HDFS warehouse, and deployed workflows + logs plus, since the first release after 17.0.4.451 (commit config-preserve, September 2026), your integrator configuration (/opt/iserver/data/config on the eltm-data volume: the per-platform system.cfg files and ~/.env_integrator). Keep the same volume names across upgrades and your data and configuration persist. Use the exact container paths shown (PostgreSQL lives at /opt/iserver/server/pgsql/data, not the usual /var/lib/postgresql/data).

Step 3 - wait for startup and verify¶

First start initializes the database (a minute or two). Watch for readiness, then confirm the services and the SOAP endpoint:

docker logs -f eltmaestro                       # wait for "Audit database ready"
docker exec eltmaestro supervisorctl status     # services should be RUNNING
curl -sk https://<server_ip>:8181/MaestroMetaDataProviderService/MaestroMetaService?wsdl | head -2

The WSDL request should return its XML header (HTTP 200).

Step 4 - default credentials¶

A bootstrap user is seeded on first start:

User: integrator
Password: integrator123

Change it before connecting any real client:

docker exec eltmaestro mset-password-md5 INTEGRATOR '<new-password>'

Step 5 - connect the desktop client¶

Point the ELTMaestro desktop client's Server / Port at <server_ip> / 8181 and sign in as integrator with your new password. From here the User Guide covers connections, workflows, and the rest.

Upgrading¶

Download the new image tarball, load it, then recreate the container with the same volume names — your data carries over and pending migrations apply automatically on start.

Your edited configuration used to be lost here. Before that release the integrator config tree (server/pgsql/metadata/integrators/<platform>/system.cfg, where $SYSTEM_DEFAULT_DATABASE and the other $SYSTEM_* values live) and ~/.env_integrator were part of the image, so docker rm put the factory copies back — one site had $SYSTEM_DEFAULT_DATABASE reset to dev and wrote to the wrong database for days. From that release the container keeps the site's copies on the eltm-data volume and, at every start, keeps every file you have, adds only files that are new in the release, snapshots the previous tree to /opt/iserver/data/config/.upgrade-<stamp>/, and prints a [config] block in docker logs naming each file whose content differs from the factory and, for system.cfg, each key ($SYSTEM_DEFAULT_DATABASE: site=… factory=dev).

Upgrading FROM an image up to 17.0.4.451: carry your edits across once, before the docker rm:
docker exec eltmaestro sh -c 'mkdir -p /opt/iserver/data/config && >   cp -a /opt/iserver/server/pgsql/metadata/integrators /opt/iserver/data/config/ && >   cp -a /root/.env_integrator /opt/iserver/data/config/env_integrator'
The new image finds those copies on the volume and uses them. Skip this on an old image and the first start of the new one seeds the volume from the factory — after that, edits survive.

curl -fLO https://eltmaestro.s3.amazonaws.com/docker/eltmaestro-<NEW_VERSION>.tar.gz
docker load -i eltmaestro-<NEW_VERSION>.tar.gz
docker stop eltmaestro && docker rm eltmaestro
docker run -d --name eltmaestro --restart unless-stopped \
  -p 8181:8181 -p 5432:5432 -p 10000:10000 -p 9080:8080 -p 7077:7077 \
  -p 9870:9870 -p 9000:9000 -p 8081:8081 \
  -v eltm-pgdata:/opt/iserver/server/pgsql/data \
  -v eltm-hdfs:/root/hdmaestro \
  -v eltm-data:/opt/iserver/data \
  eltmaestro:<NEW_VERSION>

See OPERATIONS.md for day-to-day start/stop, logs, and admin tasks.