# cp-all-in-one wires Confluent Platform into a Docker Compose file per variant > cp-all-in-one is a set of docker-compose.yml files that start Confluent Platform or Apache Kafka with Schema Registry, Kafka Connect, Control Center, REST Proxy, ksqlDB and Flink, plus a GitHub Action to launch them in CI. The repository declares no licence, ships one stale release tag, and is organised as one branch per platform version. **confluentinc/cp-all-in-one** — docker-compose.yml files for cp-all-in-one , cp-all-in-one-community, cp-all-in-one-cloud, Apache Kafka Confluent Platform - Repository: https://github.com/confluentinc/cp-all-in-one - Stars: 1,163 · Forks: 712 - Language: Python - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/confluentinc-cp-all-in-one ## Four variants, and the licence terms differ between them The repository is not one compose file, it is a set of them, and the differences between the variants matter more than the similarity. The README describes four. cp-all-in-one is the Confluent Enterprise License version of Confluent Platform, including Confluent Server, Schema Registry, a Kafka Connect worker with the Datagen Source connector plugin installed, Confluent Control Center, REST Proxy, ksqlDB and Flink. cp-all-in-one-community is the Confluent Community License version, built on the Apache Kafka broker rather than Confluent Server, and it carries the same component list otherwise. cp-all-in-one-cloud is a different animal. Its compose files run Confluent Platform components, among them Schema Registry, a Kafka Connect worker with the Datagen Source connector, Control Center, REST Proxy or ksqlDB, against Confluent Cloud rather than against a local broker. It is the bridge for testing client code against a managed service. The fourth, cp-all-in-one-security/oauth, is the Confluent Enterprise License version again, this time showcasing the platform's OAuth 2.0 support using the Keycloak identity provider. That means the compose set brings a third-party identity provider into the picture, which is a considerably heavier thing to run locally than the other variants. For a reader choosing between them, the practical question is which broker you need, Confluent Server or Apache Kafka, and whether you want the identity layer. The other two decisions, enterprise versus community terms, and local versus Confluent Cloud, follow from those. ## The documented way to run it is a GitHub Action Most people meet this repository through the GitHub Action rather than by cloning it, and the README leads with that. The action takes three inputs. The service input sets up to which service in the docker-compose.yml file to run, and the default is none, so all services are run. The github-branch-version input selects which GitHub branch of cp-all-in-one to run, and the default is latest. The type input chooses between cp-all-in-one, based on Confluent Server, and cp-all-in-one-community, based on Apache Kafka. Here is the example the README gives for running Confluent Server on platform version 7.7.1. ```yaml steps: - name: Run Confluent Platform (Confluent Server) uses: confluentinc/cp-all-in-one@v0.1 with: service: broker github-branch-version: 7.7.1-post ``` And here is the example for running all Apache Kafka services on the latest branch. ```yaml steps: - name: Run Confluent Platform (Confluent Server) uses: confluentinc/cp-all-in-one@v0.1 type: cp-all-in-one-community ``` Note the version suffix on the branch name, 7.7.1-post, which is not the same string as the platform version 7.7.1. That convention is worth internalising, because the branch name is how you pin the compose files to a platform release and a wrong guess fails rather than silently installing a different version. The action reference is in action.yml at the repository root, and the repository also carries a github-actions-example/ directory with ready-made workflow files. The one thing to be careful about is that this runs a stack of services in a CI runner, and the ports in the next section are all bound on the host. ## The port list is the contract you have to satisfy The README gives one short section, and it is the part you will actually need. To connect to services in Docker, refer to the following ports. ```console Kafka broker: 9092 Kafka broker JMX: 9101 Confluent Schema Registry: 8081 Kafka Connect: 8083 Confluent Control Center: 9021 ksqlDB: 8088 Confluent REST Proxy: 8082 Flink Job Manager: 9081 ``` That is the entire interface a user has to remember, and it is a fixed list rather than something negotiated at runtime. The broker on 9092 is the one every producer and consumer connects to, Schema Registry on 8081 is where schemas live, Kafka Connect on 8083 is where you install connectors, Control Center on 9021 is the web UI, ksqlDB on 8088 is the streaming SQL endpoint, REST Proxy on 8082 is the HTTP front door, and the Flink Job Manager on 9081 is the cluster UI. Two of these deserve a note. The JMX port on 9101 is the broker's management interface, exposed separately from the client port, and exposing it beyond your own machine is the kind of decision that deserves thought. And the Control Center port on 9021 is a browser UI with a login, not an internal service. Because these are host ports, a second copy of the stack on the same machine collides with the first. That constraint is the practical limit on how much of this repository you can run at once, and it is worth checking against what else is bound before you start. ## The image is a thin wrapper around docker compose The repository builds one container image, and its Dockerfile is four lines of substance. It starts from the tiangolo/docker-with-compose base image, copies entrypoint.sh into the image, makes it executable, and sets it as the entrypoint. ```dockerfile FROM tiangolo/docker-with-compose COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] ``` So the artefact is a container that has the compose tool inside it and runs a script on start. The entrypoint script at the repository root is what the container runs on start. The Dockerfile itself does nothing clever, which is the point, because the whole value of the repository is in the compose files and the wiring around them. The directory layout follows the variants rather than the code. There is a directory for each of the four flavours, cp-all-in-one/, cp-all-in-one-community/, cp-all-in-one-cloud/ and cp-all-in-one-security/, an images/ directory for the Confluent logo assets used in the README, and the github-actions-example/ directory with sample workflows. There is no application code to speak of, which is why the primary language is recorded as Python and not as a service language: the Python is in the tooling around the compose files rather than in the services themselves. ## Every variant includes a connector that generates data for you One detail runs through all four variants and is easy to overlook: each of them includes a Kafka Connect worker with the Datagen Source connector plugin installed. Datagen is a source connector that produces synthetic records, and shipping it preinstalled is a deliberate convenience. It means that the moment the stack is up, you have a working pipeline without writing a producer, which is the fastest way to confirm that the broker, Connect and the schema registry are talking to each other correctly. For a demo or a CI smoke test that is exactly what you want, because a failure then points at the platform rather than at your own client code. The component list otherwise mirrors the platform's own menu. Schema Registry handles schemas, Connect handles the connector runtime, Control Center gives you the browser view of the cluster, REST Proxy exposes the HTTP interface, ksqlDB is the streaming SQL engine, and Flink brings the job manager. Confluent Server or the Apache Kafka broker is the foundation, and the two variants differ there and in their licensing. The scale of this is worth stating plainly. This is a full platform topology, not a single broker, and it is why the port list has eight entries and why the CI example in the README is a multi-service run rather than a single container. ## No licence is declared for the repository itself This is the part to look at carefully, and the visible metadata is unambiguous: the repository's licence is not declared. There is no LICENSE file listed among the top-level entries, which run from .github/ and .gitignore through the Dockerfile, action.yml, the variant directories, entrypoint.sh, github-actions-example/ and images/. The absence is not a technicality, because the components being composed carry their own terms. The README is explicit that cp-all-in-one is the Confluent Enterprise License version and cp-all-in-one-community is the Confluent Community License version, and the OAuth variant is enterprise again. Those are the terms under which Confluent Server and Control Center are provided, and they are separate from whatever terms apply to the compose files themselves. The cp-all-in-one-cloud variant points at Confluent Cloud, which is a commercial service. This is a licensing fact rather than legal advice, but the practical reading for an organisation is that the repository is best treated as reference material for a demo topology rather than as a codebase to vendor into a product. If you want to run these services in production, the terms to check are the Confluent ones, and if you want to reuse the compose files themselves in something you ship, ask your legal team what the absence of a licence file means for you, because the default position in most jurisdictions is that without a grant you do not have the rights the file would otherwise give you. The commercial Confluent Platform itself is available separately, and the enterprise and community split in the variants exists precisely because the two are licensed differently. ## Branch per version, and one release tag from 2022 The versioning scheme of this repository is unusual, and understanding it prevents most of the confusion people hit with it. The default branch is not main or master, it is 8.2.0-post, which encodes both a platform version and a suffix. The GitHub Action takes that branch name as an input, so the branch is the unit of pinning. The releases tell a thinner story. The only release listed is 7.1.1-v0, published on 2022-06-23, with the title Run Apache Kafka with Confluent cp-all-in-one. Since then, the activity has been in branches, not in tagged releases, which is consistent with how a repository of compose files is usually maintained: a new branch per platform version, and the action resolving a branch name to a set of compose files. The last push was on 2026-09-17, and the repository is not archived, so the branches are still being maintained. For a reader, the practical consequence is that the release list is not where you look for the current version. You look at the branch names, and you pin the one you want in the github-branch-version input. The cost of that model is that nothing enforces the pin for you. The default is latest, which means a CI job that does not set the input will pick up whatever the latest branch contains at run time, and a change in that branch changes your pipeline behaviour without a version bump in your own repository. ## Conclusion cp-all-in-one fits an engineer who needs a full Confluent Platform topology on a laptop or in a CI job within minutes, and who is comfortable with fixed host ports and a compose file rather than a managed service. It does not fit a production deployment, because the components come up with a demo topology and no persistence story, and the Control Center and enterprise variants carry a commercial licence. Before adopting it, pick the branch that matches your platform version, since the default branch is 8.2.0-post and the compose files are branch specific, and check the port list against what is already bound on the host, since the broker, Schema Registry, Connect and Control Center all publish fixed ports. ## FAQ ### How do I run cp-all-in-one with the GitHub Action? Use confluentinc/cp-all-in-one@v0.1 in a workflow step and set the inputs. The service input selects how far up the docker-compose.yml to start, github-branch-version picks the branch of cp-all-in-one to run with a default of latest, and type selects cp-all-in-one for Confluent Server or cp-all-in-one-community for Apache Kafka. ### Which ports does cp-all-in-one expose? The README lists Kafka broker on 9092, Kafka broker JMX on 9101, Schema Registry on 8081, Kafka Connect on 8083, Control Center on 9021, ksqlDB on 8088, REST Proxy on 8082 and the Flink Job Manager on 9081. They are host ports, so a second instance on the same machine will collide. ### What is the difference between cp-all-in-one and cp-all-in-one-community? cp-all-in-one is the Confluent Enterprise License version built on Confluent Server, while cp-all-in-one-community is the Confluent Community License version built on the Apache Kafka broker. Both include Schema Registry, a Kafka Connect worker with the Datagen Source connector, Control Center, REST Proxy, ksqlDB and Flink. ### Can I run cp-all-in-one against Confluent Cloud? Yes. The cp-all-in-one-cloud directory holds Docker Compose files that run Confluent Platform components, among them Schema Registry, a Kafka Connect worker with the Datagen Source connector, Control Center, REST Proxy or ksqlDB, against Confluent Cloud rather than a local broker. ### What licence applies to the cp-all-in-one repository? The repository itself does not declare a licence, and there is no LICENSE file among the top-level entries. The components it composes have their own terms: the README describes cp-all-in-one and the OAuth variant as the Confluent Enterprise License version and cp-all-in-one-community as the Confluent Community License version, and the cloud variant targets the commercial Confluent Cloud service. ## Sources - [confluentinc/cp-all-in-one on GitHub](https://github.com/confluentinc/cp-all-in-one) - [Issues](https://github.com/confluentinc/cp-all-in-one/issues) - [README](https://github.com/confluentinc/cp-all-in-one/blob/8.2.0-post/README.md) - [Releases](https://github.com/confluentinc/cp-all-in-one/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/confluentinc-cp-all-in-one