Developer Tools AWS

Livebook 0.19.10 on AWS User Guide

| Product: Livebook 0.19.10 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and using the Livebook 0.19.10 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg developer and API tools listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Livebook is an open source interactive notebook for Elixir. A notebook mixes Markdown with code cells that really run on the Erlang VM, plus inputs, tables and charts, and is saved as a plain text .livemd file you can keep in git. Teams use it to explore data, prototype, document and automate operational tasks, and teach Elixir.

Livebook runs code. Anyone who signs in can run any program on the instance as the livebook service user, so treat the passwords like SSH access and give them only to people you trust with the instance. The cloudimg image keeps everyone else out and keeps notebook code away from the rest of the instance:

  • HTTPS from the first boot. nginx serves Livebook on port 443 with a certificate generated on your instance's first boot. Port 80 redirects to HTTPS.
  • Two passwords unique to your instance. Your browser first asks for an HTTP login (user admin) on every page, then Livebook asks for its own password. Both are generated on first boot and written to /var/lib/cloudimg/livebook-credentials.txt (root only). nginx stores only a bcrypt hash of the HTTP password. No password is baked into the image.
  • Notebook code is sandboxed. Livebook and every notebook runtime run as the unprivileged livebook user with no capabilities, a read only view of the system except the data volume, private /tmp and devices, and a memory ceiling. That user cannot read the passwords, the TLS key or the HTTP login file.
  • No route to the instance metadata service. Livebook, every notebook runtime and nginx are blocked from the EC2 metadata service (IPv4 and IPv6) at the kernel level, so a notebook cannot pick up the instance's role credentials.
  • The Erlang distribution stays on the instance. Livebook talks to each notebook runtime over Erlang distribution on 127.0.0.1 only, with a cookie generated on first boot; no epmd port is open. Only SSH and nginx listen on the network.
  • Cross site protection. Another web site cannot use your signed in browser to open a notebook, start a session, import a notebook from a URL or open a LiveView connection: nginx and Livebook itself refuse cross origin WebSocket handshakes and state changing requests.
  • Nothing leaves the instance unless you turn it on. The check for new Livebook releases is off and Livebook Teams is not configured (Step 12). Installing Hex packages from a notebook is the one network feature that works out of the box.
  • Current, patched components. Livebook 0.19.10 (the release with five security fixes the earlier 0.19.8 lacks) on Erlang/OTP 28.5.0.8 and Elixir 1.20.4, with nine of its libraries (the web server, the HTTP client and cryptography libraries among them) updated to releases that close advisories published after 0.19.10.
  • Your notebooks on their own disk. Notebooks and Livebook's data live on a separate 20 GiB EBS volume at /var/lib/livebook.
  • Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on. The AMI requires IMDSv2.

What is on the image: Livebook 0.19.10 (/opt/livebook/livebook), Erlang/OTP 28.5.0.8 (/usr/local), Elixir 1.20.4 (/opt/elixir), nginx, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

  • An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (notebooks install packages from hex.pm).
  • A security group that allows TCP 22 (SSH), TCP 443 (Livebook) and TCP 80 (redirects to HTTPS) from your own networks only.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Livebook 0.19.10 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large (2 vCPU, 8 GiB; choose more memory for data heavy notebooks), your key pair and a security group as above. The AMI brings its 20 GiB data volume; you can make it larger on the launch page.

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 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=livebook}]'

Step 2: Connect to your instance

Version SSH user
Livebook 0.19.10 on Ubuntu 24.04 ubuntu
ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

First boot generates the certificate, the passwords and Livebook's secrets, then Livebook and nginx start:

systemctl is-active livebook nginx livebook-firstboot
sudo test -f /var/lib/cloudimg/livebook-firstboot.done && echo FIRSTBOOT_DONE
active
active
active
FIRSTBOOT_DONE

Only SSH and nginx listen on the network. Livebook (8080), its output iframe server (8081) and the Erlang distribution listen on 127.0.0.1 only; each open notebook session adds one more 127.0.0.1:<distribution-port> line for its runtime:

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | grep -v '127.0.0.5' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g; s/127\.0\.0\.1:[0-9]{5}/127.0.0.1:<distribution-port>/' | sort
0.0.0.0:22 users:(("sshd"),("systemd"))
0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"))
0.0.0.0:80 users:(("nginx"),("nginx"),("nginx"))
127.0.0.1:8080 users:(("beam.smp"))
127.0.0.1:8081 users:(("beam.smp"))
127.0.0.1:<distribution-port> users:(("beam.smp"))
[::]:22 users:(("sshd"),("systemd"))
[::]:443 users:(("nginx"),("nginx"),("nginx"))
[::]:80 users:(("nginx"),("nginx"),("nginx"))

Step 4: Get your URL and passwords

sudo cat /var/lib/cloudimg/livebook-credentials.txt

The file is readable by root only and holds the URL, the HTTP login and Livebook's password:

# Livebook 0.19.10 - generated on first boot by livebook-firstboot.service
# These credentials are unique to this instance; none was baked into the image. Keep this file secret.
# Livebook RUNS CODE: anyone who signs in can run any program as the 'livebook' user on this instance.

LIVEBOOK_URL=https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/
HTTP_USERNAME=admin
HTTP_PASSWORD=<HTTP_PASSWORD>
LIVEBOOK_PASSWORD=<LIVEBOOK_PASSWORD>
#
# Two walls: your browser first asks for HTTP_USERNAME / HTTP_PASSWORD (nginx, every page), then Livebook asks
# for LIVEBOOK_PASSWORD. The certificate is self-signed and minted on this instance's first boot; port 80
# redirects to https.
# Self-test:  sudo livebook-selftest      Change the name it is served as:  sudo livebook-set-hostname <your-dns-name>
# User guide: https://www.cloudimg.co.uk/guides/livebook-0-19-10-on-ubuntu-24-04-aws/

The URL uses the instance's public DNS name from EC2 instance metadata. The certificate also names the public and private IP addresses, so https://<public-ip>/ works too. To serve Livebook under your own DNS name, see Step 10.

The self test signs in with both passwords over HTTPS and checks the protections described in this guide:

sudo livebook-selftest
SELFTEST-OK https 301 + /public/health + 401 no/wrong HTTP credential + 302 to /authenticate + wrong Livebook password refused + Livebook sign-in + home page + 403 cross-site /new + 403 cross-origin POST + 403 cross-origin WebSocket + 444 unknown host

Step 5: Sign in

Open the LIVEBOOK_URL in your browser. The certificate is self signed, so your browser asks you to confirm it the first time (or install your own certificate, Step 10). Your browser then asks for a user name and password: enter admin and the HTTP_PASSWORD. Livebook then shows its own sign in page; enter the LIVEBOOK_PASSWORD:

The Livebook sign in page asking for the instance's Livebook password

The home page lets you create a new notebook, reopen recent ones and work through Livebook's built in learning notebooks:

The Livebook 0.19.10 home page on cloudimg with the New notebook button and the Learn notebooks

Open shows the notebooks folder on the data volume, /var/lib/livebook/notebooks, with the welcome notebook that first boot put there:

The Open notebook page listing welcome.livemd in /var/lib/livebook/notebooks

Step 6: Run the welcome notebook

Open welcome.livemd and choose Evaluate on the first code cell (or press Ctrl/Cmd + Enter). Livebook starts a fresh Elixir runtime for the notebook and runs the cell:

The welcome notebook with its first Elixir cell evaluated, showing the squares of 1 to 10

Each notebook session gets its own Elixir node (a separate operating system process) running as the livebook user. Save a notebook with Ctrl/Cmd + S; new notebooks are saved under /var/lib/livebook/notebooks unless you pick another folder on the data volume.

Step 7: Install packages from a notebook

Add packages to a notebook's Notebook dependencies and setup cell, for example the Kino widgets and the Req HTTP client:

Mix.install([
  {:kino, "~> 0.18"},
  {:req, "~> 0.5"}
])

Livebook downloads them from hex.pm into the livebook user's cache on the data volume (/var/lib/livebook/home), so the instance needs outbound HTTPS. The image ships no C compiler, so packages that compile native code at install time fail; packages that ship precompiled binaries (Explorer, EXLA, Kino) work. To compile native packages, install the toolchain yourself:

sudo apt-get update && sudo apt-get install -y build-essential

Charts, tables and other Kino outputs render in a sandboxed frame that your browser loads from livebookusercontent.com, Livebook's standard setup for HTTPS servers. Only that empty frame page comes from there; your notebook's data stays between your browser and the instance. Step 12 shows how to host the frame yourself.

Step 8: Where your notebooks and data live

df -h /var/lib/livebook | tail -1
sudo ls -l /var/lib/livebook /var/lib/livebook/notebooks
/dev/nvme1n1     20G   72K   19G   1% /var/lib/livebook
/var/lib/livebook:
total 28
drwxr-x--- 3 livebook livebook  4096 Oct 27 19:41 data
drwxr-x--- 2 livebook livebook  4096 Oct 27 19:38 home
drwx------ 2 root     root     16384 Oct 27 19:14 lost+found
drwxr-x--- 2 livebook livebook  4096 Oct 27 19:38 notebooks

/var/lib/livebook/notebooks:
total 4
-rw-r----- 1 livebook livebook 946 Oct 27 19:38 welcome.livemd
Folder Holds
/var/lib/livebook/notebooks your notebooks (Livebook's home folder)
/var/lib/livebook/data Livebook's own settings, secrets you store in Livebook and its file system list
/var/lib/livebook/home the livebook user's home: Hex and Mix package caches

The volume is a separate EBS volume, so you can grow it (modify the volume in the EC2 console, then sudo resize2fs on its device) or snapshot it on its own. To copy your notebooks off the instance:

sudo tar -czf <backup-dir>/livebook-notebooks.tar.gz -C /var/lib/livebook notebooks

Step 9: What notebook code can and cannot reach

Notebook code runs as livebook in the same locked down service as Livebook itself. From the command line you can confirm what that user can do: it cannot read the passwords, the TLS key or the HTTP login file, and its service is blocked from the instance metadata service while it can still reach the internet:

for f in /var/lib/cloudimg/livebook-credentials.txt /etc/livebook/secrets.env /etc/ssl/livebook/livebook.key /etc/nginx/.livebook-htpasswd; do
  sudo -u livebook test -r "$f" && echo "readable: $f" || echo "not readable by livebook: $f"
done
systemctl show livebook -p User -p NoNewPrivileges -p ProtectSystem -p ReadWritePaths -p CapabilityBoundingSet -p MemoryMax
for u in livebook nginx; do echo "$u IPAddressDeny: $(systemctl show $u -p IPAddressDeny --value | tr ' ' '\n' | sort | xargs)"; done

MemoryMax is 80% of the instance's memory (here an 8 GiB instance), shared by Livebook and every notebook runtime.

not readable by livebook: /var/lib/cloudimg/livebook-credentials.txt
not readable by livebook: /etc/livebook/secrets.env
not readable by livebook: /etc/ssl/livebook/livebook.key
not readable by livebook: /etc/nginx/.livebook-htpasswd
MemoryMax=6556725248
CapabilityBoundingSet=
User=livebook
ReadWritePaths=/var/lib/livebook
ProtectSystem=strict
NoNewPrivileges=yes
livebook IPAddressDeny: 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128
nginx IPAddressDeny: 168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128

To see the block from inside a notebook, run this in a code cell. The request to the metadata service times out while hex.pm answers:

:inets.start()
probe = fn url -> :httpc.request(:get, {String.to_charlist(url), []}, [timeout: 3000, connect_timeout: 3000, autoredirect: false], []) end
%{metadata_service: elem(probe.("http://169.254.169.254/latest/meta-data/"), 0),
  hex_pm: elem(probe.("http://hex.pm/"), 0)}
%{hex_pm: :ok, metadata_service: :error}

Step 10: Your own DNS name and certificate

Point a DNS record at the instance, then set the name Livebook is served as. This mints a new self signed certificate for the name, updates nginx, the cross site protection, the WebSocket origin Livebook accepts and the URL in the credentials file, restarts Livebook and keeps the name across reboots:

sudo livebook-set-hostname <your-domain>

To use a certificate from your own certificate authority instead, copy it over the generated pair and reload nginx (running livebook-set-hostname again replaces it with a self signed one):

sudo install -m 0644 <your-domain>.crt /etc/ssl/livebook/livebook.crt
sudo install -m 0600 <your-domain>.key /etc/ssl/livebook/livebook.key
sudo nginx -t && sudo systemctl reload nginx

Step 11: Change the passwords

The HTTP login is an nginx Basic Auth file. To set a new password for admin, hand it to htpasswd on standard input (printf is a shell builtin, so the password never appears in the process list; start the line with a space so most shells keep it out of your history), then reload nginx:

 printf '%s\n' '<new-password>' | sudo htpasswd -i -B -C 12 /etc/nginx/.livebook-htpasswd admin
sudo systemctl reload nginx

Add a colleague's own HTTP login with sudo htpasswd -B -C 12 /etc/nginx/.livebook-htpasswd <user> (it prompts for the password) and remove one with sudo htpasswd -D /etc/nginx/.livebook-htpasswd <user>.

Livebook's own password is LIVEBOOK_PASSWORD in /etc/livebook/secrets.env (root only, at least 12 characters). Edit it with sudo nano /etc/livebook/secrets.env, then sudo systemctl restart livebook. Update both values in /var/lib/cloudimg/livebook-credentials.txt too, so it does not hold old passwords.

Step 12: Optional features (off by default)

Put your own Livebook settings in /etc/livebook/livebook.local.env (it is read after the shipped /etc/livebook/livebook.env, so its values win), then sudo systemctl restart livebook. The environment variables page lists every setting.

  • Release check. Livebook can tell you when a new release is out by asking GitHub once a day. It is off on this image; switch on Show banner when a new Livebook version is available under Settings:

Livebook Settings showing version 0.19.10 with Elixir 1.20.4, the update banner switched off and the dev endpoints switched off

  • Dev endpoints (control Livebook through HTTP endpoints under /dev) are off; leave them off on a server.
  • Livebook Teams (shared secrets, app deployment and sign in for your organization) connects the instance to Livebook's hosted service. It is not configured; adding an organization under Settings turns it on.
  • Self hosted output frame. Set LIVEBOOK_IFRAME_URL to an HTTPS address that serves Livebook's iframe page on a different origin from Livebook to stop your browser loading it from livebookusercontent.com.
  • Instance role for S3 file systems. Livebook cannot read the instance's IAM role (the metadata service is blocked). To browse an S3 bucket, add it under Settings with an access key for a user scoped to that bucket.

The metadata service stays blocked whatever you switch on.

Step 13: Check the security posture from the command line

Without the HTTP login every page is refused, including Livebook's sign in form and its WebSocket; port 80 redirects to HTTPS; Livebook's health check stays open for load balancers; and a request for a host name the instance does not serve is dropped without an answer:

H=$(sudo grep '^LIVEBOOK_URL=' /var/lib/cloudimg/livebook-credentials.txt | sed -E 's#^LIVEBOOK_URL=https://([^/]+)/.*#\1#')
R="--resolve $H:443:127.0.0.1 --resolve $H:80:127.0.0.1"
curl -s -o /dev/null -w 'http://  -> %{http_code} %{redirect_url}\n' $R "http://$H/"
curl -sk -o /dev/null -w 'home, no login -> HTTP %{http_code}\n' $R "https://$H/"
curl -sk -o /dev/null -w 'sign in form, no login -> HTTP %{http_code}\n' $R "https://$H/authenticate"
curl -sk --http1.1 -o /dev/null -w 'LiveView WebSocket, no login -> HTTP %{http_code}\n' $R -H 'Connection: Upgrade' -H 'Upgrade: websocket' -H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' "https://$H/live/websocket?vsn=2.0.0"
curl -sk -w '\n' $R "https://$H/public/health"
curl -sk -o /dev/null -w 'unknown host -> %{http_code}\n' --resolve "evil.example:443:127.0.0.1" "https://evil.example/" || true
http://  -> 301 https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/
home, no login -> HTTP 401
sign in form, no login -> HTTP 401
LiveView WebSocket, no login -> HTTP 401
{"application":"livebook"}
unknown host -> 000

000 means nginx closed the connection without answering, which is how it treats any host name it does not serve.

With the HTTP login, Livebook still wants its own password, and requests that arrive from another web site are refused: a link on another page that would start a new notebook session, or a WebSocket handshake whose browser Origin is another site, gets HTTP 403:

sudo bash -c '
  F=/var/lib/cloudimg/livebook-credentials.txt
  P=$(grep "^HTTP_PASSWORD=" $F | cut -d= -f2-)
  H=$(grep "^LIVEBOOK_URL=" $F | sed -E "s#^LIVEBOOK_URL=https://([^/]+)/.*#\1#")
  api() { printf "user = \"admin:%s\"\n" "$P" | curl -K - -sk --resolve "$H:443:127.0.0.1" -o /dev/null "$@"; }
  ws() { api --http1.1 -m 3 -w "$1 -> HTTP %{http_code}\n" -H "Origin: $2" -H "Connection: Upgrade" -H "Upgrade: websocket" \
    -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" "https://$H/live/websocket?vsn=2.0.0"; }
  api -w "home with the HTTP login -> HTTP %{http_code}\n" "https://$H/"
  api -D - "https://$H/" | grep -i "^location" | tr -d "\r"
  api -w "new session from another site -> HTTP %{http_code}\n" -H "Sec-Fetch-Site: cross-site" "https://$H/new"
  api -w "sign in POST from another site -> HTTP %{http_code}\n" -X POST -H "Origin: https://evil.example" "https://$H/authenticate"
  ws "LiveView WebSocket, other origin" "https://evil.example"
  ws "LiveView WebSocket, same origin" "https://$H" || true
'
home with the HTTP login -> HTTP 302
location: /authenticate
new session from another site -> HTTP 403
sign in POST from another site -> HTTP 403
LiveView WebSocket, other origin -> HTTP 403
LiveView WebSocket, same origin -> HTTP 101

The Erlang distribution and Livebook's own ports answer on 127.0.0.1 only, and the service has no epmd:

PRIV=$(hostname -I | awk '{print $1}')
for p in 8080 8081 4369; do timeout 3 bash -c "exec 3<>/dev/tcp/$PRIV/$p" 2>/dev/null && echo "$p open on $PRIV" || echo "$p closed on $PRIV"; done
sudo cat /proc/$(systemctl show -p MainPID --value livebook)/environ | tr '\0' '\n' | grep -E '^(LIVEBOOK_IP|LIVEBOOK_NODE|ERL_AFLAGS)='
8080 closed on <private-ip>
8081 closed on <private-ip>
4369 closed on <private-ip>
LIVEBOOK_IP=127.0.0.1
ERL_AFLAGS=-kernel inet_dist_use_interface {127,0,0,1}
LIVEBOOK_NODE=livebook@127.0.0.1

The certificate was generated on this instance and names its own addresses:

H=$(sudo grep '^LIVEBOOK_URL=' /var/lib/cloudimg/livebook-credentials.txt | sed -E 's#^LIVEBOOK_URL=https://([^/]+)/.*#\1#')
echo | openssl s_client -connect 127.0.0.1:443 -servername "$H" 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
subject=CN = ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, O = cloudimg
X509v3 Subject Alternative Name: 
    DNS:ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, IP Address:127.0.0.1, DNS:localhost

Step 14: Server components

Component Path
Livebook (escript) /opt/livebook/livebook
Erlang/OTP 28.5.0.8 /usr/local/lib/erlang (erl on the PATH)
Elixir 1.20.4 /opt/elixir (elixir, iex, mix on the PATH)
Configuration /etc/livebook/livebook.env (shipped), /etc/livebook/livebook.local.env (yours)
Per instance secrets /etc/livebook/secrets.env (root only: Livebook password, distribution cookie, session signing key)
Notebooks and data /var/lib/livebook (data volume)
Livebook service livebook.service (user livebook; 127.0.0.1:8080, iframe server 127.0.0.1:8081)
Build record, licence, patch, dependency lock, advisory report /usr/share/doc/cloudimg-livebook/
nginx site /etc/nginx/sites-available/cloudimg-livebook
HTTP login file /etc/nginx/.livebook-htpasswd (bcrypt)
Certificate and key /etc/ssl/livebook/
First boot script /usr/local/sbin/livebook-firstboot.sh
Host name helper /usr/local/sbin/livebook-set-hostname
Self test /usr/local/sbin/livebook-selftest
Credentials /var/lib/cloudimg/livebook-credentials.txt (mode 0600)
cat /usr/local/lib/erlang/releases/28/OTP_VERSION
elixir --version | tail -1
command -v gcc || echo "no C compiler"
nginx -v 2>&1
sed -n '/^changes/,/^erlang/p' /usr/share/doc/cloudimg-livebook/BUILD-INFO.txt
28.5.0.8
Elixir 1.20.4 (compiled with Erlang/OTP 28)
no C compiler
nginx version: nginx/1.24.0 (Ubuntu)
changes           (cloudimg-livebook.patch)
                  * dependency bumps inside the release lines Livebook 0.19.10 accepts (advisories published after
                    the 0.19.10 lock): bandit:1.11.1:1.14.0, decimal:3.1.0:3.1.2, hpax:1.0.3:1.1.0, jose:1.11.10:1.11.13, mint:1.7.1:1.10.2, phoenix:1.8.7:1.8.15, plug:1.19.2:1.19.5, plug_crypto:2.1.0:2.2.1, thousand_island:1.4.3:1.6.0
                    (name:upstream:shipped); every other dependency is upstream's lock (mix.lock vs
                    mix.lock.upstream-0.19.10)
                  * WebSocket check_origin pinned to the instance's own https origin(s) (upstream: false)
erlang/otp        28.5.0.8: Hex's official Ubuntu 24.04 build https://builds.hex.pm/builds/otp/ubuntu-24.04/OTP-28.5.0.8.tar.gz

BUILD-INFO.txt records the checksums of every source (Erlang/OTP is Hex's official Ubuntu 24.04 build), the dependency updates, the one code change cloudimg makes (cloudimg-livebook.patch: Livebook's WebSocket origin check, which upstream leaves open, is pinned to the instance's own address) and the advisory review; osv-report.json lists the advisory query of the shipped dependency lock.

Step 15: Security notes and recommendations

  • Allow ports 22, 80 and 443 in the security group from your own networks only.
  • Anyone with both passwords can run code on the instance as livebook, read and change every notebook and use any secret stored in Livebook. Share them only with people you would give SSH access, and rotate them (Step 11) if they may have leaked.
  • Livebook passes its distribution cookie to each notebook runtime on that process's command line, as upstream Livebook does. Only accounts on the instance can see it, and the distribution only listens on 127.0.0.1.
  • Three dependencies keep advisories that have no fix inside the versions Livebook 0.19.10 can use. Req 0.5.8 can be made to use too much memory, or to send a malformed multipart request, by a server you fetch from; Livebook only fetches addresses a signed in user chooses (importing a notebook from a URL, S3 file systems), and another site cannot make your browser start an import. Protobuf 0.13.0 only decodes messages from Livebook Teams, which is not configured. Phoenix LiveView 1.1.24 has a low severity open redirect that needs a crafted link followed by a signed in user. cloudimg rechecks these at each Livebook release.
  • Use your own DNS name and a certificate your clients trust (Step 10).
  • Keep the operating system patched; unattended security upgrades are on, and sudo apt-get update && sudo apt-get upgrade applies everything else. Erlang/OTP, Elixir and Livebook are updated by new versions of this AMI.

Support and licensing

Livebook is open source under the Apache License 2.0 (Dashbit); the licence text is in /usr/share/doc/cloudimg-livebook/. Erlang/OTP is Apache 2.0 and Elixir is Apache 2.0. Livebook's web interface includes open source packages under the MIT, Apache 2.0 and BSD licences. There is no per user or per CPU licence fee. The AMI price covers cloudimg's build, hardening, first boot setup and support.

  • Email: support@cloudimg.co.uk
  • Website: https://www.cloudimg.co.uk
  • Support: 24/7, with a 24 hour response SLA