Comment on page
soketi is also available via pre-built Docker images. To get started, you may simply run one of our available images:
docker run -p 6001:6001 -p 9601:9601 quay.io/soketi/soketi:1.4-16-debian
Whenever a release, commit, or master merge is performed on the soketi GitHub repository, an image containing the required code to run the application in Docker is published to
The image tags use the following naming conventions:
[git_version]represent the soketi version released to the Git repository. This usually is
x.x.x, unless it's a commit or the master branch. For commits, the value is the SHA hash of the commit. When using the master branch image, the value is
Currently, the only supported
16-alpine. This will be augmented in the future with additional Node versions.
The following example versions are valid:
1.0-16-alpine(points to the latest
1-16-alpine(points to the latest
latest-16-alpine(points to the latest
The advantage of using a distroless container is that in the case of a remote code execution vulnerability the attacker cannot open a shell because there are no shells installed in the container. This makes an attack against the server much harder to achieve, but can also make running something like
kubectl exec <your soketi pod> -- /bin/bashharder to debug since, again, there is no shell available within the container.
Distroless image tagging follows the same convention as the Alpine-based images, but the tags are suffixed with
docker run -p 6001:6001 quay.io/soketi/soketi:1.0-16-distroless
We recommend using the distroless images in production to avoid any security issues involving remote code execution. However, keep in mind that debugging is not enabled and it might be harder to debug live containers / pods.