HyperSpace Service Agent for Synology NAS deployments.
1.3K
Primary HyperSpace service workload with REST and CLI endpoints.
Expose services securely through HyperSpace.
This image is the Synology-specific distribution of HyperSpace Service Agent. It is meant to be installed and maintained from an SSH session on the NAS, not from the Container Manager launch wizard.
Repository: whitestarcommunications/synology-hyperspaceserviceagent
Current release tag:
0.04.16.26.4The NAS needs:
sudo/dev/net/tun available, or permission for the installer to create itThe installer uses sudo because it may need to:
/dev/net/tunmodprobe tun/volume1/...Connect to the Synology host with an account that is allowed to run sudo.
ssh <synology-user>@<nas-host>
You do not need to switch to an interactive root shell first. The setup block
below uses sudo for the commands that need it, but you should validate sudo
before you paste any setup commands.
Do not continue until this succeeds. The Synology setup path needs elevated privileges for Docker access, TUN preparation, and persistent-directory creation.
sudo -v
If your environment prefers a root shell, use sudo -i instead and then run
the next steps from that shell.
Each Synology image now carries its own NAS-side installer bundle at
/opt/hyperspace-synology. The block below pulls the exact image from Docker
Hub and copies that bundled installer onto the NAS filesystem.
The extracted directory contains:
install.shupdate.shclean.sh.envREADME.mdThat local directory is what you will execute on the NAS.
set -euo pipefail
IMAGE='whitestarcommunications/synology-hyperspaceserviceagent:0.04.16.26.4'
BUNDLE_ROOT='/volume1/docker/hyperspace-installers'
BUNDLE_DIR="${BUNDLE_ROOT}/service-0.04.16.26.4"
TEMP_CONTAINER='hyperspace-service-bundle-extract'
if [ "$(id -u)" -eq 0 ]; then
SUDO=''
else
echo "This setup requires sudo or a root shell before it will touch Docker or NAS storage." >&2
command -v sudo >/dev/null 2>&1 || {
echo "This setup requires sudo or a root shell." >&2
exit 1
}
sudo -v || {
echo "sudo authentication failed. No setup commands were run." >&2
exit 1
}
SUDO='sudo'
fi
command -v docker >/dev/null 2>&1 || {
echo "Docker CLI is not installed on this NAS." >&2
exit 1
}
${SUDO} docker info >/dev/null
${SUDO} docker pull "${IMAGE}"
${SUDO} mkdir -p "${BUNDLE_ROOT}"
${SUDO} rm -rf "${BUNDLE_DIR}"
${SUDO} mkdir -p "${BUNDLE_DIR}"
${SUDO} docker rm -f "${TEMP_CONTAINER}" >/dev/null 2>&1 || true
${SUDO} docker create --name "${TEMP_CONTAINER}" "${IMAGE}" >/dev/null
${SUDO} docker cp "${TEMP_CONTAINER}:/opt/hyperspace-synology/." "${BUNDLE_DIR}"
${SUDO} docker rm -f "${TEMP_CONTAINER}" >/dev/null
cd "${BUNDLE_DIR}"
ls
If you want the installer stored somewhere else on the NAS, change
BUNDLE_ROOT before you run the block.
From the extracted bundle directory on the NAS:
cd /volume1/docker/hyperspace-installers/service-0.04.16.26.4
sudo ./install.sh
install.sh handles the full host setup:
/dev/net/tun when the NAS allows itThe created container should appear in Synology Container Manager after the command finishes.
By default, install.sh creates three persistent folders under:
/volume1/HyperSpaceServiceAgentThose directories are:
state: long-lived HyperSpace state and identity datalog: runtime logsagent: profile-specific runtime files under /root/serviceAgentThese folders are important because they let the agent keep its state when you replace the container with a newer image.
The generated SSH bundle includes three commands:
install.sh: first install or replace the current containerupdate.sh: pull a newer image tag and recreate the container in placeclean.sh: remove the container, image, and persisted agent dataCommon examples:
sudo ./update.sh
sudo ./update.sh --image-tag 0.04.16.26.4
sudo ./update.sh --use-bundle-tag
sudo ./clean.sh --yes
update.sh defaults to Docker Hub latest. If you want to stay on the
bundle's pinned release, use --use-bundle-tag.
clean.sh --yes is the reset-to-zero path. It removes the container and the
persisted data configured in .env, so the next install.sh run starts with a
fresh Synology directory tree.
Treat install.sh, update.sh, and clean.sh as privileged commands. Run
sudo -v first and stop immediately if authentication fails.
Once the container is running, open the browser UI:
http://<nas-host>:42588/api/uiCheck readiness:
curl http://<nas-host>:42588/api/openapi.jsonCheck the current identity from inside the container:
sudo docker exec hyperspace-service /bin/bash -lc 'HS_IDENTITY_URL="http://127.0.0.1:42587/api/command/whoAmI" /usr/local/bin/extractIdentityValue.sh'
hyperspace-service.42588./var/lib/hyperspace./var/log/hyperspace.127.0.0.1:8421./volume1/HyperSpaceServiceAgent unless you chose a different HS_ROOT.The most common cause is a missing TUN device on the NAS host.
From the NAS shell, check:
ls -l /dev/net/tun
If the device is missing, rerun the setup from a root shell. If Synology still
does not allow install.sh to create it, prepare /dev/net/tun on the
host first and then rerun sudo ./install.sh.
If install.sh fails with a Docker permission error, stop and validate
sudo -v again before retrying.
If install.sh fails with a port binding error, another container is already
using one of the host ports. Edit .env in the extracted bundle, then rerun
sudo ./install.sh.
whitestarcommunications/synology-hyperspaceconnectionagent
Create secure outbound HyperSpace connections from this device.whitestarcommunications/synology-hyperspaceproxyagent
Accept secure inbound HyperSpace traffic and relay it to local services.whitestarcommunications/synology-hyperspaceserviceagent
Expose services securely through HyperSpace.Content type
Image
Digest
sha256:3b747ef25…
Size
292.8 MB
Last updated
6 months ago
docker pull whitestarcommunications/synology-hyperspaceserviceagent