Colanode 0.4.7

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Colanode 0.4.7 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose an instance type, your key pair, your subnet and the security group above.

m5.large (2 vCPUs, 8 GiB) suits a team of a few dozen people. The image has two volumes: a 30 GiB root volume and a 10 GiB data volume (/dev/sdf) for /var/lib/colanode. Make the data volume bigger at launch if your team shares many files.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings '[{"DeviceName":"/dev/sdf","Ebs":{"VolumeSize":50,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=colanode}]'

Connect over SSH as the default login user for your AMI. For Colanode 0.4.7 on Ubuntu 24.04, the login user is ubuntu:

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

The login message shows where your URL and password are and how to add a teammate.

First boot takes about 20 seconds: it names the instance after its public DNS name and makes the certificate, generates the database passwords, starts the containers, creates the administrator and only then starts nginx. Check that everything is running:

systemctl is-active docker colanode-firstboot colanode nginx \
  && sudo test -f /var/lib/sac/data/colanode-firstboot.done && echo FIRSTBOOT_DONE

active active active active FIRSTBOOT_DONE

Three containers run, all healthy: the Colanode server, PostgreSQL and Valkey.

sudo docker ps --format '{{.Names}} {{.Image}} {{.Status}}' | sort | tee /dev/stderr \
  | grep -c '(healthy)' | grep -qx 3 && echo "3 containers healthy"

colanode-postgres sac/pgvector:0.8.7-pg17 Up 2 minutes (healthy) colanode-server sac/colanode-server:0.4.7 Up 2 minutes (healthy) colanode-valkey valkey/valkey:8.1.11 Up 2 minutes (healthy) 3 containers healthy

Only SSH and nginx listen on the network. The Colanode server listens on 127.0.0.1:3000 behind nginx, and PostgreSQL and Valkey have no port on the host at all:

sudo ss -Hlnt | awk '{print $4}' | grep -vE '^(127\.|\[::1\]|\[::ffff:127\.)' \
  | sed -E 's/.*:([0-9]+)$/\1/' | sort -un | xargs | tee /dev/stderr | grep -qx '22 80 443' && echo "network listeners: 22 80 443"

22 80 443 network listeners: 22 80 443

Your workspace data is on the data volume:

findmnt -no FSTYPE,TARGET /var/lib/colanode | head -n 1 | tee /dev/stderr | grep -q '^ext4 ' \
  && sudo ls /var/lib/colanode | xargs

ext4 /var/lib/colanode lost+found postgres storage valkey

The data volume holds three folders:

• /var/lib/colanode/postgres holds the PostgreSQL database (accounts, workspaces, pages, messages).
• /var/lib/colanode/storage holds uploaded files.
• /var/lib/colanode/valkey holds the Valkey cache and sync channel.

/root/colanode-credentials.txt (root only) holds everything generated on first boot:

sudo grep -o '^colanode\.[a-z.]*' /root/colanode-credentials.txt | tee /dev/stderr \
  | grep -qx colanode.admin.pass && echo "credentials present"

colanode.url colanode.admin.email colanode.admin.pass colanode.db.name colanode.db.user colanode.db.pass credentials present

Show the values (keep them private):

sudo cat /root/colanode-credentials.txt

colanode.url is the address to open, for example https://ec2-203-0-113-10.compute-1.amazonaws.com/. It uses the instance's public DNS name, and the certificate is made for that name. Use this name rather than the IP address: the server only accepts changes from pages loaded from the name it is configured with (Step 9 changes it to your own domain).

In a desktop browser, open the colanode.url address. The certificate is self-signed, so the browser warns once. Choose Advanced and continue, or use your own domain and certificate (Step 9).

Colanode opens on Add a server. Choose Add a new server, enter your server's config URL, which is colanode.url followed by config, for example:

https://ec2-203-0-113-10.compute-1.amazonaws.com/config

and choose Create. Your server appears in the list as Colanode:

Choose your server, then sign in with admin@colanode.local and the colanode.admin.pass value from Step 4.

Colanode allows 10 sign-in attempts per email address in 10 minutes. After that, wait 10 minutes.

The image has no outgoing email, so Forgot password? cannot send a reset link. Keep the credentials file, and change the password in your account settings once you are in.

Your workspace opens with a Home space holding a Welcome page and a Discussions channel. Click anywhere on a page and type, or press / to add headings, to-do lists, quotes, subpages and databases. Everything syncs to the server and to every device signed in to the workspace.

Open Discussions to chat in real-time: type in the composer and press Enter.

Sign-up is closed. Confirm it:

sudo colanode-signup status | tee /dev/stderr | grep -qx 'sign-up is CLOSED' && echo SIGNUP_CLOSED

sign-up is CLOSED SIGNUP_CLOSED

nginx refuses any sign-up while it is closed (403), and no account is created:

H="$(sudo sed -n 's/^set \$app_host "\(.*\)";$/\1/p' /etc/nginx/colanode-host.conf)" curl -sk -o /dev/null -w '%{http_code}\n' --resolve "$H:443:127.0.0.1" -X POST -H "Origin: https://$H" \
  -H 'Content-Type: application/json' --data '{"name":"Test","email":"test@example.com","password":"Not-a-real-1234"}' \
  "https://$H/client/v1/auth/email/register" | tee /dev/stderr | grep -qx 403 && echo "sign-up refused"

403 sign-up refused

To add a teammate, open sign-up and let them register in the Colanode app (No account yet? Register on the login screen). Then verify their account and close sign-up again:

sudo colanode-signup open
# they register in the app; their account waits for your verification
sudo colanode-activate --list sudo colanode-activate <their-email>
sudo colanode-signup close

New accounts always wait for your verification, even while sign-up is open (account.verificationType is manual). Then invite them to your workspace from the workspace settings.

Point a DNS name at the instance (an Elastic IP keeps the address fixed), then:

sudo colanode-set-hostname <your-dns-name>

This makes a new self-signed certificate for the name, updates nginx, the cross-site check and Colanode's web domain, and restarts the stack. Your config URL becomes https://<your-dns-name>/config; add it in the app as in Step 5.

For a certificate your browsers trust, replace /etc/ssl/colanode/colanode.crt (the full chain) and /etc/ssl/colanode/colanode.key (mode 0600, root) with your own and run sudo systemctl reload nginx. The certificate is only regenerated when you change the name again.

The server's public configuration and the full credential round trip (the web app, anonymous API calls refused, sign-up closed, a wrong password refused, the administrator signs in and opens a sync socket, the database passwords work):

H="$(sudo sed -n 's/^set \$app_host "\(.*\)";$/\1/p' /etc/nginx/colanode-host.conf)" curl -sk --resolve "$H:443:127.0.0.1" "https://$H/config" | jq -c '{name,version}' | tee /dev/stderr \
  | grep -qx '{"name":"Colanode","version":"0.4.7"}' && sudo colanode-selftest | tail -n 1 | cut -c1-60

{"name":"Colanode","version":"0.4.7"} round-trip OK https://ec2-203-0-113-10.compute-1.amazonaws.

The CVE-2026-110766 fence: an encoded traversal is refused before it reaches Colanode (400), and so is an avatar upload (403):

H="$(sudo sed -n 's/^set \$app_host "\(.*\)";$/\1/p' /etc/nginx/colanode-host.conf)" T="$(curl -sk -o /dev/null -w '%{http_code}' --path-as-is --resolve "$H:443:127.0.0.1" "https://$H/client/v1/avatars/..%2f..%2fconfig")" U="$(curl -sk -o /dev/null -w '%{http_code}' --resolve "$H:443:127.0.0.1" -X POST -H "Origin: https://$H" --data-binary x "https://$H/client/v1/avatars")" echo "traversal=$T upload=$U" | tee /dev/stderr | grep -qx 'traversal=400 upload=403' && echo "avatar fences hold"

traversal=400 upload=403 avatar fences hold

The containers cannot reach the instance metadata service (and so cannot read the instance role's credentials). The first request is the control: the instance itself reaches the same address (HTTP 200), so a refusal from inside the container is the block at work, not a dead network path:

HOST="$(curl -s -m 5 -o /dev/null -w '%{http_code}' -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token)" CONT="$(sudo docker exec colanode-server node -e "fetch('http://169.254.169.254/latest/api/token',{method:'PUT',headers:{'X-aws-ec2-metadata-token-ttl-seconds':'60'},signal:AbortSignal.timeout(4000)}).then(r=>console.log('REACHED '+r.status)).catch(()=>console.log('BLOCKED'))")" echo "host=$HOST container=$CONT" | tee /dev/stderr | grep -qx 'host=200 container=BLOCKED' && echo "metadata service blocked for the containers"

host=200 container=BLOCKED metadata service blocked for the containers

What else the image does:

• PostgreSQL and Valkey sit on an internal Docker network with no route out, and the server runs as an unprivileged user on a read-only filesystem with every Linux capability dropped.
• nginx pins the host name and the client address it passes to Colanode (it never forwards X-Forwarded-For or Forwarded values a client sends) and refuses cross-site state changes and WebSocket upgrades.
• SSH accepts keys only, with no root login. No core dumps are written by the services that hold secrets.
• The firmware metadata refresh (fwupd-refresh) is masked, as there is no firmware it could update on EC2.

sudo systemctl restart colanode
# restart the three containers
sudo docker logs --tail 50 colanode-server
sudo tail -n 20 /var/log/nginx/colanode-upstream.log
# requests that reached Colanode

The stack is defined in /opt/colanode/docker-compose.yml. Colanode's configuration, including the logging level and the workspace file size limit, is in /etc/colanode/config.json.

Everything your team creates is on the data volume. For a consistent backup, stop the stack, snapshot the volume, and start it again:

sudo systemctl stop colanode aws ec2 create-snapshot --volume-id <data-volume-id> --description "colanode backup"
sudo systemctl start colanode

Keep /root/colanode-credentials.txt and /etc/colanode/ with your backups: the database password in /etc/colanode/pg_password is needed to open a restored database.

Operating system updates install automatically (unattended security upgrades). The Colanode, PostgreSQL and Valkey images are fixed at build time; new Colanode releases arrive as new versions of this listing.

• Allow port 22 from your admin network only, and ports 80 and 443 only from the networks your team works from.
• Use your own DNS name and a trusted certificate (Step 9).
• Change the administrator password after your first sign-in, and keep sign-up closed except while you add people.
• Snapshot the data volume regularly.