Enclosed

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Enclosed by SecureAnyCloud, and select Create.

On the Basics tab, 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) and HTTP (80).

Select Review + create, then Create.

RG="enclosed-prod"; LOCATION="eastus"; VM_NAME="enclosed-01" IMAGE_URN="sac1647283583153:enclosed-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name enclosed-vnet --address-prefix 10.100.0.0/16 --subnet-name enclosed-subnet --subnet-prefix 10.100.1.0/24 az network nsg create -g "$RG" --name enclosed-nsg az network nsg rule create -g "$RG" --nsg-name enclosed-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name enclosed-nsg --name allow-http --priority 110 \
  --destination-port-ranges 80 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:enclosed-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name enclosed-vnet --subnet enclosed-subnet --nsg enclosed-nsg --public-ip-sku Standard

Replace <sub-id> and <version> with your subscription ID and the image version shown on the listing. Replace <your-mgmt-cidr> with the network you administer from.

On the first boot of each VM, before the app is reachable, Enclosed generates its own per-instance login and JWT signing secret. Nothing is baked into the image. Wait a minute after first boot, then SSH in and read the credentials file, which is 0600 root:root:

ssh azureuser@<vm-ip>
sudo cat /root/enclosed-credentials.txt

The file contains the account you use to create notes, with a per-instance random password:

• ENCLOSED_ADMIN_EMAIL (<ADMIN_EMAIL>) and ENCLOSED_ADMIN_PASSWORD (<ADMIN_PASSWORD>) are the login you use in the web UI to create notes.
• ENCLOSED_URL (<ENCLOSED_URL>) is the resolved address of this instance.

Confirm that the services and the container are healthy:

sudo systemctl is-active docker nginx enclosed-firstboot enclosed

active active active active

sudo docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

NAMES STATUS PORTS enclosed Up 7 minutes 127.0.0.1:8787->8787/tcp

Enclosed needs a secure origin for its in-browser encryption. Until you install a TLS certificate (Step 6), reach the app over an SSH tunnel from your workstation, because browsers treat http://localhost as a secure origin:

ssh -L 8080:127.0.0.1:80 azureuser@<vm-ip>

Leave the tunnel running and open http://localhost:8080/ in your browser. The login screen appears, because creating notes requires authentication by default. Sign in with ENCLOSED_ADMIN_EMAIL and ENCLOSED_ADMIN_PASSWORD from Step 3.

Type your secret into the note. On the right, choose an expiry, optionally set a one-time note password, and optionally switch on Delete after reading so the note self-destructs the first time it is opened. Then select Create note.

Enclosed confirms that the note was created and gives you a single share link and a QR code. The decryption key is the part of the link after #. It is generated in your browser and is never sent to the server. Copy the link and send it to your recipient over any channel.

When the recipient opens the link, Enclosed reads the key from the link fragment and decrypts the note in their browser. If you chose delete after reading, the note is destroyed on the server the moment it is read.

This image is built so that the server never sees your data and no usable secret ships in the image.

• Zero-knowledge by design. Encryption and decryption happen only in the browser. The server stores opaque ciphertext, and the decryption key lives in the link fragment, which is never transmitted.
• The app is bound to loopback. The Enclosed container publishes its port to 127.0.0.1:8787 only. nginx on port 80 is the single public front door, and the app is not reachable directly on the VM's address.
• Authentication is required to create notes. A passer-by cannot use your instance as an open relay, because only the per-instance login can create notes. Recipients still need no account to read a public note.
• No known secret ships. The JWT signing secret and the admin password are generated for each VM on first boot, before the app starts, replacing upstream's default. The app refuses to start if the secret is missing or still the default.

Run this check to see that the app is on loopback only, the public web is on port 80, an unauthenticated create is rejected, and the secret is per VM:

# app on loopback only, public web on :80, unauthenticated create rejected, per-VM secret ss -tlnH | grep -E ':(80|8787) ' | awk '{print $4}' | sort -u curl -s -o /dev/null -w 'public web GET / : %{http_code}\n' http://127.0.0.1/ curl -s -o /dev/null -w 'unauth create : %{http_code} (401 = rejected)\n' -X POST http://127.0.0.1/api/notes -H 'Content-Type: application/json' -d '{"payload":"x","deleteAfterReading":false,"ttlInSeconds":3600,"encryptionAlgorithm":"aes-256-gcm","serializationFormat":"cbor-array","isPublic":true}'

A built-in round-trip script exercises the whole model end to end on the instance. It confirms that:

• an unauthenticated create is rejected
• the per-VM admin can log in and create a note, and the same ciphertext reads back
• a delete-after-reading note is gone on the second read
• a nonexistent note is refused

Run it with:

sudo /usr/local/sbin/enclosed-roundtrip.sh

OK round-trip: url=http://<vm-ip> admin=admin@enclosed.local created+readback note <id> (payload matched); burn note <id> refused on 2nd read (404); unauth create 401; ghost 404

Enclosed depends on the browser's Web Crypto API, which browsers disable on insecure origins. Without HTTPS, your users cannot create or read notes except over a localhost tunnel. Point a DNS record at the VM and open port 443 in your network security group. Then issue a certificate with Let's Encrypt:

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

Certbot obtains the certificate, rewrites the nginx site to listen on 443 with HTTP redirected to HTTPS, and installs a renewal timer. Your users can now open https://enclosed.example.com/ directly, and the in-browser encryption works. Replace enclosed.example.com and the email address with your own.