SciNote

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for SciNote by SecureAnyCloud, 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) and HTTP (80). Then select Review + create and Create.

RG="scinote-prod"; LOCATION="eastus"; VM_NAME="scinote-01" IMAGE_URN="sac1647283583153:scinote-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 scinote-vnet --address-prefix 10.100.0.0/16 --subnet-name scinote-subnet --subnet-prefix 10.100.1.0/24 az network nsg create -g "$RG" --name scinote-nsg az network nsg rule create -g "$RG" --nsg-name scinote-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 scinote-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:scinote-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 scinote-vnet --subnet scinote-subnet --nsg scinote-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, SciNote generates its own per-instance secrets and creates its database. It then creates the administrator account directly with a password unique to this VM, before the web port is opened. Nothing is baked into the image.

Give the instance a few minutes after first boot for the database to be created and migrated. Then SSH in and read the credentials file (it is 0600 root:root):

sudo cat /root/scinote-credentials.txt

The file contains everything unique to this instance:

• SCINOTE_ADMIN_EMAIL / SCINOTE_ADMIN_PASSWORD: the administrator login you use in the web UI. The administrator has full access, including team and user management.
• SCINOTE_URL: the web address of this instance, resolved from its public IP on first boot.
• POSTGRES_PASSWORD: the database role password. PostgreSQL is not published to any host port, so the password is used only inside the private container network.

Confirm the services and containers are healthy:

sudo systemctl is-active docker scinote-firstboot scinote scinote-postboot nginx

active active active active active

sudo docker compose -f /opt/scinote/docker-compose.production.yml ps --format 'table {{.Service}}\t{{.Status}}\t{{.Ports}}'

SERVICE STATUS PORTS db Up About a minute (healthy) 5432/tcp jobs Up 57 seconds web Up 57 seconds (healthy) 127.0.0.1:3000->3000/tcp

The web container publishes to loopback only and PostgreSQL has no host port at all; host nginx on port 80 is the single public door.

The upstream SciNote seed data creates a default administrator (admin@scinote.net) with a publicly documented password when no administrator details are supplied. On a VM with a public IP, that would be a real risk. SecureAnyCloud closes it. On first boot, the image supplies its own per-VM administrator name, email and password to the seed. The administrator is created directly with a password unique to this VM, and the well-known default account is never created.

The application encryption key (SECRET_KEY_BASE), which signs sessions and cookies, and the attachment signing secret are also generated per VM, so no two instances share a secret. A start-up guard refuses to launch the application at all if the encryption key or database password is empty, too short or a known default. Host nginx, the only public listener, does not start until first boot has proven the administrator can sign in.

ss -tln | grep -E ':(80|3000|5432) ' | awk '{print $1, $4}'

LISTEN 127.0.0.1:3000 LISTEN 0.0.0.0:80 LISTEN [::]:80

Exactly one account exists on a fresh instance, it is confirmed and can sign in, and the upstream default administrator is absent:

sudo docker exec scinote_db_production psql -w -U postgres -d scinote_production -tAc "SELECT email, CASE WHEN confirmed_at IS NULL THEN 'unconfirmed' ELSE 'confirmed' END FROM users" </dev/null

admin@scinote.local|confirmed

The image ships a prover that exercises the whole security model through the public front door on port 80. It confirms that:

• The sign-in page answers.
• The per-VM administrator signs in through the real login form and reads back an authenticated page.
• A wrong password is rejected.
• The upstream default admin@scinote.net credential is rejected.

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

Open http://<vm-ip>/ in your browser and sign in with the SCINOTE_ADMIN_EMAIL and SCINOTE_ADMIN_PASSWORD from the credentials file.

Once signed in, open your account settings first. There you can change the administrator email and password from the per-VM values to your own.

The projects dashboard is your home view. A project is the top level of the SciNote structure. It holds experiments, and each experiment holds tasks. Use New project to start one. The screenshot below shows a freshly created project, Antibody Validation Study 2026, next to the SciNote Examples project that ships as a ready-made walk-through of the notebook.

Open a project and you see its experiments. The SciNote Examples project ships with a full set of worked examples: polymerase chain reaction, CRISPR transformations, antibody purification, SDS-PAGE and more. You can see how a real notebook is organized before you build your own.

Open an experiment and its tasks are laid out on a canvas, connected in the order they are carried out. Each task holds its protocol steps, results, tables and file attachments, and can be assigned a status and an owner. This is where the day-to-day work of the lab is recorded.