elastic-container stands up a TLS secured Elastic stack for local research

A whole Elastic stack, pre-configured, in one script

The project promises to stand up a 100 percent containerized Elastic stack, TLS secured, with Elasticsearch, Kibana, Fleet and the Detection Engine all pre-configured, enabled and ready to use, within minutes.

That is the whole scope, and it is a narrower one than running Elastic yourself. The four components arrive wired together: an Elasticsearch, a Kibana, and an Elastic Agent configured as a Fleet Server with the settings Fleet and the Detection Engine need. The Detection Engine is enabled and the prepackaged rules are installed as part of startup, so you land in a working rules environment rather than an empty Kibana.

The project is not an Elastic product, and it says so in a warning near the top. This is not an Elastic created, sponsored or maintained project, and Elastic is not responsible for this project's design or implementation. The primary language of the repository is Shell, the licence is Apache 2.0, and the top level is small, with `.env`, `docker-compose.yml`, `elastic-container.sh`, `kibana.yml`, `LICENSE.md` and the `.github/` directory. The last push was on 2026-04-10, so if you are reading this to decide whether the project is current, that date is the fact to check, and there are no published GitHub releases to pin to. There is also a blog post on the Elastic Security Labs site that goes into what to do once the stack is running.

Nine steps, and the version pin that catches people

The steps section is a numbered list, and the fourth one is the one that matters.

You clone the repository, install the prerequisites, change into the `elastic-container/` folder, and then set a current stack image tag, because pinned versions in `.env` can disappear from registries over time. Either run `bash ./elastic-container.sh update-version` or the short form `bash ./elastic-container.sh -u`, which sets `STACK_VERSION` to the newest stable `x.y.z` tag listed for elastic/elasticsearch on Docker Hub, or open that page and set `STACK_VERSION` in `.env` manually to a tag that exists for Elasticsearch, Kibana and Elastic Agent.

Then you change the default password of `changeme` in the `.env` file, and the README is explicit that you should not change the `elastic` username, because it is a required built-in user. You can bulk enable the pre-built detection rules by operating system in the `.env` file, which is not required. You make the script executable with `chmod +x elastic-container.sh`, and then you run `./elastic-container.sh start`.

Finally you wait for the prompt to tell you to browse to https://localhost:5601, and the README warns that you may be presented with a browser warning because of the self-signed certificates, and that you can type `thisisnotsafe` or click to proceed, after which you are directed to the Elastic log in screen.

docker-compose-plugin, not docker-compose

The prerequisites are the Docker suite, jq, curl and git, and the README gives the install commands for the common platforms.

On macOS:

brew install jq git curl docker-compose
brew install --cask docker

followed by opening the Docker app so that it can be given privileged access, and on Ubuntu:

apt-get install jq git curl

and on RPM based distributions such as CentOS, Fedora and Rocky:

dnf install jq git curl

The same note appears on each Linux distribution, and it is the one detail most likely to cost an afternoon. Of specific note, you must install the `docker-compose-plugin`, which is different than `docker-compose`. The plugin is the Compose v2 implementation that the `docker compose` subcommand uses, and the older standalone binary is not what the script expects.

Two platform specific notes follow. Arch Linux users should install `inetutils` and change the shell script from `hostname -I` to `hostname -i`, which is the kind of detail that only appears when a script was written on one distribution. And on Windows 10 or 11 with WSL 2, the README asks you to make sure you are using WSL version 2, checked with `wsl -l -v` in PowerShell and changed with `wsl --set-version Ubuntu-20.04 2`, then:

apt-get update
apt-get install jq git curl

and, once the Docker suite is installed, `sudo service docker start` to start it.

What start actually does on the machine

The usage section spells out what the start argument does, and the sequence explains why the first run takes a while.

Starting will create a network called `elastic`, download the Elasticsearch, Kibana and Elastic-Agent Docker images defined in the script, and start Elasticsearch, Kibana and the Elastic Agent configured as a Fleet Server with all the settings needed for Fleet and the Detection Engine.

The output shows the shape of it:

$ ./elastic-container.sh start

...
 ⠿ Container elasticsearch-security-setup  Healthy 7.3s
 ⠿ Container elasticsearch                 Healthy 39.3s
 ⠿ Container kibana                        Healthy 59.3s
 ⠿ Container elastic-agent                 Started 59.7s

Attempting to enable the Detection Engine and Prebuilt-Detection Rules

Kibana is up. Proceeding

Detection engine enabled. Installing prepackaged rules.

Prepackaged rules installed!

Waiting 40 seconds for Fleet Server setup

So the script waits for the security setup container, then for Elasticsearch, then for Kibana, and only then enables the Detection Engine and installs the prepackaged rules, and then it waits another 40 seconds for Fleet Server setup. The agent container reports as Started rather than Healthy, because it is a long running service rather than one with a health check.

The practical point is that the startup is sequential and slow, and the rules installation happens at the end of it, so a run that appears stuck in the first minute is usually just Elasticsearch still becoming healthy.

A setup container that mints its own CA and certificates

The TLS story is handled by a dedicated Compose service that runs the Elasticsearch image as root and generates the certificates before anything else starts:

services:
  setup:
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    container_name: ecp-elasticsearch-security-setup
    volumes:
      - certs:/usr/share/elasticsearch/config/certs:z
    user: "0"
    command: >
      bash -c '
        if [ x${ELASTIC_PASSWORD} == x ]; then
          echo "Set the ELASTIC_PASSWORD environment variable in the .env file";
          exit 1;
        elif [ x${KIBANA_PASSWORD} == x ]; then
          echo "Set the KIBANA_PASSWORD environment variable in the .env file";
          exit 1;
        fi;

Two things are worth reading there. The setup service refuses to do anything if either password variable is empty, which is the same rule the script enforces later, and the container runs as user 0 because the certificate tools write into the mounted volume.

The rest of the command creates a CA with `bin/elasticsearch-certutil ca` if `certs/ca.zip` is not there, writes an `instances.yml` describing the DNS names and IP addresses for the elasticsearch, kibana and fleet-server hosts, and then produces the node certificates with `bin/elasticsearch-certutil cert` against that CA, all with `--pem`. The result is that the stack serves HTTPS with certificates signed by a CA the stack generated for itself, which is why the browser warns and why the README tells you what to type to get past it.

A research tool that refuses to start with default credentials

The usage section is where the project's intent is clearest. This uses default creds of `elastic:changeme` and is intended purely for security research on a local Elastic stack, and the instruction is to change the password in the `.env` file, while not changing the `elastic` username, since it is a required built-in user.

Then the sentence that defines the boundary: this should not be Internet exposed or used in a production environment.

That constraint is enforced rather than merely suggested. The start section says that if you have not changed the default passwords in the `.env` file, the script will exit, and the setup container in the Compose file exits with an error message if either password variable is empty. So the insecure configuration cannot be started by accident.

The rule can also be flipped in the other direction, in the sense that the stack is meant to be cheap and disposable. The pre-built detection rules can be bulk enabled per operating system by changing the chosen value in `.env` from 0 to 1, with separate switches for LinuxDR, WindowsDR and MacOSDR, and this happens on startup. A researcher who wants to test a rule set for one platform changes one line and restarts.

The consequence for a reader is that this repository is a convenience wrapper, not a product. It saves an afternoon of assembling a certificate chain, a Fleet Server, an agent and a rules installation. It does not harden anything, and it is not the place to look for production guidance.

Editorial conclusion

Adopt elastic-container when you want a working Elastic detection environment on a laptop for research, testing rules or reproducing behaviour, and when you are happy to manage a container stack by hand. Do not adopt it as a production deployment, since the README says plainly that it should not be Internet exposed or used in a production environment, and the default credentials are `elastic:changeme`. Verify first that the `STACK_VERSION` you pin exists for Elasticsearch, Kibana and Elastic Agent, that you have changed both passwords in `.env`, that you have installed the `docker-compose-plugin` rather than the older `docker-compose`, and that the state of the repository is the one you expect, since the last push was on 2026-04-10 and there are no published releases.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. peasead/elastic-container on GitHub
4. README