restic Rest Server

Launch the image from the Azure Marketplace listing. Choose your resource group, region, size (Standard_B2s or larger) and SSH key. Attach the offer's data disk, and open ports 22 and 443 in the network security group.

To deploy with the Azure CLI instead, run:

RG="rest-server-prod"; LOCATION="eastus"; VM_NAME="rest-server1" IMAGE_URN="sac1647283583153:restic-rest-server-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:restic-rest-server-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 443 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

On first boot, the VM generates a unique username and password and writes them to a root-only file. SSH in as azureuser and read the file:

sudo cat /root/rest-server-info.txt

The file contains REST_SERVER_USER, REST_SERVER_PASSWORD, REST_SERVER_URL (the HTTPS endpoint using this VM's public IP) and REST_SERVER_REPO (a ready-to-use restic repository string). These credentials are unique to this VM and are not part of the image. Keep the file secret.

Confirm that the services are active and check the network listeners. Rest Server binds to loopback (127.0.0.1:8000), and nginx binds the public HTTPS endpoint on 0.0.0.0:443:

sudo systemctl start rest-server.service nginx.service systemctl is-active rest-server.service nginx.service /opt/rest-server/rest-server --version ss -tlnH | grep -E ':8000|:443'

The restic client talks to this server over HTTPS. The endpoint is an IP address with a self-signed certificate, so use --insecure-tls or trust the certificate (see below).

The following block runs a quick self-test on the VM. It installs a restic client, reads the VM's own credentials, and runs a full round trip against the local endpoint: initialise a repository, back up a file, list the snapshot, then restore the file and print its contents.

curl -fsSL -o /tmp/restic.bz2 https://github.com/restic/restic/releases/download/v0.18.0/restic_0.18.0_linux_amd64.bz2 bunzip2 -f /tmp/restic.bz2 && chmod +x /tmp/restic
U=$(sudo grep '^REST_SERVER_USER=' /root/rest-server-info.txt | cut -d= -f2-)
P=$(sudo grep '^REST_SERVER_PASSWORD=' /root/rest-server-info.txt | cut -d= -f2-)
export RESTIC_REPOSITORY="rest:https://$U:$P@127.0.0.1/restic/demo"
export RESTIC_PASSWORD="choose-a-strong-repository-encryption-password" echo "hello from sac" > /tmp/demo.txt /tmp/restic --insecure-tls init /tmp/restic --insecure-tls backup /tmp/demo.txt /tmp/restic --insecure-tls snapshots /tmp/restic --insecure-tls restore latest --target /tmp/restored cat /tmp/restored/tmp/demo.txt

The RESTIC_PASSWORD above is the repository encryption password that you choose. It encrypts the backup data and is separate from the REST_SERVER_PASSWORD that authenticates you to the server. Keep both safe, because backups cannot be decrypted without the repository password.

There is no anonymous access. A request with no credentials, and a request with the wrong password, are both rejected with HTTP 401. Run the following to see it:

curl -ks -o /dev/null -w 'no credentials: HTTP %{http_code}\n' https://127.0.0.1/restic/
U=$(sudo grep '^REST_SERVER_USER=' /root/rest-server-info.txt | cut -d= -f2-)
curl -ks -o /dev/null -w 'wrong password: HTTP %{http_code}\n' -u "$U:wrong-password" https://127.0.0.1/restic/
curl -ks -o /dev/null -w 'correct password: HTTP %{http_code}\n' \
  -u "$U:$(sudo grep '^REST_SERVER_PASSWORD=' /root/rest-server-info.txt | cut -d= -f2-)" https://127.0.0.1/restic/

The credentials file is root-only (0600), the server runs with --htpasswd-file and --private-repos, and repository data lives on the dedicated data disk mounted at /var/lib/restic. Confirm all three:

sudo stat -c '%n %a %U:%G' /root/rest-server-info.txt systemctl show rest-server.service -p ExecStart --value | grep -o -- '--htpasswd-file[^ ]* --private-repos' df -h /var/lib/restic | tail -1

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Rest Server for restic. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, then create or select a security group that opens port 22 from your management network and port 443 from the machines that back up to the server.

Leave the root volume at the default size or larger. The repository store lives on a separate data volume that is provisioned automatically.

Select Launch instance. First-boot initialisation takes a few seconds after the instance state becomes Running and the status checks pass.

Run the following block to launch an instance from the SecureAnyCloud Rest Server Marketplace AMI into an existing subnet and security group.

Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID and <security-group-id> with a security group that opens port 22 and port 443.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=rest-server}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name. You can find both in the EC2 console or with aws ec2 describe-instances.

Connect over SSH with your key pair. The login user for Ubuntu 24.04 is ubuntu.

ssh -i /path/to/your-key.pem ubuntu@<public-ip>

The unique username and password generated on first boot are in a root-only file. Read it with sudo:

sudo cat /root/rest-server-aws-credentials.txt

The file contains:

• REST_SERVER_USER and REST_SERVER_PASSWORD: the restic username and password for this instance
• REST_SERVER_URL: the HTTPS endpoint, https://<instance-public-ip>/
• REST_SERVER_REPO: a ready-to-paste restic repository prefix

Keep this file secret. It holds the credentials for your backup repository server.

Rest Server runs as a systemd service bound to 127.0.0.1:8000 only. nginx terminates TLS on port 443 as the single network-facing surface. Confirm that both services are active and that rest-server listens on loopback only:

systemctl is-active rest-server.service nginx.service
sudo ss -ltnp | grep -E ':8000|:443|:80 ' cat /opt/rest-server/VERSION

rest-server listens on 127.0.0.1:8000 and never on a public interface, while nginx owns ports 443 and 80. This keeps the server from ever being an open, anonymous repository.

nginx fronts the entire REST backend with HTTP basic authentication, so an unauthenticated request is rejected. An unauthenticated /healthz probe is available for load balancers. Run the following to confirm the boundary:

# no credentials -> 401 Unauthorized (the server is never open)
curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/restic/
# a wrong password is also rejected -> 401
curl -sk -u restic:wrong-password -o /dev/null -w '%{http_code}\n' https://127.0.0.1/restic/
# unauthenticated load-balancer liveness probe -> 200
curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/healthz

On any machine that has the restic client installed, point restic at this instance and run a normal backup. The TLS certificate is self-signed per instance, so either copy the instance's certificate from /etc/nginx/tls/rest-server.crt and trust it, or pass --insecure-tls.

Use the username and password from your credentials file, and choose a strong repository encryption password of your own.

# from your own machine, using the per instance credentials export RESTIC_REPOSITORY="rest:https://restic:<REST_SERVER_PASSWORD>@<public-ip>/restic/myrepo" export RESTIC_PASSWORD="choose-a-strong-repository-encryption-password" restic --insecure-tls init restic --insecure-tls backup /path/to/data restic --insecure-tls snapshots

restic init creates the repository under your user's namespace on the data volume. restic backup uploads deduplicated, encrypted data, and restic snapshots lists what has been stored. Because the server runs with --private-repos, the restic user can access only repositories under its own namespace (rest:https://restic:...@<host>/restic/<repo>).

The repository store is on the dedicated data volume. To see where your backups live and how much room remains, run:

df -h /var/lib/restic

To roll the server out across a fleet, distribute the certificate and the per-instance credentials to the machines that back up to it. For production, replace the self-signed certificate with one signed by your own certificate authority or a public CA for your domain. Add further restic users with htpasswd.