# docker-splunk: building Splunk Enterprise as a container image > This is Splunk's own repository of Dockerfiles for building Splunk Enterprise and Splunk Universal Forwarder images, with the provisioning handed off to a separate Splunk-Ansible project. It suits a team that has already decided to run Splunk and wants its configuration in version control, and it is not a Splunk distribution, since the software inside the image remains under the Splunk General Terms. **splunk/docker-splunk** — Splunk Docker GitHub Repository - Repository: https://github.com/splunk/docker-splunk - Stars: 554 · Forks: 278 - Language: Python - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/splunk-docker-splunk ## What this repository is, and where the actual work moved This is the official Splunk repository of Dockerfiles for building Splunk Enterprise and Splunk Universal Forwarder images for containerized deployments. The stated purpose is to marry the ideals of infrastructure-as-code and declarative directives to manage and run Splunk Enterprise. The critical thing to understand is that the container building is not the whole system, and the README points elsewhere for the important half. The provisioning of these containers is handled by the Splunk-Ansible project, with the Splunk-Ansible documentation and the Ansible User Guide given as the references. So the division is: this repository defines the image, and Splunk-Ansible defines how a running instance is configured. That division exists because containerising a stateful service with an index and a configuration tree is mostly a configuration management problem, and Ansible is a configuration management tool. Writing the image is the small part. The README's own framing is that the image gets the software into a container, and the Ansible role is what makes that container a working Splunk instance with the right inputs, outputs, indexes and configuration. The repository layout reflects the same split. There are `base/` and `py23-image/` directories for the shared base images, a `splunk/` directory for the Enterprise image and a `uf/` directory for the Universal Forwarder, plus a `Makefile` that drives the builds, a `docs/` directory with the documentation and the support and contribution guidelines, `tests/` and `test_scenarios/` for the test suite, and `test-results/` for its output. There is also a `clair-whitelist.yml` and a `clair_to_junit_parser.py` script, which are about scanning the built images for vulnerabilities and reporting the result. The default branch is `develop`, the last push to the tree was on 2026-10-19, and the releases include 10.4.3, 10.4.2 and 10.4.1, all dated 2026-09-15. ## The Debian deprecation and what is still published The README opens with a deprecation notice that is easy to skim past and expensive to ignore. We are no longer releasing Debian images on Docker Hub as of May 2021, for Splunk Enterprise v8.2.0 and later. Red Hat images will continue to be published. That sentence covers nearly five years of image history and it changes what you can pull today. If you arrive at this repository expecting a Debian based `splunk/splunk` image for a recent Splunk release, the notice is telling you that family is not being published. The Red Hat line is the one that continued. The releases in the repository are numbered 10.4.3, 10.4.2 and 10.4.1, which follow the 10.x line that the README later discusses when it explains the licence acceptance change in the 10.x image versions of Splunk Enterprise and Splunk Universal Forwarder. So the image family in active use is a Red Hat one, and the licence acceptance behaviour described below applies to it. The Makefile shows the two things the build depends on. The version and build parameters for the Splunk product are set as variables, with `SPLUNK_VERSION` and `SPLUNK_BUILD` in the visible part of the file and `SPLUNK_PRODUCT` set to `splunk`, and the download URLs are derived from them for Linux, for the Windows installer and for the Universal Forwarder. The architecture is chosen by a conditional on `arch`, with `s390x` for that platform and `amd64` otherwise, and the filename and URL are assembled to match. There is also a compose file, referenced as `cluster_absolute_unit.yaml`, and the Splunk-Ansible repository and branch are variables, defaulting to the `develop` branch of that project. So even the build is parameterised rather than hard coded, which is the difference between a forkable recipe and a fixed image. ## Starting a container and the two flags you cannot omit The quickstart is one `docker run`, and the README explains each part of it afterwards. ```bash $ docker run -p 8000:8000 -e "SPLUNK_PASSWORD=" \ -e "SPLUNK_START_ARGS=--accept-license" \ -e "SPLUNK_GENERAL_TERMS=--accept-sgt-current-at-splunk-com" \ -it --name so1 splunk/splunk:latest ``` It starts a container from the `splunk/splunk:latest` image, names the container `so1`, maps the host's `8000` port to the container's `8000`, and specifies a custom `SPLUNK_PASSWORD` that has to satisfy the Splunk Enterprise password requirements. Then there are the two flags that decide whether the container comes up at all. `SPLUNK_START_ARGS=--accept-license` accepts the license agreement, and `SPLUNK_GENERAL_TERMS=--accept-sgt-current-at-splunk-com` accepts the current Splunk General Terms. The README is emphatic that this agreement must be explicitly accepted on every container or Splunk Enterprise does not start. The general terms flag is the newer of the two and it exists because of the 10.x image change. Starting in 10.x image versions of Splunk Enterprise and Splunk Universal Forwarder, licence acceptance requires that additional argument, and it indicates that the user has read and accepted the current version of the Splunk General Terms, which the README says may be updated from time to time. The longer paragraph goes on to note that unless you have jointly executed with Splunk a negotiated version of those terms that explicitly supersedes it, by accessing or using Splunk software you are agreeing to the terms posted at the time of your access and use. The practical consequence for anyone automating this: the acceptance is per container start, not a one-time thing in the image, so a deployment template has to carry both flags or a scaled-out replica comes up dead. After the container starts, Splunk Web is at http://localhost:8000 with the `admin` user and the password you set. ## Driving the running instance from outside the container Once the container is up, the README gives four operational commands, and between them they cover the tasks you would otherwise do with a management interface. Reading the logs is a `docker logs` on the container name. ```bash $ docker logs -f so1 ``` Getting a shell inside the container defaults to the `ansible` user, which is the account the provisioning uses. ```bash # Defaults to the user "ansible" docker exec -it so1 /bin/bash # Run shell as the user "splunk" docker exec -u splunk -it so1 bash ``` The `splunk` user is the one the Splunk binaries run as, and using it matters for the CLI commands, because those commands have to run as the user that owns the Splunk installation. Enabling an input is done through the Splunk CLI inside the container. The example enables TCP 10514 for listening, sets the sourcetype to syslog, resolves the host, and authenticates as admin with the password from the environment. ```bash docker exec -u splunk so1 /opt/splunk/bin/splunk add tcp 10514 \ -sourcetype syslog -resolvehost true \ -auth "admin:${SPLUNK_PASSWORD}" ``` Installing an app works the same way, by pointing the install command at a tarball inside the container, and there is an alternative that passes the app URL at container run time instead. ```bash docker exec -u splunk so1 /opt/splunk/bin/splunk install \ /path/to/app.tar -auth "admin:${SPLUNK_PASSWORD}" # Alternatively, apps can be installed at Docker run-time docker run -e SPLUNK_APPS_URL=http://web/app.tgz ... ``` Note the pattern in all of these. The Splunk CLI is invoked with `-u splunk`, and the password comes from the environment variable rather than being typed. Both details matter when you script this, and the second one is the difference between a runnable pipeline and one that fails on a fresh container. ## What the licence actually covers, and what it does not The licence section is short and it is the part most likely to surprise someone who came for an open source log platform. The repository carries an Apache 2.0 badge and the licence text says the copyright belongs to Splunk for 2018 to 2024, and that it is distributed under the terms of the repository's own licence file at `docs/LICENSE.md`, with the note that splunk-ansible is free and open source software. That sentence is about the Ansible project, not about Splunk Enterprise. The following sentence is the one that governs the software you actually run. The software in the container is licensed under and subject to the Splunk General Terms, and by accessing the container and its software you agree to those terms. The README's own statement of the position is that the software in the container is not open source, it is Splunk Enterprise under a proprietary licence, and the repository is the official source of the Dockerfiles for building it. The repository's own licence field is recorded as unknown, which is a further hint that the Apache badge describes the container tooling rather than the application. So the honest summary is that this is a build repository for a proprietary product, published by its vendor, under a permissive licence for the tooling and Splunk's own terms for the payload. For an organisation that has already licensed Splunk Enterprise and wants the deployment in version control, that is exactly what is needed. For an organisation looking for a free log analytics platform, this is the wrong repository, and no amount of containerisation changes the licensing of the software inside. The General Terms are also live documents. The README says the current version is available on Splunk's site and may be updated from time to time, and the acceptance flag refers to the version current at the time of access. A pinned image and an unpinned legal document are a combination worth noting in a compliance review. ## Where this approach does not reach There are three practical boundaries, and one of them is about scope rather than technique. The first is that the image is not a complete deployment. The README is explicit that the provisioning is handled by Splunk-Ansible, and the full usage instructions, including installation, examples and advanced deployment scenarios, are on the Docker-Splunk documentation site. So the repository alone gives you an image, and a Splunk instance with real configuration needs the Ansible role or your own equivalent. The second is scale and architecture support. The Makefile's architecture conditional covers `s390x` and `amd64`, and the download URL construction is per platform, so the image set is not unlimited. The compose file is a single named file, `cluster_absolute_unit.yaml`, and while there is a `test_scenarios/` directory in the tree, the repository documentation does not describe a documented clustering configuration. Anyone planning a multi-node Splunk cluster has to go to the Splunk-Ansible documentation and the Splunk Enterprise container documentation rather than rely on this repository. The third is the licensing constraint, already covered, which is a hard boundary and not a configuration problem. The alternative approach is worth naming concretely. The difference between this route and a conventional virtual machine deployment is where the configuration lives. On a VM, the Splunk configuration is files edited in place on the host, or through the management interface, and the state of the instance drifts from any record of how it was built. Here, the image is a versioned artefact and the configuration is a set of Ansible roles in a Git repository, so the instance is reproducible from source. The cost is that you now need a container runtime, an Ansible control path, and a working understanding of both, where the VM route needs only the second. If you already run Splunk-Ansible, this repository is a natural fit, because the two are designed to work together. If you do not, adopting this repository alone gets you a running container with default configuration and no declarative management, which is the least useful combination of the options. ## Conclusion Adopt docker-splunk if you already run Splunk Enterprise and want the image build and the instance configuration to live in your own repositories, because that is what the Ansible hand-off is for. Do not adopt it to get a free or open source log analytics platform, since the Splunk software in the image is licensed under the Splunk General Terms and the licence acceptance flags are mandatory on every container start. Before your first run, read the deprecation notice about Debian images, confirm the base image family you need is still published, and set the `SPLUNK_PASSWORD` and both acceptance flags in your orchestration so a restart cannot silently come up unlicensed. ## FAQ ### How do I start a Splunk Enterprise container with docker-splunk? Run the documented `docker run` with `-p 8000:8000`, a `SPLUNK_PASSWORD`, `SPLUNK_START_ARGS=--accept-license` and `SPLUNK_GENERAL_TERMS=--accept-sgt-current-at-splunk-com`, naming the container `so1` and using the `splunk/splunk:latest` image. Splunk Web is then at http://localhost:8000 with the `admin` user. ### Why does my Splunk container not start? The licence agreement must be explicitly accepted on every container or Splunk Enterprise does not start, so both the `--accept-license` and the `--accept-sgt-current-at-splunk-com` arguments are required. The general terms argument is required starting with the 10.x image versions. ### Are Debian images still published for docker-splunk? No. The README carries a deprecation notice stating that Debian images are no longer released on Docker Hub as of May 2021, for Splunk Enterprise v8.2.0 and later. Red Hat images continue to be published. ### How is configuration handled for these Splunk containers? The provisioning of the containers is handled by the separate Splunk-Ansible project, with its documentation and the Ansible User Guide given as the references. The repository holds the Dockerfiles for building the images. ### What licence applies to the Splunk software inside the container? The software in the container is licensed under and subject to the Splunk General Terms, and accessing the container and its software means agreeing to those terms. The repository's own tooling is distributed under the licence in `docs/LICENSE.md`. ## Sources - [Issues](https://github.com/splunk/docker-splunk/issues) - [README](https://github.com/splunk/docker-splunk/blob/develop/README.md) - [Releases](https://github.com/splunk/docker-splunk/releases) - [splunk/docker-splunk on GitHub](https://github.com/splunk/docker-splunk) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/splunk-docker-splunk