Skip to main content

​
Systemd service

If you install Konduktor using the one-liner script, we’ll set up a systemd service with the following config: 
[Unit]
Description=Konduktor Agent Control Plane
Documentation=https://github.com/yakkomajuri/konduktor-oss
After=network.target

[Service]
Type=simple
User=${KONDUKTOR_USER} # user you ran the install script in
Group=${KONDUKTOR_USER}
WorkingDirectory=${REPO_DIR}
Environment=HOME=${KONDUKTOR_HOME} # $HOME by default
Environment=PATH=${HOME}/.local/bin:/usr/local/bin:/usr/bin:/bin
${EXTERNAL_URL:+Environment=KONDUKTOR_EXTERNAL_URL=${EXTERNAL_URL}} # EXTERNAL_URL is set to your public IP or the configured domain name
Environment=KONDUKTOR_UI_DIR=${REPO_DIR}/ui/dist # REPO_DIR is $HOME/konduktor-oss by default
ExecStart=${KONDUKTOR_SERVER_BIN} start --host 127.0.0.1 --port 8080 # looks for the konduktor-server binary on the PATH else falls back to $HOME/.local/bin/konduktor-server
Restart=on-failure
RestartSec=5
KillMode=process
StandardOutput=journal
StandardError=journal
SyslogIdentifier=konduktor

# Hardening
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=${KONDUKTOR_HOME}/.konduktor ${KONDUKTOR_HOME}/.claude ${KONDUKTOR_HOME}/.local ${KONDUKTOR_HOME}/.cache /tmp

[Install]
WantedBy=multi-user.target
You’ll see that we have ProtectSystem set to strict and just make a few useful paths available via ReadWritePaths so that Claude Code and other dependencies can work. If you know what you’re doing, you can change these to give Konduktor more or less access.

​
Attack vectors

Provided you install Konduktor on a remote machine as recommended, what’s at risk is:
  • Your Konduktor instance
  • Your code (if it’s not public)
  • Your gh token
  • Your Claude Code token
This is significantly lower risk than a lot of workflows people run on their own machines, but nevertheless a risk. The main risk here comes from prompt injection attacks. For example, if Konduktor was looking through GitHub issues on your repo and finds a legitimate-looking issue that contains a command at the bottom that tells it to make a request to some URL with your gh credentials. Konduktor is currently as exposed to this as Claude Code itself, which has some strong defenses both at the harness and model layers. However, the risk certainly still exists. If you want to mitigate risks, there are a few things you can do, such as:
  • Use a separate GitHub user that you create for automated use e.g. <yourusername>-bot and that only has access to certain repos
  • Limit the scopes of the GitHub PAT you use even if it potentially limits Konduktor in the process
  • Use a separate Claude Code subscription for Konduktor specifically
But if you’re very sensitive about security, the main thing you can do is limit the instance at the networking layer. This means doing one of the following:
  1. Enabling the firewall in Cloud providers that support it
  2. Using something like ufw since Konduktor’s systemd profile prevents it from accessing it
  3. Having Konduktor only available inside a VPN like Tailscale
  4. Setting up your own firewall service that sits between NGINX and Konduktor or manage the reverse proxy yourself
If you take these actions, you can then only whitelist IPs considered safe for traffic, such as your own as well as those from e.g. npm and GitHub. Or you can cut your Konduktor instance’s access to the wider internet altogether and just have a way for you to access it, and maybe GitHub for PRs and webhooks. The more you limit Konduktor’s internet access the less it can do independently around e.g. installing packages or searching for documentation, but at the same time you definitely become more secure. The approach to use here will depend on your security stance. Nevertheless, there are plans to do more work on this front in Konduktor natively, and you’re more than welcome to contribute your thoughts on the topic too.