Run in Docker

The official image is docker.io/syncplify/sc-conn, built for linux/amd64 and linux/arm64.

Start it

docker run -d --name sc-conn -v sc-conn-data:/data \
  --log-opt max-size=50m --log-opt max-file=5 \
  docker.io/syncplify/sc-conn

The volume is not optional

/data holds the Connector's identity, its database and your at rest encryption keys. Without a volume, every container restart is a brand new Connector that has to enroll again, and any encryption key it created is gone with the container.

Bound the container's own log

The Connector writes its service log to standard output, which Docker captures with its json-file driver, and that driver keeps everything unless you cap it. The two --log-opt flags above keep it to five files of 50 MB. Set them on every docker run of this image, or set the same defaults once in the daemon's /etc/docker/daemon.json under log-opts.

This is only the service log. The tamper evident audit log lives under /data/audit, is always on, and has its own retention (by age and by size) in the admin console under Settings, Logging.

Enroll it

docker exec sc-conn /usr/local/bin/sc-conn enroll \
  --portal https://portal.sftp.cloud --code XXXXX-XXXXX-XXXXX-XXXXX
docker restart sc-conn

The restart is required: enrollment writes the identity, and the enforcement plane starts from it.

Get the code from Storage, then Connect storage, in the Portal. See Connect your storage.

Reach the admin console

The admin console binds 127.0.0.1:8883 inside the container, which is not reachable from outside it. Two ways to get to it.

Exec into the container and use the CLI for the few things it covers.

Or bind it to all interfaces inside the container and publish the port. Publish it to loopback on the host, or to a LAN address; the console is never meant to be internet reachable.

The bind address lives in the Connector's own database, which is single writer, so it can only be changed while the Connector is stopped:

docker stop sc-conn && docker rm sc-conn

docker run --rm -v sc-conn-data:/data docker.io/syncplify/sc-conn \
  config web --bindto 0.0.0.0:8883 --tls selfsigned

docker run -d --name sc-conn \
  -v sc-conn-data:/data \
  -p 127.0.0.1:8883:8883 \
  --log-opt max-size=50m --log-opt max-file=5 \
  docker.io/syncplify/sc-conn

--tls selfsigned generates a certificate under the data directory at the next start, so the console is then at https://127.0.0.1:8883 with a one time browser warning. --tls none serves plain HTTP and is only sensible when the published port is bound to loopback on the host.

Using a host directory instead of a named volume

A bind mount keeps the host directory's own ownership, which the image cannot fix. The container runs as an unprivileged user, so set the ownership first:

sudo mkdir -p /srv/sc-conn-data
sudo chown 65532:65532 /srv/sc-conn-data
docker run -d --name sc-conn -v /srv/sc-conn-data:/data \
  --log-opt max-size=50m --log-opt max-file=5 \
  docker.io/syncplify/sc-conn

Or run the container with --user matching the directory's owner.

Mounting your storage

If this Connector serves a local disk, mount that into the container too, and use the container path when you create the virtual file system:

docker run -d --name sc-conn \
  -v sc-conn-data:/data \
  -v /srv/files:/srv/files \
  docker.io/syncplify/sc-conn

For S3, Azure, Google Cloud or a remote SFTP server, nothing needs mounting; the Connector reaches them over the network.

Updating

A container never updates itself

This is by design. The image is the unit of deployment.

The Connector detects that it is in a container, and its Updates page becomes informational: it reports version skew and never applies anything.

To update, pull the new tag and recreate the container. The named volume carries the identity across:

docker pull docker.io/syncplify/sc-conn
docker stop sc-conn && docker rm sc-conn
docker run -d --name sc-conn -v sc-conn-data:/data docker.io/syncplify/sc-conn

There is no re-enrollment, no reconfiguration and no key loss, because none of that lives in the image.

Image signatures

Published images are signed with cosign, and the signed digest is recorded in the release channel index. Verify before you deploy if your policy requires it.

What the image is

A distroless base with one binary in it, running as a non root user. There is no shell, no package manager and no interactive login inside the container.