Si
Storage Azure

Sync-in on Ubuntu 24.04 on Azure User Guide

| Product: Sync-in on Ubuntu 24.04 LTS on Azure

Overview

Sync-in is an open-source, self-hosted platform for file storage, sharing, synchronization and collaboration - a lightweight alternative to hosted drives that keeps your files on infrastructure you control. Users store files in personal and shared spaces, share them with links and granular permissions, synchronize across devices, and collaborate as a team. The cloudimg image runs the official pinned Sync-in container together with MariaDB behind nginx over HTTPS: the application and database are published on the loopback interface only, and nginx terminates TLS in front of them. Backed by 24/7 cloudimg support.

What is included:

  • Sync-in 2.4.4 from the official pinned container image syncin/server:2.4.4, baked into the image and published on loopback 127.0.0.1:8080
  • MariaDB 11 (mariadb:11) as the database, on the internal Docker network only
  • nginx terminating TLS on :443 in front of Sync-in, with :80 redirecting to HTTPS
  • A per-VM administrator account and per-VM secrets (database password, encryption key, and JWT access and refresh secrets) generated on first boot - no default or shared credential ships in the image, and the upstream default sync-in/sync-in account is never created
  • docker.service, sync-in.service and nginx.service as systemd units, enabled and active
  • 24/7 cloudimg support

Sync-in is distributed under the GNU Affero General Public License v3.0-or-later (AGPL-3.0-or-later).

Secure by default - a per-VM administrator credential

This image ships with no default or shared login: no database, no user accounts and no secrets ship in the image. On first boot a one-shot service resolves your public URL, regenerates a per-VM TLS certificate, generates a fresh database password, encryption key and token signing secrets, recreates the stack on an empty database, and creates the single administrator account with a unique per-VM password that it writes to a root-only file. Sync-in's upstream tooling would otherwise fall back to a well-known sync-in/sync-in login; the image always supplies an explicit login and a long random password, so that default account is never created. You retrieve the password over SSH and change it after your first login.

Sync-in login page served over HTTPS

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point (the running stack idles well under 1 GiB used); scale up for large teams or heavy file volumes. NSG inbound: allow 22/tcp from your management network, and 80/tcp + 443/tcp from wherever you browse Sync-in (:80 only redirects to :443).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Sync-in by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22), HTTP (80) and HTTPS (443). Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name sync-in \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name sync-in --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name sync-in --port 443 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

The message of the day shows your VM's Sync-in URL and administrator login.

Step 4 - Confirm the services are running

Sync-in runs as three systemd units - the Docker engine, the Sync-in Compose stack and nginx:

systemctl is-active docker.service sync-in.service nginx.service
active
active
active

The application and database are published only on the loopback / internal Docker network; nginx is the only service bound to public ports (:80 and :443):

sudo ss -tln | grep -E ':(80|443|8080) '
LISTEN 0      4096       127.0.0.1:8080      0.0.0.0:*
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*

The web UI is served over HTTPS, and plain HTTP redirects to it:

curl -sk -o /dev/null -w 'https:// -> %{http_code}\n' https://127.0.0.1/
curl -s  -o /dev/null -w 'http://  -> %{http_code}\n' http://127.0.0.1/
https:// -> 200
http://  -> 301

Sync-in services, loopback + nginx binding, and HTTPS health on the VM

Step 5 - Read the per-VM administrator credential

On first boot the VM writes a root-only file with your Sync-in URL, the administrator login and the unique password generated for this VM:

sudo grep -E '^SYNC_IN_URL=|^SYNC_IN_ADMIN_LOGIN=' /root/sync-in-credentials.txt
SYNC_IN_URL=https://<vm-public-ip>
SYNC_IN_ADMIN_LOGIN=admin

The SYNC_IN_ADMIN_PASSWORD line in that file holds your unique password. Only the per-VM credential is accepted - a wrong password, and the upstream default sync-in/sync-in, are both rejected (a successful token request returns 201, a rejected one 401):

L=$(sudo grep '^SYNC_IN_ADMIN_LOGIN=' /root/sync-in-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^SYNC_IN_ADMIN_PASSWORD=' /root/sync-in-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'per-VM password -> HTTP %{http_code}\n' -X POST https://127.0.0.1/api/auth/token \
  -H 'Content-Type: application/json' --data "{\"login\":\"$L\",\"password\":\"$P\"}"
curl -sk -o /dev/null -w 'default sync-in -> HTTP %{http_code}\n' -X POST https://127.0.0.1/api/auth/token \
  -H 'Content-Type: application/json' --data '{"login":"sync-in","password":"sync-in"}'
per-VM password -> HTTP 201
default sync-in -> HTTP 401

Secure by default: the per-VM info file and a live token round-trip

Step 6 - First login

Open Sync-in in your browser (accept the self-signed certificate warning, or install a trusted certificate first - see below):

https://<vm-public-ip>/

Enter the administrator login (admin) and the SYNC_IN_ADMIN_PASSWORD from Step 5, then Sign in. Change your password from your account settings immediately after your first sign-in.

Working with files and spaces

Sync-in organises storage into Personal files and shared Spaces. Your Personal area is your private drive; upload files by dragging them into the file list, then browse, preview, download, and share them.

The Sync-in Personal files view with uploaded files

Create Spaces to collaborate with a team - each space has its own files and members, and you control who can view or edit through granular permissions:

The Sync-in Spaces view

The Recents view keeps your latest files and comments in one place so you can pick up where you left off, and the Shared section tracks what has been shared with you, by you, and via links:

The Sync-in Recents activity view

Step 7 - The official pinned container images

Sync-in runs from the official upstream container images, pinned to exact tags and baked into the VM image (no runtime pull), published on the loopback interface only:

sudo docker ps --format 'table {{.Image}}\t{{.Status}}\t{{.Ports}}'
IMAGE               STATUS         PORTS
syncin/server:2.4.4 Up 6 minutes   127.0.0.1:8080->8080/tcp
mariadb:11          Up 6 minutes

The pinned Sync-in and MariaDB container images and the loopback-published service

Adding more users

Sync-in is multi-user. Sign in as the administrator and open Administration in the web interface to create and manage user accounts, then invite them into your spaces. Each user gets their own Personal area and only sees the spaces they are a member of.

Security updates

The image is captured fully patched (including Ubuntu phased updates) and unattended-upgrades stays enabled, so security patches keep flowing on your VM. There should be no held-back packages:

apt-mark showhold

The Docker engine and nginx are managed by systemd units; the application itself is the pinned container image described above. The running stack idles comfortably within the 4 GiB of a Standard_B2s:

free -m | head -2

The OS security baseline and the Sync-in memory footprint on Standard_B2s

Your data

Sync-in stores its database and your uploaded files in Docker named volumes on the VM's OS disk:

sudo docker volume ls | grep sync-in

Snapshot the VM's OS disk in Azure to back up your database and files, or export the sync-in_data volume to external storage on a schedule.

Enabling a trusted TLS certificate

The image ships a per-VM self-signed certificate so HTTPS works out of the box; browsers will warn until you install a trusted certificate. For production, point a DNS A record at the VM's public IP, ensure 443/tcp is open in the NSG, then install certbot and let it manage the nginx certificate. Replace the placeholders with your own domain and email:

sudo apt-get update
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com -m you@example.com --agree-tos

certbot configures the HTTPS server block and sets up automatic renewal, and Sync-in is then available at your domain with a trusted certificate that desktop and mobile sync clients trust.

Upgrading Sync-in

Sync-in runs from a pinned container image. To upgrade, edit the image tag in /opt/sync-in/docker-compose.yml, then from /opt/sync-in run sudo docker compose pull and sudo docker compose up -d. The database schema migrates automatically on start. Always snapshot the OS disk first. cloudimg support can assist with planning and performing upgrades.

Support

This image is backed by 24/7 cloudimg support covering deployment, upgrades, integrations, TLS termination and user administration. Contact us by email and chat.

Sync-in is a trademark of its respective owner; cloudimg is an independent image builder and is not an official Sync-in partner, distributor or reseller. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.