Tiny helper script to start Livebook connected to production (fly.io) or development

Hey friends, wanted to share a tiny shell script I’ve been using to start Livebook with easy access to either a running production server or a development server. This is based on the fly.io guide and offers nothing really new or novel beyond some small conveniences:

  • Starts Livebook with a default data directory set.
  • Sets the default runtime to be Attached, configured for your development or production server, so that you can immediately get going in that environment without having to set anything up.

Pre-reqs for development server:

  • For Livebook to connect, you need to start it with an sname and cookie:
$ iex --sname my-server --cookie my-server-cookie -S mix phx.server

Pre-reqs for production fly.io server:


# connect-live.sh


case "$1" in
    ip=$(fly ips private --app $fly_app | cut -f 3 | sed -n 2p)

    ERL_AFLAGS="-proto_dist inet6_tcp" \
      livebook server \
        --name livebook@ \
        --default-runtime attached:$node:$fly_cookie \
        --data-path $data_path \
        --home $home

    livebook server \
      --default-runtime attached:$node:$dev_cookie \
      --data-path $data_path \
      --home $home

Make sure to chmod +x connect-live.sh, then getting things going is as easy as:

$ ./connect-live.sh # start with development defaults
$ ./connect-live.sh prod # start with production defaults

As a final note: I do next to no shell scripting and the above may be total crap, but it took me a bit longer than I’d like to get this kind of thing set up in the first place and now it’s very convenient & easy, so I thought I’d share!


Script updated for Livebook 0.8.1 using environment variables instead of flags:


# Usage:
# Development:  ./connect-live.sh
# Production:   ./connect-live.sh prod


export LIVEBOOK_HOME="notebooks"
export LIVEBOOK_DATA_PATH="notebooks"

case "$1" in
    echo "[PROD] Starting Livebook..."
    fly_ip=$(fly ips private --app $fly_app | cut -f 3 | sed -n 2p)
    export LIVEBOOK_DEFAULT_RUNTIME="attached:$fly_node:$fly_cookie"
    export LIVEBOOK_NODE="livebook@"
    export ERL_AFLAGS="-proto_dist inet6_tcp"
    echo "[DEV] Starting Livebook..."
    export LIVEBOOK_DEFAULT_RUNTIME="attached:$dev_node:$dev_cookie"

livebook server
1 Like

That’s a nice alternative to doing all that manual setup to connect to a remote fly app. I recently was thinking of something similar.

If you keep your secrets in a password manager like 1password, you could use their cli to inject the cookie too. You’d be prompted for a password, and nothing else. I like to keep all secrets related to one deployment in a secured note (there are probably better ways to do it though).

Just out of curiosity: what kind of things do you do when connected to a remote host?

Nice tip on the password manager! I personally use direnv, so project secrets are kept in an .envrc that’s gitignored.

Some context first: my primary project is a site for our business of which I’m the sole developer, so I’m able to play some things a little more fast-and-loose than I might otherwise. :slight_smile:

Two primary use-cases for me:

  1. Debugging. When something’s reported, it’s really convenient to just be able to poke around and see what’s up, what state things are in, etc. instead of having to rely on what Zach of yesterday thought to log.

  2. Performing one-off or infrequent tasks that I haven’t gotten around to making a UI for. Basically using Livebook as a bespoke admin interface. There are some things that are really easy in code, e.g. nested data structures, that are kind of a pain in the ass otherwise, e.g. nested forms. This lets me play around with new features that have a business-logic implementation but don’t yet have a nailed down UI.

Overall I’ve found it extremely productive and pretty indispensable as a solo dev! As mentioned, if I were working on a larger team and hadn’t written literally all of it myself, I’d exercise more caution on making sure that I don’t break something.

That said, I do have a scratch notebook that I use for all this that has this nice warning at the top:


Those are the usages I had in mind too! It’s much nicer than a plain IEx session. And the notebook allows to set up some scenario’s that you can easily repeat.

That screenshot is great :slight_smile: good reminder of the responsibilities that come with this power…