Introduction

If by "start Kafka permanently" you mean "keep it running after logout, restart it on failure, and bring it up automatically after reboot," the right answer is to run Kafka under a service manager such as systemd. Starting it in a shell with kafka-server-start.sh is fine for experiments, but it is not a production operating model.

Modern Kafka deployments also need one clarification up front: current Kafka versions support KRaft mode, which removes the ZooKeeper dependency. Older guides that start ZooKeeper first are describing older deployments.

Local Start Versus Permanent Service

For a quick local run, you can still start Kafka directly:

bin/kafka-server-start.sh config/server.properties

That keeps Kafka attached to the current shell. Close the session and the broker stops. Even -daemon is only a lightweight backgrounding trick, not a robust service-management solution.

For a permanent setup, you want:

• automatic startup on boot
• restart after failure
• centralized logs
• a dedicated service user

That is exactly what systemd is for on most Linux systems.

Use a Dedicated Kafka User

Do not run Kafka as root. Create a dedicated account and make sure the data and log directories belong to it:

1sudo useradd --system --home /opt/kafka --shell /usr/sbin/nologin kafka
2sudo chown -R kafka:kafka /opt/kafka
3sudo mkdir -p /var/lib/kafka /var/log/kafka
4sudo chown -R kafka:kafka /var/lib/kafka /var/log/kafka

Using a dedicated service user limits blast radius and makes ownership simpler.

A Practical systemd Service

A minimal service file looks like this:

1[Unit]
2Description=Apache Kafka Broker
3After=network.target
4
5[Service]
6Type=simple
7User=kafka
8Group=kafka
9ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties
10ExecStop=/opt/kafka/bin/kafka-server-stop.sh
11Restart=on-failure
12RestartSec=5
13LimitNOFILE=100000
14
15[Install]
16WantedBy=multi-user.target

Save that as /etc/systemd/system/kafka.service, then load and enable it:

sudo systemctl daemon-reload
sudo systemctl enable kafka
sudo systemctl start kafka

Now Kafka starts at boot and restarts if the process exits unexpectedly.

KRaft Versus ZooKeeper

This is the part many outdated guides miss. In newer Kafka deployments, KRaft is the default architecture and you do not separately run ZooKeeper. Your broker configuration needs the right KRaft settings and formatted storage before first startup.

For older ZooKeeper-based clusters, you still need the metadata service running before the broker. If you are inheriting an existing installation, check the configuration files before copying instructions from a random guide.

The operational lesson is simple: know which architecture you are running before you automate the service.

Check Service Health the Right Way

Once the service is installed, use systemctl and journalctl instead of guessing:

sudo systemctl status kafka
sudo journalctl -u kafka -f

Kafka's own scripts also help confirm the broker is really usable:

bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

That is better than assuming the process is healthy just because a PID exists.

Environment and Limits Matter

Kafka is sensitive to JVM settings, disk paths, and file descriptor limits. A service file is a good place to make those assumptions explicit.

For example:

Environment="KAFKA_HEAP_OPTS=-Xms1G -Xmx1G"
Environment="LOG_DIR=/var/log/kafka"
LimitNOFILE=100000

Those values depend on the workload, but the general principle is correct: production services should not rely on whatever random shell environment happened to start them.

Containers and Orchestration

If Kafka runs in Docker, Kubernetes, or another orchestrator, that platform replaces systemd as the service manager. The same goals still apply:

• automatic restart
• declarative startup
• health checking
• clear log collection

So the exact tool changes, but the pattern does not.

Common Pitfalls

The most common mistake is assuming nohup or -daemon is equivalent to a proper service. It is not. Those approaches do not give you the same restart semantics, observability, or startup management.

Another common issue is following ZooKeeper-based instructions on a KRaft deployment, or the reverse. Kafka setup has changed materially across versions.

People also run Kafka as root, which is unnecessary and risky. Use a dedicated service account.

Finally, do not declare the service done after systemctl start. Verify that the broker actually accepts client connections and that the data directories and listeners are configured correctly.

Summary

• For a permanent Kafka server on Linux, prefer systemd over shell backgrounding tricks.
• Use a dedicated kafka service account and explicit data and log directories.
• Modern Kafka often runs in KRaft mode, so ZooKeeper instructions may be outdated.
• Enable restart-on-failure and verify health with systemctl, journalctl, and Kafka CLI tools.
• The goal is not just "process stays up," but "broker starts predictably, survives failure, and is operable."