Graylog's compose files are a demo harness with an explicit warning label

Four directories, four different Graylog topologies

The repository is small and the top level entries explain the whole design. There are four directories, each holding a set of Compose files: open-core/, enterprise/, cluster/ and forwarder/, alongside a .gitignore, the README and the LICENSE.

The naming describes the deployments rather than the features. open-core/ is the standard single node arrangement using Graylog's open core distribution. enterprise/ is the variant for the licensed edition. cluster/ covers the multi node topology, which is where a distributed Graylog gets its data node and its search nodes. forwarder/ is for a forwarder, the lightweight agent that ships logs from a host into a central Graylog instead of running the server there.

That last one is the piece that is easiest to overlook. A forwarder is not a scaled down Graylog server, it is a separate deployment mode, and having it in the same repository is convenient for anyone who wants to test a log shipping path without standing up the full server.

The repository description is consistent with the README: a set of Docker Compose files that allow you to quickly spin up a Graylog instance for testing or demo purposes. Note that the emphasis on quickly and on demo is in the project's own framing, not an inference.

vm.max_map_count is the host setting that will stop you first

Before any container starts, there is one host level prerequisite, and the README puts it under a heading titled Configure your OS. You need to configure your OS or Docker to have the correct vm.max_map_count setting, and the README links to the OpenSearch documentation for the important settings.

That is a specific, checkable requirement rather than a vague one, and it is the kind of thing that costs an afternoon if you skip it. vm.max_map_count is a kernel limit on the number of memory map areas a process may have, and OpenSearch uses memory mapped files heavily. If the limit is too low, the search node fails to start, and the failure looks like an unrelated JVM error rather than a host misconfiguration.

The reason the setting is called out here is that the Compose files do not set it for you. It is a property of the host kernel, and it has to be applied on the machine or inside the VM running Docker, not in a container. The README's phrasing covers both cases, which is the right ambiguity to leave, since the correct value and where it lives depends on whether Docker itself runs in a Linux VM.

The other prerequisite is the obvious pair, Docker and Docker Compose, both linked to their own installation docs.

Configuration is GRAYLOG_ prefixed environment variables in a .env file

All the Graylog configurations can be set via environment variables, and the rule is mechanical: prefix the parameter name with GRAYLOG_ and put it in upper case. The README points at the Graylog server configuration documentation for the full list of parameters.

The variables live in an environment file. The repository ships .env.example, and you rename it to .env so Docker Compose will pick it up:

      cp .env.example .env

That renaming step is the whole configuration workflow. There is no separate config file to edit and no command to run, which is what makes the setup quick enough to be a demo. A parameter that in a native install would live in a graylog.conf file becomes an environment variable with the same name in upper case with a prefix, and the container picks it up at start.

Two variables are mandatory, and the README marks this as important. You must set GRAYLOG_PASSWORD_SECRET and GRAYLOG_ROOT_PASSWORD_SHA2 in the .env file, and Graylog will not start without them. The first is the secret used to sign and verify internal tokens, and the second is the hash of the initial root password. Neither has a default you would want to ship with, and the second is the value you will use as the root account password.

A .env file is also the natural place to put the OpenSearch and MongoDB connection details, since Graylog needs both of those to start.

Starting it is one command, and the first password comes from the logs

Once those two variables are set, the startup commands are the standard Compose pair. Run docker compose up to start the instance in the foreground, and docker compose up -d to start it daemonized.

The client port is 9000 by default, so you navigate to http://localhost:9000 once the services are up.

The login sequence is the part that trips people up, and the README handles it in three cases. The username is admin. The password depends on what you are looking at.

If you are running the DataNode and it is the initial startup, the password is the one from the logs of your first Graylog node, and you use it for the basic auth dialog that appears before the preflight and configuration UI. After you have configured Graylog, you use the password you set through GRAYLOG_ROOT_PASSWORD_SHA2. And if you have manually configured Graylog to connect to OpenSearch directly, you use that same password from GRAYLOG_ROOT_PASSWORD_SHA2 straight away, because the preflight and configuration UI is not shown in that case.

So there are effectively two paths. On a default start you get a temporary password from the container logs and a setup wizard, and on a pre-configured or direct OpenSearch connection you get the password you chose and no wizard. The distinction matters because the basic auth dialog comes before the UI, so a wrong guess there looks like a broken deployment rather than a password problem.

The README labels itself as not for production, twice

The disclaimer is not a footnote. It is the first thing in the README, marked as an important notice: the Docker Compose files in this repository are meant for testing and demo purposes, and the files might be outdated, can change in incompatible ways, and are not tested for production use cases.

That last clause has a specific meaning for anyone who is tempted to promote these files. The repository has no GitHub releases, so there is no tagged version of a compose file to pin, and the main branch is where changes land. A compose file that changes incompatibly between two runs of a demo is an annoyance, and the same change on a production host is an outage. There is no upgrade path documented either, and no migration notes, which is what you would expect if the files are not meant to outlive a demonstration.

The last push was on 2026-10-19, so the files are being worked on, and the repository is not archived. The activity is consistent with keeping a demo current against a moving Graylog release rather than with maintaining a supported deployment.

The licence arrangement is worth reading carefully because it is two licences. Graylog itself is licensed under the Server Side Public License, and the README links to the licensing information for it. This Docker image, that is the compose files in this repository, is licensed under the Apache 2.0 licence, with the file at the root. So the permissive grant covers the packaging, while the software it packages carries a source available licence with its own terms. That is a licensing note rather than legal advice, and anyone running this beyond a laptop should have the SSPL reviewed for their situation.

Where a compose file is the wrong answer

The obvious alternative to a community compose file is the vendor's own container documentation, and for anything long lived that is the more defensible choice. The reason is the one the README already gives: these files are not tested for production, and the packaging is Apache 2.0 while the product is SSPL, so a production deployment based on this repository is running a source available server under terms that were not designed for that use.

There is a second, more practical limitation. A compose file pins a set of image tags at the moment it was written, and Graylog's upstream images move. A demo file that references a current tag will pick up whatever that tag points to when you run it months later, which means the demo you are giving is not the demo you tested, and an incompatibility in the server or in OpenSearch surfaces as a broken demo rather than as a clear error.

The forwarder directory deserves a separate word because it changes the shape of the question. A forwarder is the component you deploy on a machine that is not the Graylog server, and testing it locally against a local Graylog is a genuinely useful exercise, because the failure modes of shipping logs over the network are exactly what you want to see before deploying. For that use, the repository is a good fit, and the license question does not arise in the same way, since no Graylog server is being run.

The honest summary is that this repository removes the friction of getting a look at Graylog and leaves every decision about durability, upgrades and licensing to you.

Editorial conclusion

Adopt this repository if you need a Graylog instance running locally to try a query, reproduce a bug or demo the product to someone. Do not adopt it as a production deployment, because the README states the files might be outdated, can change in incompatible ways and are not tested for production use cases. Verify first that your host has the vm.max_map_count setting configured as the OpenSearch documentation requires, that GRAYLOG_PASSWORD_SECRET and GRAYLOG_ROOT_PASSWORD_SHA2 are set in your .env file, and which of the four directories matches the topology you actually want to run.

Frequently asked questions

Official sources

1. Graylog2/docker-compose on GitHub
2. Issues
3. License: Apache-2.0
4. README