Storage Azure

AIStore 1.4 Object Storage on Ubuntu 24.04 on Azure User Guide

Last updated: 2026-08-07 | Product: AIStore 1.4 Scalable Object Storage for AI and ML Datasets on Ubuntu 24.04 on Azure

Overview

This guide covers the deployment and use of AIStore (AIS) 1.4 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images.

AIStore is an open source object storage system from NVIDIA, built for the read heavy, high throughput access patterns of AI and machine learning training. It stores objects in buckets on local disks and presents them two ways at once: through its own cluster aware API and ais command line client, and through an S3 compatible REST API that unmodified S3 tools and SDKs, such as the AWS CLI and boto3, can point at directly. That makes it a practical home for training datasets, shards, model checkpoints and other large artifacts, without rewriting the code that reads them.

This image is a complete single node cluster. AIStore normally scales out across many storage nodes; this appliance runs the smallest useful shape of the same software, one gateway and one storage target, on one VM, managed by systemd. No Kubernetes, no second VM, no external coordination service and no cloud account are required. Everything below works against local disk.

AIStore has no web interface. It is a storage system: objects in, objects out. Everything here is done with the ais client, the AWS CLI, boto3 or plain HTTP.

Security by design. AIStore in its default upstream form is unauthenticated, and an open S3 compatible object store on a reachable address is a data exposure shape. This image inverts that:

Authentication is on in the shipped configuration. The cluster runs with AIStore's own AuthN token service enabled from its very first start, so every gateway path, native and S3 alike, requires a valid token and is refused with HTTP 401 or 403 without one.
Nothing is baked into the image. The captured image contains no signing key, no password and no cluster identity. All three services physically cannot start until first boot has generated your VM's own signing key and administrator password, so there is no window in which an unauthenticated object store is listening and no secret is ever shared between customers.
The only unauthenticated path is the liveness probe. GET /v1/health returns HTTP 200 and an uptime header, and nothing else. It discloses no version, no configuration, no cluster map and no data, so an Azure Load Balancer or Application Gateway health probe works without a credential.
Object data lives on its own volume. A dedicated 32 GB data disk is attached and mounted at /ais/disk0, and that is the storage target's only mountpath, so objects never consume the operating system disk.

What is included:

AIStore 1.4.9 built from the pinned upstream release tag, running under systemd as ais-proxy.service (the gateway) and ais-target.service (the storage node)
AIStore AuthN, the token service that issues and validates the JSON Web Tokens the cluster requires, running as ais-authn.service
The ais command line client, built from the same source revision as the cluster so client and server versions always agree
The S3 compatible API on the gateway, with upstream's reverse proxy mode enabled so a stock S3 client talks to one endpoint and one port
The AWS CLI v2 and boto3 already installed, so the S3 API can be exercised the moment you connect
ais-env and aistore-selfcheck, two bundled commands that set up an authenticated shell in one line and verify the whole appliance end to end
A per VM signing key and administrator password generated on first boot and written to a root only credentials file
Unattended security upgrades left enabled so the appliance keeps receiving patches

Prerequisites

Active Azure subscription, an SSH public key, and a VNet and subnet in the target region
Subscription to this listing on Azure Marketplace
A Network Security Group allowing TCP 22 for administration and TCP 8080 for the AIStore gateway, which carries both the native API and the S3 compatible API. Restrict 8080 to the subnet your training nodes or applications run in rather than opening it to the internet. TCP 8081 is the storage target and is only needed by clients that use the native API from another machine; the S3 API never needs it. The intra cluster ports 9080, 10080, 9081 and 10081 are bound to the VM's own network address and never need to be opened.

Recommended virtual machine size: Standard_B2s with 2 vCPU and 4 GB RAM suits evaluation and light dataset serving. For real training workloads choose a size with more vCPU, memory and network bandwidth, such as Standard_D4s_v5 or above, and add mountpaths on larger disks as described later in this guide.

Deploy the virtual machine

Deploy from the Azure Portal by selecting the image from Azure Marketplace, choosing your VM size, and supplying your SSH public key for the azureuser account. Or deploy from the Azure CLI.

These commands run on your own workstation, not on the VM:

az vm create \
  --resource-group my-resource-group \
  --name my-aistore-vm \
  --image <this-marketplace-image> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

az vm open-port --resource-group my-resource-group --name my-aistore-vm --port 8080

The dedicated data disk is part of the image, so it is attached, formatted and mounted at /ais/disk0 automatically. You do not create or attach it yourself.

Connect over SSH once the VM is running:

ssh azureuser@<vm-ip>

Confirm the cluster is healthy

First boot generates this VM's signing key and administrator password, starts the three services and forms the cluster. It normally completes within a minute of the VM becoming reachable.

Check that all three services are running:

systemctl is-active ais-authn.service ais-proxy.service ais-target.service

Expected output

active
active
active

ais-env reads the root only credentials file, logs in to AuthN and prints ready to use exports for both the native client and any S3 client. Evaluate it once per shell, then ask the cluster how it is doing:

eval "$(sudo ais-env)"
ais show cluster

Expected output

PROXY        MEM USED(%)     MEM AVAIL   SYS CPU(%)  UPTIME  STATUS  ALERT
p[LYzPrJRY][P]   1.39%       3.21GiB     9%      9m30s   online  low-cpu

TARGET       MEM USED(%)     MEM AVAIL   CAP USED(%)     CAP AVAIL   SYS CPU(%)  UPTIME  STATUS  ALERT
t[jIDUkeFR]  1.35%       3.21GiB     5%      29.565GiB   4%      1m20s   online  low-cpu

Cluster:
   CLI Endpoint:    http://10.0.0.19:8080
   Proxies:     1
   Targets:     1 (one disk)
   Capacity:        used 1.64GiB (5%), available 29.57GiB
   Cluster Map:     version 276, UUID OY_9UiN0O, primary p[LYzPrJRY]
   Software:        4.9.a809c60
   Backend:     AWS, Azure
   Deployment:      linux
   Status:      2 online
   Rebalance:       -
   Authentication:  enabled

The node identifiers, the cluster map UUID and the addresses are unique to your VM, so they will differ from the example above. Authentication: enabled is the line to look for: it confirms the cluster is refusing unauthenticated requests. The low-cpu alert is AIStore noting that a 2 vCPU VM is below what it considers a production storage node; it is advisory and the cluster is fully functional. It disappears on a larger VM size.

Confirm object data is on the dedicated volume and not the operating system disk:

eval "$(sudo ais-env)"
ais show storage mountpath
df -h /ais/disk0

Expected output

jIDUkeFR
    Used: min= 5%, avg= 5%, max= 5%  
                    /ais/disk0 /dev/sdc(ext4)
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         32G  112K   30G   1% /ais/disk0

The three AIStore services active, the single node cluster online with authentication enabled, and the storage target using the dedicated /ais/disk0 volume

Retrieve your per VM credentials

First boot generates the administrator password for this VM and writes it, with the endpoint addresses, to a root only file. Read it when you need to authenticate from another machine:

sudo cat /root/aistore-credentials.txt

The file records the administrator username and password, the gateway URL, the S3 endpoint URL, the AuthN URL and this VM's public address, along with copy ready example commands. It is the only place the password is written, it is mode 0600 and owned by root, and it exists only on your VM.

On the VM itself you rarely need the password at all, because ais-env reads that file for you and exports a short lived token:

sudo ais-env | sed -E "s/(TOKEN)='.*'/\1='<jwt>'/"

Expected output

export AIS_ENDPOINT='http://10.0.0.19:8080'
export AIS_AUTHN_URL='http://10.0.0.19:52001'
export AIS_AUTHN_TOKEN='<jwt>'
export AIS_S3_ENDPOINT='http://10.0.0.19:8080/s3'
export AWS_ACCESS_KEY_ID='aistore'
export AWS_SECRET_ACCESS_KEY='aistore'
export AWS_SESSION_TOKEN='<jwt>'
export AWS_DEFAULT_REGION='us-east-1'
export AWS_EC2_METADATA_DISABLED='true'

Tokens are valid for 24 hours by default. Run eval "$(sudo ais-env)" again to get a fresh one.

Store and read your first objects

This is the core of the product: create a bucket, write an object, read it back, and confirm the bytes that came back are the bytes that went in.

eval "$(sudo ais-env)"
head -c 4194304 /dev/urandom > /tmp/dataset.bin
ais bucket create ais://cloudimg-demo
ais put /tmp/dataset.bin ais://cloudimg-demo/dataset.bin
ais ls ais://cloudimg-demo
ais get ais://cloudimg-demo/dataset.bin /tmp/dataset-out.bin
sha256sum /tmp/dataset.bin /tmp/dataset-out.bin

Expected output

"ais://cloudimg-demo" created
PUT "/tmp/dataset.bin" => ais://cloudimg-demo/dataset.bin

NAME         SIZE    
dataset.bin  4.00MiB     

GET dataset.bin from ais://cloudimg-demo as /tmp/dataset-out.bin (4.00MiB)
982049437e976ec56e3a31d2325080edd50fe55289de806db92ac99495f741aa  /tmp/dataset.bin
982049437e976ec56e3a31d2325080edd50fe55289de806db92ac99495f741aa  /tmp/dataset-out.bin

The two checksums match, which is the proof that the object round tripped through storage unchanged. Your checksum will differ because the source file is random.

A real object round trip over the native API: bucket created, a 4 MiB object written, listed, read back, and the two SHA 256 checksums matching exactly

Delete an object, and the bucket, when you are finished with them:

eval "$(sudo ais-env)"
ais object rm ais://cloudimg-demo/dataset.bin
ais ls ais://cloudimg-demo

Expected output

deleted "dataset.bin" from ais://cloudimg-demo

NAME         SIZE

Use the S3 compatible API

Everything you just did through the native client is also reachable through the S3 compatible API on the same gateway, at http://<vm-address>:8080/s3. Unmodified S3 clients work: AIStore accepts its token in the standard AWS session token header, so you pass the token as AWS_SESSION_TOKEN and use placeholder values for the access key and secret. ais-env has already set all of that for you.

The AWS CLI v2 is installed on the image:

eval "$(sudo ais-env)"
head -c 4194304 /dev/urandom > /tmp/s3-src.bin
aws --endpoint-url "$AIS_S3_ENDPOINT" s3 mb s3://cloudimg-s3-demo
aws --no-progress --endpoint-url "$AIS_S3_ENDPOINT" s3 cp /tmp/s3-src.bin s3://cloudimg-s3-demo/via-s3.bin
aws --endpoint-url "$AIS_S3_ENDPOINT" s3 ls s3://cloudimg-s3-demo/
aws --no-progress --endpoint-url "$AIS_S3_ENDPOINT" s3 cp s3://cloudimg-s3-demo/via-s3.bin /tmp/s3-out.bin
sha256sum /tmp/s3-src.bin /tmp/s3-out.bin

Expected output

make_bucket: cloudimg-s3-demo
upload: ../../tmp/s3-src.bin to s3://cloudimg-s3-demo/via-s3.bin
2026-08-07 06:57:07    4194304 via-s3.bin
download: s3://cloudimg-s3-demo/via-s3.bin to ../../tmp/s3-out.bin
bcf7b906cef78ddb7c4bb09efc77bf312c62a4775d787c758b59c4f96e7003e2  /tmp/s3-src.bin
bcf7b906cef78ddb7c4bb09efc77bf312c62a4775d787c758b59c4f96e7003e2  /tmp/s3-out.bin

The same buckets and objects are visible from either API, so you can write with an S3 tool and read with the native client, or the other way round. boto3, the official AWS SDK for Python, is installed as well:

eval "$(sudo ais-env)"
python3 - <<'PY'
import boto3, os
s3 = boto3.client(
    "s3",
    endpoint_url=os.environ["AIS_S3_ENDPOINT"],
    aws_access_key_id="aistore",
    aws_secret_access_key="aistore",
    aws_session_token=os.environ["AIS_AUTHN_TOKEN"],
    region_name="us-east-1",
)
print([b["Name"] for b in s3.list_buckets()["Buckets"]])
PY

Expected output

['cloudimg-s3-demo', 'cloudimg-demo']

Both buckets appear, including the one created earlier with the native client, because there is one namespace behind both APIs.

The same bucket driven by an unmodified AWS CLI and by boto3 over the S3 compatible endpoint, listing and transferring real objects

Remove the demonstration bucket when you are done:

eval "$(sudo ais-env)"
aws --endpoint-url "$AIS_S3_ENDPOINT" s3 rm s3://cloudimg-s3-demo/via-s3.bin
aws --endpoint-url "$AIS_S3_ENDPOINT" s3 rb s3://cloudimg-s3-demo
ais bucket rm ais://cloudimg-demo --yes

To point an existing application at the appliance, set its S3 endpoint to http://<vm-address>:8080/s3, its region to any value, its access key and secret to any placeholder, and its session token to a token from ais-env. No client patching is required.

Confirm the appliance is closed

Every path except the liveness probe refuses a request that carries no token, on the VM's own routable address as well as on loopback. Prove it for yourself:

AIS_IP=$(ip -4 -o addr show scope global | awk '{print $4}' | cut -d/ -f1 | head -1)
printf 'anonymous native  /v1/cluster : HTTP '; curl -s -o /dev/null -w '%{http_code}\n' "http://${AIS_IP}:8080/v1/cluster"
printf 'anonymous S3      /s3         : HTTP '; curl -s -o /dev/null -w '%{http_code}\n' "http://${AIS_IP}:8080/s3"
printf 'forged token      /v1/cluster : HTTP '; curl -s -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJmb3JnZWQifQ.forged' "http://${AIS_IP}:8080/v1/cluster"
printf 'liveness probe    /v1/health  : HTTP '; curl -s -o /dev/null -w '%{http_code}\n' "http://${AIS_IP}:8080/v1/health"

Expected output

anonymous native  /v1/cluster : HTTP 401
anonymous S3      /s3         : HTTP 403
forged token      /v1/cluster : HTTP 401
liveness probe    /v1/health  : HTTP 200

An unmodified S3 client with no token is refused in the same way:

AIS_IP=$(ip -4 -o addr show scope global | awk '{print $4}' | cut -d/ -f1 | head -1)
if env -u AWS_SESSION_TOKEN AWS_ACCESS_KEY_ID=x AWS_SECRET_ACCESS_KEY=x AWS_DEFAULT_REGION=us-east-1 \
     aws --endpoint-url "http://${AIS_IP}:8080/s3" s3 ls >/dev/null 2>&1; then
  echo "UNEXPECTED: an unauthenticated client listed buckets"
else
  echo "refused: an unauthenticated S3 client cannot list buckets"
fi

Expected output

refused: an unauthenticated S3 client cannot list buckets

The client's own error message is An error occurred (None) when calling the ListBuckets operation: token required.

The per VM secrets are readable only by root and the service account:

sudo stat -c '%a %U:%G %n' /root/aistore-credentials.txt /etc/ais/ais-secret.env /etc/ais/authn-secret.env

Expected output

600 root:root /root/aistore-credentials.txt
640 root:ais /etc/ais/ais-secret.env
640 root:ais /etc/ais/authn-secret.env

Anonymous native, anonymous S3 and forged token requests over the VM's routable address all refused, while the liveness probe answers, and the per VM secrets restricted to root

Run the bundled self check

aistore-selfcheck verifies the entire appliance end to end at any time. It authenticates with your VM's own credential, creates a bucket, writes a 4 MiB object, reads it back and compares checksums, lists it and deletes it, over both the native API and the S3 compatible API, and then confirms that anonymous and forged requests are refused on the routable address:

sudo aistore-selfcheck

Expected output

selfcheck: authenticated as admin with the per-VM credential
selfcheck: wrong password refused by AuthN
selfcheck: native: created ais://cloudimg-selfcheck-53663
selfcheck: native: PUT 4 MiB object
selfcheck: native: GET byte-compare OK (sha256 34481059ef4221a4...)
selfcheck: native: LIST shows native.bin
selfcheck: native: DELETE removed the object
selfcheck: s3: created s3://cloudimg-s3-selfcheck-53663
selfcheck: s3: PUT 4 MiB object
selfcheck: s3: LIST shows s3.bin
selfcheck: s3: GET byte-compare OK (sha256 34481059ef4221a4...)
selfcheck: s3: DELETE removed the object
selfcheck: anonymous native request to 10.0.0.19:8080 refused (HTTP 401)
selfcheck: anonymous S3 request to 10.0.0.19:8080/s3 refused (HTTP 403)
selfcheck: unauthenticated aws CLI over the routable address refused
selfcheck: forged token refused (HTTP 401)
selfcheck: liveness probe /v1/health returns 200 (no version, no config, no data)
selfcheck: object data volume /ais/disk0 is mounted
selfcheck: ALL CHECKS PASSED — native and S3 round-trips proved, anonymous access refused

The bucket names contain the process id, and the checksums and address are your VM's own, so those lines will differ from the example above.

Reach AIStore from another machine

From the same virtual network there is nothing to do beyond opening TCP 8080 in the Network Security Group. Point your client at http://<vm-private-address>:8080 for the native API or http://<vm-private-address>:8080/s3 for the S3 API, and pass a token from ais-env on the VM. This is the normal deployment shape: an object store serving datasets to compute in the same network.

From your own workstation, over the S3 API, the public address works directly once TCP 8080 is open to your address, because the S3 API is served entirely by the gateway:

aws --endpoint-url "http://<vm-ip>:8080/s3" s3 ls

with AWS_SESSION_TOKEN set to a token you obtained on the VM, and placeholder values for the access key and secret.

From your own workstation, over the NATIVE API, use an SSH SOCKS tunnel. The native API redirects object reads and writes to the storage target using the VM's own network address, so a plain port forward is not enough, and a SOCKS proxy routes the redirect correctly. Run this on your workstation:

ssh -D 1080 -N azureuser@<vm-ip>

Then, in another terminal on your workstation, with the ais client installed:

export ALL_PROXY=socks5h://127.0.0.1:1080
export AIS_ENDPOINT=http://<private-ip>:8080
export AIS_AUTHN_TOKEN=<your-token>
ais show cluster

Add more storage

The storage target uses /ais/disk0 as its only mountpath. To grow capacity, attach another Azure data disk to the VM, format and mount it, then tell AIStore about it. These steps need a second disk that is not present on a freshly deployed VM, so run them only after you have attached one:

# after attaching and mounting a new disk at /ais/disk1, owned by the ais user
eval "$(sudo ais-env)"
ais storage mountpath attach /ais/disk1
ais show storage mountpath

Mount the new filesystem with an /etc/fstab entry so it survives a reboot, and make sure it is owned by the ais user. AIStore spreads objects across all attached mountpaths.

Server components

Component	Version	Purpose
AIStore gateway (`aisnode -role=proxy`)	1.4.9	Serves the native API and the S3 compatible API, holds the cluster map
AIStore target (`aisnode -role=target`)	1.4.9	Stores objects on `/ais/disk0`
AIStore AuthN	1.4.9	Issues and validates the JSON Web Tokens the cluster requires
`ais` command line client	1.4.9	Native client, built from the same source revision as the cluster
AWS CLI	2.36.18	Unmodified S3 client for the S3 compatible API
boto3	1.34.46	Official AWS SDK for Python
Ubuntu Server	24.04 LTS	Operating system

Filesystem layout

Path	Size	Purpose
`/`	29 GB	Root filesystem
`/boot`	913 MB	Operating system kernel files
`/boot/efi`	106 MB	UEFI boot partition (Gen2 Hyper V)
`/ais/disk0`	32 GB	Dedicated AIStore object data volume
`/mnt`	varies	Azure temporary resource disk

Key directories

Path	Purpose
`/usr/local/bin/aisnode`	The AIStore node binary, run as both gateway and target
`/usr/local/bin/ais`	The native command line client
`/usr/local/bin/authn`	The AuthN token service
`/usr/local/bin/ais-env`	Prints authenticated shell exports
`/usr/local/sbin/aistore-selfcheck`	End to end appliance self check
`/etc/ais/ais.json`	Cluster configuration, including `auth.enabled`
`/etc/ais/ais_local_proxy.json`	Gateway node configuration
`/etc/ais/ais_local_target.json`	Storage target configuration, including mountpaths
`/etc/ais/authn/authn.json`	AuthN configuration
`/var/lib/ais/proxy`, `/var/lib/ais/target`	Cluster metadata and node identity
`/var/log/ais/`	AIStore logs, one directory per node
`/root/aistore-credentials.txt`	Per VM credentials, mode 0600
`/usr/share/doc/aistore/LICENSE`	The upstream MIT licence

Network ports

Port	Bound to	Purpose
22	all interfaces	SSH administration
8080	all interfaces	AIStore gateway: native API and S3 compatible API
8081	all interfaces	AIStore storage target, native API object transfers
52001	all interfaces	AuthN token service, requires the administrator password
9080, 10080	VM network address	Gateway intra cluster control and data planes
9081, 10081	VM network address	Target intra cluster control and data planes

Open only 22 and 8080 in your Network Security Group unless you use the native API from another machine, in which case also open 8081. Never open the intra cluster ports.

Managing the services

sudo systemctl status ais-proxy.service --no-pager || true
sudo systemctl restart ais-target.service
sudo journalctl -u ais-proxy.service -n 20 --no-pager

Start order matters: ais-authn.service first, then ais-proxy.service, then ais-target.service. The unit dependencies encode this, so a plain sudo systemctl restart ais-target.service is safe. Stopping ais-authn.service takes authentication offline and every subsequent request is refused, so restart it before using the cluster again.

Scripts and log files

Path	Purpose
`/usr/local/sbin/aistore-firstboot.sh`	First boot bootstrap: mints the per VM secrets and starts the cluster
`/usr/local/sbin/ais-netenv`	Resolves this VM's address at every boot and pins it into the node configuration
`/usr/local/sbin/ais-token`	Exchanges a username and password for a token
`/usr/local/bin/ais-env`	Prints authenticated shell exports
`/usr/local/sbin/aistore-selfcheck`	End to end appliance self check
`/var/log/cloudimg-firstboot.log`	First boot log
`/var/log/ais/proxy/`, `/var/log/ais/target/`, `/var/log/ais/authn/`	Per node AIStore logs

On startup

On the first boot only, aistore-firstboot.service runs aistore-firstboot.sh. It generates this VM's signing key and administrator password, creates the bootstrap marker that permits the AIStore services to start, brings up AuthN, the gateway and the target in order, registers the cluster with AuthN, writes /root/aistore-credentials.txt and then disables itself. A marker file at /var/lib/cloudimg/aistore-firstboot.done prevents it running again.

Until that marker exists the three AIStore units refuse to start at all, which is what guarantees the shipped image never listens on any address without your own credentials in place.

On every boot, ais-netenv.service resolves the VM's current network address and writes it into the node configuration before the cluster starts, so the appliance keeps working if the VM is reassigned a different address.

Troubleshooting

The services are not active after first boot. Read the first boot log, which records each step:

sudo tail -40 /var/log/cloudimg-firstboot.log
sudo systemctl status aistore-firstboot.service --no-pager || true

aistore-firstboot.service reports inactive (dead) and disabled once it has completed successfully, which is why the || true is there. That is the healthy state, not a fault.

ais-env reports it cannot read the credentials file. It must be run with sudo, because the credentials are mode 0600 and owned by root.

ais commands return "token required" or HTTP 401. Your token has expired, or this shell never had one. Run eval "$(sudo ais-env)" again.

A service will not start and the journal mentions the bootstrap marker. The units are gated on /var/lib/aistore/.bootstrap-ready, which only first boot creates. If it is missing, first boot did not complete; check the first boot log above.

The storage target will not start. It requires the data volume. Confirm it is mounted:

mountpoint /ais/disk0 && df -h /ais/disk0

An S3 client reports a signature error. AIStore does not validate AWS signatures; it authenticates on the session token. Use any placeholder access key and secret, and set AWS_SESSION_TOKEN to a token from ais-env.

Native API object transfers time out from a machine outside the virtual network. The native API redirects object reads and writes to the storage target's own network address. Use the S3 API, which does not redirect, or an SSH SOCKS tunnel as shown earlier.

Check cluster health at any time:

eval "$(sudo ais-env)"
ais show cluster
sudo journalctl -u ais-proxy.service -u ais-target.service -n 60 --no-pager

Security recommendations

Restrict TCP 8080 to the network your clients run on. Authentication is enforced, but there is no reason to expose an object store to the whole internet. Use Network Security Group rules scoped to your subnet or to specific source addresses.
Keep the credentials file where it is. /root/aistore-credentials.txt is mode 0600 and owned by root. Copy the password into your secret manager rather than moving or relaxing the file.
Create per application users rather than sharing the administrator. AuthN supports additional users and roles; see ais auth --help. The administrator account should be reserved for administration.
Put TLS in front of the gateway for anything crossing an untrusted network. The appliance speaks HTTP. Terminate TLS on an Azure Application Gateway or a reverse proxy, or enable AIStore's own HTTPS support with your certificate.
Rotate the administrator password with ais auth update user, and update your stored copy.
Leave unattended security upgrades enabled so the operating system keeps receiving patches.
Take Azure snapshots of the data disk on a schedule that matches how much data you can afford to re create. A single node cluster has no replication.

Support

cloudimg images are backed by 24/7 support. For help with this image, contact support through the Azure Marketplace listing or visit www.cloudimg.co.uk.

AIStore and NVIDIA are trademarks of NVIDIA Corporation. Amazon S3 and AWS are trademarks of Amazon.com, Inc. or its affiliates. cloudimg is not affiliated with, endorsed by, or sponsored by NVIDIA Corporation or Amazon. AIStore is distributed under the MIT licence; the licence text ships on the image at /usr/share/doc/aistore/LICENSE.