Project 11: Safe Attached-Runtime Triage Console

Compare standalone, Remote Execution, and attached-runtime behavior against a disposable local Phoenix or OTP node using only allowlisted, bounded, read-only diagnostics.

Quick Reference

Attribute Value
Difficulty Level 3 — Advanced
Time Estimate 20–30 hours
Language Elixir; Erlang terms and runtime tools where already present on the target
Prerequisites OTP processes, links/monitors, Livebook runtime model, basic distributed Elixir, operational safety
Key Topics Standalone runtime, Remote Execution Smart Cell, attached runtime, Erlang distribution, bounded diagnostics, authority mapping

1. Learning Objectives

By completing this project, you will:

  1. Prove where the evaluator, dependencies, and diagnostic code run in each runtime mode.
  2. Explain why standalone, remote execution, and attached runtime have different authority and failure coupling.
  3. Create a disposable target node with synthetic processes and data suitable for fault exercises.
  4. Design a named catalog of read-only diagnostics rather than accepting arbitrary source or module/function input.
  5. Bound diagnostic time, result rows, serialized bytes, concurrency, and refresh frequency.
  6. Handle target disconnect, timeout, target crash, stale PID, and oversized result without freezing the notebook.
  7. Protect and redact node names, distribution cookies, host details, and process metadata in saved evidence.
  8. Decide when a narrow service API is safer than either remote execution or attachment.
  9. Stop at the disposable-environment boundary; no production connection is required or permitted by this project.

2. Theoretical Foundation

2.1 Core Concepts

A runtime defines evaluator location. Livebook’s default standalone runtime is a separate Erlang VM for the notebook. It can declare notebook-specific packages through Mix.install. An attached runtime evaluates notebook code inside an existing external node and therefore uses that node’s loaded code, configuration, process space, and operating-system authority. It cannot casually install new dependencies because it is not an isolated package environment.

Remote execution preserves a split boundary. The notebook remains on its standalone runtime with Kino and analytical dependencies, while an allowlisted expression runs on the target and returns a bounded value. This is often preferable for rich diagnostic presentation because charting packages stay off the target. It still uses distributed Erlang authority and is not equivalent to a least-privilege HTTP endpoint.

Erlang distribution is a privileged channel. Node names, connectivity, TLS/network configuration where applicable, and a shared cookie participate in connection. Possessing the cookie can grant broad distributed-node capabilities; it is not merely a label. Use a unique disposable-training cookie, loopback-only topology, and no production cookie or hostname.

Observation can change the observed system. Enumerating every process, copying large states, requesting expensive process information, or repeatedly polling can consume scheduler time, memory, and network bandwidth. A diagnostic is safe only when it filters and summarizes on the target, applies a timeout, caps output, and records its own cost.

Read-only is a designed catalog, not a promise. An arbitrary evaluation channel can mutate state even if the UI says “read only.” This project exposes named diagnostic operations whose implementation is reviewed and whose outputs are bounded. It does not accept arbitrary SQL, Elixir strings, module names, function names, PIDs, registry names, or shell commands from the browser.

Process identifiers are ephemeral. PIDs become stale after restart and can eventually be reused. Diagnostics should select processes from current allowlisted groups or registered training names and attach observation time/generation. Never carry an old PID forward as durable identity.

2.2 Why This Matters

Livebook can make live BEAM systems unusually understandable, but its power creates a sharp trust boundary. Engineers need to know whether code executes beside the notebook, briefly on a remote node, or entirely inside the target. This lab teaches that distinction with evidence and controlled failure before anyone considers a real environment. It also demonstrates why stable production diagnostics usually graduate into an authenticated, rate-limited, independently audited service API.

2.3 Historical Context / Background

The BEAM has long supported distributed nodes, remote calls, process inspection, and attached shells. Livebook packages those capabilities into explicit runtime choices and a Remote Execution Smart Cell. Official Livebook runtime documentation currently describes standalone, attached-node, Fly.io, and Kubernetes Pod runtimes, including attached execution within an existing application node. The Livebook runtime guide and Livebook use cases are the primary references; Elixir Node, Process, and Task document the underlying language/runtime behavior.

2.4 Common Misconceptions

  • “Attached means the notebook can still install its own packages.” It runs in the target’s existing code environment.
  • “Remote Execution is a narrow RPC API.” It remains a powerful distributed-code channel unless constrained operationally.
  • “The cookie identifies a user.” It is a shared distribution secret, not per-user authorization.
  • “Read-only diagnostics cannot hurt performance.” Large or frequent observations can destabilize the target.
  • “A PID identifies a durable component.” It identifies one process incarnation.
  • “This lab prepares a production connection.” It prepares judgment; the required work ends at a disposable local target.

3. Project Specification

3.1 What You Will Build

Create a training repository with:

  • one disposable local Phoenix or OTP application started as a named node with a unique training cookie;
  • synthetic workers, queues, supervised restarts, and safe mock metrics;
  • a Livebook console with three explicitly separated demonstrations: standalone, Remote Execution, and attached;
  • an allowlisted catalog containing process summary, queue-depth summary, application versions, scheduler summary, and one training-worker health check;
  • timeout, row, byte, concurrency, and refresh bounds;
  • a redacted transcript showing evaluator node, target node alias, diagnostic identifier, start/end time, result count, bytes, and outcome;
  • failure drills for disconnect, timeout, oversized result, stale process, and target restart.

No operation may mutate target application state, start/stop target children, execute arbitrary strings, inspect secrets, read user data, or connect to any non-disposable node.

3.2 Functional Requirements

  1. Environment gate: target advertises an explicit disposable-training marker; console refuses any target without it.
  2. Mode evidence: every result displays evaluator alias, target alias, and where dependencies are loaded.
  3. Standalone demonstration: prove notebook package isolation without target access.
  4. Remote Execution demonstration: run one named diagnostic remotely and render it locally.
  5. Attached demonstration: prove evaluator and target share a node and show dependency limitations.
  6. Catalog: only fixed diagnostic identifiers and validated bounded parameters are accepted.
  7. Budgets: enforce timeout, maximum result items, maximum encoded bytes, concurrency, and minimum refresh interval.
  8. Redaction: raw cookie, real host details, environment secrets, stack state, and sensitive process metadata never appear in output.
  9. Failure states: disconnected, unauthorized, timed out, too large, target restarted, and unsupported diagnostic are distinct.
  10. Cleanup: notebook listeners and disposable target are stopped through documented, idempotent local procedures.

3.3 Non-Functional Requirements

  • Safety: loopback/disposable environment only; no production configuration accepted.
  • Observability: each diagnostic records its duration, output size, truncation, and source timestamp.
  • Responsiveness: one slow diagnostic cannot block the UI listener or leave an unbounded task.
  • Reproducibility: target revision, notebook revision, OTP/Elixir versions, and synthetic fixture seed are recorded.
  • Reviewability: diagnostic catalog implementation lives in a normal Mix project with tests.
  • Privacy: outputs use synthetic process names and data; evidence is redacted before save/export.

3.4 Example Usage / Output

TRIAGE CONSOLE — DISPOSABLE TARGET ONLY
Mode: Remote Execution from standalone runtime
Evaluator: notebook-training-node
Target alias: disposable-app-A
Target marker: LIVEBOOK_TRAINING_TARGET=true [VERIFIED]

Diagnostic: queue_depths.v1
Timeout: 2,000 ms
Result limit: 100 rows / 256 KiB
Refresh limit: once per 5 seconds
Mutation capability exposed by UI: NONE

RESULT
Observed at: 2026-07-15T18:42:03Z
Rows: 6
Encoded bytes: 1,284
Target execution: 7 ms
Round trip: 11 ms
Truncated: false
Status: PASS

3.5 Real World Outcome

Start the disposable target and open the console in standalone mode. The comparison view shows that local Kino and analytical dependencies belong to the notebook node. Use Remote Execution to retrieve one synthetic queue summary and render a local table. Switch a copy of the notebook to attached mode; node identity proves evaluation now occurs inside the target and the package setup path is unavailable.

Then perform controlled failure drills:

SAFETY DRILL SUMMARY
non-training target marker ........ REFUSED
target disconnect ................. BOUNDED FAILURE
diagnostic timeout ................ TASK TERMINATED / UI RESPONSIVE
oversized result .................. TRUNCATED AT SOURCE
stale PID after restart ........... RESELECTED BY TRAINING NAME
cookie value in evidence scan ..... NOT FOUND
production host patterns scan ..... NOT FOUND

The final notebook ends with a comparison and recommendation: use standalone plus a narrow read-only API for repeatable production diagnostics; use this attached-mode knowledge only to understand risk.

4. Solution Architecture

4.1 High-Level Design

MODE A — STANDALONE
┌──────────────────────┐          ┌───────────────────────┐
│ Livebook runtime     │          │ Disposable target     │
│ Kino + local deps    │          │ no connection         │
└──────────────────────┘          └───────────────────────┘

MODE B — REMOTE EXECUTION
┌──────────────────────┐  bounded  ┌───────────────────────┐
│ Standalone runtime   │──────────▶│ diagnostic catalog    │
│ Kino + rendering     │◀──────────│ filter + summarize    │
└──────────────────────┘  result   └───────────────────────┘

MODE C — ATTACHED
┌──────────────────── Livebook UI ────────────────────────┐
└──────────────────────────┬──────────────────────────────┘
                           │ evaluator runs inside
                           v
                 ┌───────────────────────┐
                 │ Disposable target     │
                 │ app + evaluator       │
                 │ existing deps only    │
                 └───────────────────────┘

4.2 Key Components

Component Responsibility Key Decisions
Disposable target Host synthetic supervised workload Loopback, unique cookie, explicit training marker
Diagnostic catalog Map fixed IDs to reviewed read-only observations No arbitrary MFA, source, PID, or registry input
Target summarizer Filter and cap before transfer Reject or truncate at source
Remote adapter Execute named diagnostic with deadline Return structured result/error only
Attached notebook copy Demonstrate evaluator location Separate file/session to avoid mode confusion
Evidence redactor Replace sensitive topology/process data Applied before render and export
Safety gate Verify marker, alias, allowlist, and budget Fail closed on uncertainty

4.3 Data Structures

diagnostic_request = {
  catalog_id,
  bounded_parameters,
  deadline_ms,
  max_rows,
  max_encoded_bytes,
  request_id
}

diagnostic_result = {
  request_id,
  catalog_revision,
  observed_at,
  target_execution_ms,
  rows,
  encoded_bytes,
  truncated,
  redacted_payload,
  status
}

safety_context = {
  disposable_marker_verified,
  evaluator_alias,
  target_alias,
  mode,
  notebook_revision,
  target_revision
}

4.4 Algorithm Overview

Key Algorithm: Bounded Diagnostic Dispatch

  1. Verify that the selected target is loopback/disposable and exposes the expected training marker.
  2. Resolve the requested diagnostic from a fixed catalog.
  3. Validate parameters against the catalog entry and apply the stricter of user and server limits.
  4. Start supervised bounded work with a deadline.
  5. Filter, aggregate, sort, and cap on the target before serialization.
  6. Reject results over the byte contract or return an explicitly truncated summary.
  7. Redact topology and process details before rendering or export.
  8. Record timing, count, bytes, revision, and outcome.
  9. On timeout or disconnect, terminate local waiting work and show a distinct failure state.

Complexity Analysis:

  • Target scan: O(P) for P synthetic processes, but output remains O(K) for configured cap K.
  • Sorting a bounded summary: O(K log K).
  • Network/serialization: O(B) for result byte limit B.
  • Notebook memory: O(B + rendered bounded table), independent of total target process count after target-side aggregation.

5. Implementation Guide

5.1 Development Environment Setup

Use one local workstation and loopback networking. Generate a unique disposable cookie and never reuse credentials from another environment. Keep the target repository visibly named as training-only.

Disposable target prerequisites:
  environment marker: LIVEBOOK_TRAINING_TARGET=true
  network: loopback only
  data: synthetic only
  cookie: unique, ephemeral, never printed

Verification transcript:
  target marker ........ PASS
  target alias ......... disposable-app-A
  non-loopback route ... REFUSED

Consult the current runtime configuration UI and official runtime documentation rather than copying a version-sensitive full launch command from this guide.

5.2 Project Structure

attached-runtime-lab/
├── disposable_target/
│   ├── lib/
│   │   ├── training_target/application.ex
│   │   ├── training_target/synthetic_worker.ex
│   │   └── training_target/diagnostics.ex
│   ├── test/
│   │   └── diagnostics_test.exs
│   └── config/
│       └── training-only configuration
├── notebooks/
│   ├── runtime-comparison-standalone.livemd
│   └── runtime-comparison-attached.livemd
├── fixtures/
│   └── synthetic-workload-manifest.json
├── evidence/
│   └── redacted-transcript-schema.md
└── README.md

5.3 The Core Question You’re Answering

“Where does notebook code execute, and how does that location change dependencies, authority, risk, and failure?”

Answer with observed evaluator node, dependency location, process visibility, and failure behavior—not a diagram alone.

5.4 Concepts You Must Understand First

  1. Livebook runtime types
    • What processes evaluate cells in standalone and attached modes?
    • Primary reference: Livebook runtimes
  2. Remote execution use case
  3. Distributed Elixir
    • What do node naming, connection, cookies, and remote process semantics imply?
    • Primary reference: Elixir Node
  4. Process observation
    • Which process information is safe and bounded to request?
    • Primary reference: Elixir Process
  5. Task failure and deadlines
    • How are timeout, exit, and cleanup represented?
    • Primary reference: Elixir Task
  6. Operational stability
    • Why can observability overload the observed system?
    • Book reference: Release It!, 2nd ed. — stability and operations chapters

5.5 Questions to Guide Your Design

  1. What unforgeable-enough local evidence distinguishes the disposable target from any other node in this lab?
  2. Which five diagnostics are necessary, and why is every other operation excluded?
  3. Where are row, byte, time, concurrency, and frequency bounds enforced?
  4. Which data is summarized on target instead of copied to Livebook?
  5. What happens when the target restarts between process selection and observation?
  6. How does the notebook remove topology and cookie data before save?
  7. What production requirement would justify building an API instead?

5.6 Thinking Exercise

Create three trust maps—standalone, Remote Execution, and attached. For each, fill in:

Question Answer to determine
Where is the evaluator? notebook node or target node
Where are Kino dependencies? notebook or target code path
What credential enables access? none, API credential, or distribution secret
Which processes can code see? notebook only or target process space
What failure affects the target? bounded request, remote execution, or evaluator work inside target
What output crosses the boundary? none, bounded summary, or direct cell result

Then write the safest architecture for a repeated production diagnostic. It should normally be a narrow API, not attachment.

5.7 The Interview Questions They’ll Ask

  1. “How does Livebook attached runtime differ from Remote Execution?”
  2. “Why is an Erlang cookie a sensitive shared secret rather than user identity?”
  3. “Why can attached mode not freely use Mix.install?”
  4. “How can process inspection affect scheduler and memory behavior?”
  5. “How do you design a read-only diagnostic catalog?”
  6. “When should a diagnostic move behind an HTTP or application API?”

5.8 Hints in Layers

Hint 1: Make the target disposable by construction

Use loopback, synthetic data, an explicit marker, a unique cookie, and a separate repository/configuration.

Hint 2: Prove location before inspecting anything

Render evaluator alias, target alias, and dependency availability at the top of every mode.

Hint 3: Summarize remotely

Filter and cap on the target. Do not transfer all PIDs or states and then decide what to show.

Hint 4: Fail closed

If the training marker, allowlist, deadline, or result cap cannot be verified, refuse the operation.

5.9 Books That Will Help

Topic Book Chapter
Distributed Elixir Elixir in Action, 3rd ed. Distribution chapter
Supervision and process design Designing Elixir Systems with OTP Chapters 3–8
Operational safety Release It!, 2nd ed. Stability patterns and operations chapters
Access boundaries Foundations of Information Security Authentication and access-control chapters

5.10 Implementation Phases

Phase 1: Disposable Target and Catalog (6–9 hours)

Goals: create synthetic workload, training marker, diagnostic catalog, and target-side bounds.

Tasks:

  1. Seed supervised synthetic workers and queues.
  2. Define five read-only diagnostic result schemas.
  3. Add target-side timeout, row, and byte policies.
  4. Test high process count, stale process, and restart fixtures.

Checkpoint: catalog tests prove bounded outputs without Livebook.

Phase 2: Runtime Comparison (7–10 hours)

Goals: observe evaluator and dependency location in all three modes.

Tasks:

  1. Create the standalone comparison notebook.
  2. Add one Remote Execution diagnostic and local Kino rendering.
  3. Create a separate attached-runtime notebook copy.
  4. Record node identity, code availability, and failure behavior.

Checkpoint: evidence clearly distinguishes all modes and contains no raw cookie.

Phase 3: Failure, Redaction, and Recommendation (7–11 hours)

Goals: harden failure handling and document production judgment.

Tasks:

  1. Test disconnect, timeout, target restart, oversized result, and wrong marker.
  2. Scan saved notebook and exports for canary secrets/topology.
  3. Verify task cleanup and UI responsiveness.
  4. Write the narrow-API production migration recommendation.

Checkpoint: all safety drills pass and no non-disposable target is contacted.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Target Existing dev service; purpose-built disposable app Purpose-built disposable app Makes data, authority, and failure safe to control
Operation selection Arbitrary source/MFA; fixed catalog Fixed catalog UI “read-only” cannot constrain arbitrary code
Output bounding Cap after transfer; summarize/cap on target Summarize/cap on target Protects both target and notebook
Rich visualization Load packages into target; render on standalone node Remote Execution plus local rendering Reduces target coupling
Process selection User-supplied PID; allowlisted training group/name Allowlisted current selection Avoids stale/arbitrary process inspection
Production path Reuse attached notebook; build narrow service API Build narrow service API Supports RBAC, rate limits, and independent audit

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Catalog unit Prove operations are read-only and bounded large process set, sorted top-K, byte cap
Environment gate Prevent wrong target missing marker, wrong alias, non-loopback target
Mode evidence Prove evaluator/dependency location node identity, code availability
Failure Bound operational faults disconnect, timeout, target exit, stale PID
Redaction Protect saved evidence cookie canary, hostname canary, process metadata
Cleanup Avoid leaked listeners/tasks repeated run, reconnect, target shutdown

6.2 Critical Test Cases

  1. Wrong target marker: console refuses before any diagnostic.
  2. Unsupported diagnostic: arbitrary identifier is rejected locally and remotely.
  3. Parameter abuse: excessive limits are reduced to server policy or rejected.
  4. Slow diagnostic: deadline returns timeout and terminates waiting work.
  5. Oversized result: target returns bounded/truncated summary; full data never crosses.
  6. Target disconnect: UI remains responsive and reports connection failure distinctly.
  7. Target restart: old PID is never reused as logical identity; current synthetic name is resolved again.
  8. Evidence scan: seeded cookie and topology canaries are absent from .livemd, logs, and export.
  9. Attached dependency attempt: limitation is shown as expected behavior, not “fixed” by changing target packages.
  10. No production contact: network evidence contains only documented loopback/disposable nodes.

6.3 Test Data

Synthetic target fixture:
  50 normal workers
  5 workers with growing bounded training queues
  1 deliberately slow diagnostic source
  1 restartable worker with logical training name
  1 oversized synthetic metadata source

Canaries:
  cookie-like secret value
  fake internal hostname
  fake customer identifier

Expected:
  bounded summaries only; all canaries absent from saved evidence

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Attached notebook runs setup packages Dependency setup fails or risks target change Keep attached notebook dependency-free; render rich UI locally through remote mode
Arbitrary MFA accepted “Read-only” tool can call mutating functions Fixed catalog with no user-selected module/function
Full process list transferred Browser freezes and target allocates heavily Aggregate and cap at target
Cookie logged during debugging Secret appears in cell output or Git Use secret configuration and canary scans; never inspect raw value
Old PID retained Diagnostic observes wrong/dead incarnation Resolve current logical training name on each request
Reconnect tasks leak Repeated timeout messages or duplicated output Supervised deadlines and idempotent cleanup

7.2 Debugging Strategies

  • Start with identity: verify evaluator and target aliases before any result.
  • Test target module directly: distinguish catalog bugs from distribution bugs.
  • Observe encoded bytes: row count alone may hide large payloads.
  • Force each failure separately: disconnect, timeout, and target crash are different states.
  • Inspect current process references: stale PIDs often explain inconsistent results.
  • Scan saved evidence last: runtime redaction is incomplete until .livemd and exports are checked.

7.3 Performance Traps

Avoid repeated global process enumeration, copying process dictionaries or full states, high-frequency polling, sorting unbounded results, synchronous long diagnostics in a UI listener, and transferring large terms before truncation. Use target-side sampling and fixed refresh minimums.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a runtime comparison table generated from recorded evidence.
  • Add a freshness indicator for every diagnostic.
  • Add a local-only export with topology aliases and no raw identifiers.

8.2 Intermediate Extensions

  • Add a supervised health summary for one additional synthetic subsystem.
  • Measure diagnostic overhead as target worker count increases.
  • Compare Remote Execution with a mock read-only HTTP diagnostic endpoint.

8.3 Advanced Extensions

  • Build the mock HTTP endpoint with scoped identity, RBAC, rate limits, and independent audit, then retire attachment from the repeated workflow.
  • Add distribution TLS inside the disposable lab and document what it changes and does not change.
  • Create property-based tests proving catalog parameter bounds and encoded-size limits.

No extension may connect to production or introduce mutation.

9. Real-World Connections

9.1 Industry Applications

  • Incident diagnostics: bounded process and queue health summaries.
  • Release verification: inspect loaded application versions in a controlled environment.
  • Performance labs: correlate synthetic queue pressure with scheduler observations.
  • Migration tools: understand an existing node before designing a safer API.
  • Training: make distributed Elixir authority and failure visible without risking real data.
  • Livebook: runtime orchestration and Remote Execution integration.
  • Phoenix: suitable disposable application target.
  • Elixir: Node, Process, Task, and OTP interfaces.
  • Erlang/OTP: distribution and runtime tools beneath Elixir.

9.3 Interview Relevance

This project demonstrates runtime authority, distributed Erlang, process inspection, supervision, timeouts, bounded output, failure classification, secret handling, observability overhead, and the architectural judgment to replace powerful shells with narrow APIs.

10. Resources

10.1 Essential Reading

  • Livebook runtimes — current runtime choices and attached-node semantics.
  • Livebook use cases — Remote Execution and attached diagnostics.
  • Elixir Node — node connectivity and basic distributed operations.
  • Elixir Process — process information and monitoring.
  • Elixir Task — asynchronous work, timeout, and shutdown behavior.
  • Release It!, 2nd ed. — stability and operational-boundary chapters.

10.2 Video Resources

  • Use the installed Livebook Learn notebooks and official runtime demonstrations linked from Livebook News.
  • Prefer official ElixirConf talks linked from Elixir/Livebook project pages for distributed runtime behavior.

10.3 Tools & Documentation

  • Livebook Runtime sidebar: configure and visibly verify runtime mode.
  • Remote Execution Smart Cell: bounded training-node exercise.
  • Structured Logger metadata: local redacted timing and outcome evidence.
  • Network/process inspection on the local lab: verify that only disposable loopback nodes participate.

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain evaluator and dependency location in all three modes.
  • I can explain why a cookie is sensitive but not per-user authorization.
  • I can explain how observation can overload a target.
  • I can defend the recommendation to build a narrow production API.

11.2 Implementation

  • Disposable marker and loopback safety gate pass.
  • Only allowlisted diagnostics and bounded parameters exist.
  • Timeout, disconnect, target restart, oversized output, and cleanup tests pass.
  • Saved evidence contains no cookie or topology canary.
  • No production node or credential was used.

11.3 Growth

  • I can translate one catalog diagnostic into an API contract.
  • I documented which attached-mode convenience carries the greatest risk.
  • I can teach another engineer why runtime choice is an authority decision.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • One disposable target, one allowlisted diagnostic, and clear standalone versus attached evaluator evidence.
  • Timeout and result cap work.
  • No cookie appears in saved output.

Full Completion:

  • All three modes, five diagnostic catalog entries, environment gate, target-side bounds, disconnect/timeout/restart/oversize drills, redaction scan, idempotent cleanup, and production-API recommendation are complete.
  • Evidence proves only a disposable loopback target was contacted.

Excellence (Going Above & Beyond):

  • Replace one repeated diagnostic with a mock authenticated read-only API featuring scoped authorization, rate limiting, freshness, and independent audit; compare its authority map with Remote Execution and attachment.

This guide was generated from LEARN_LIVEBOOK_ELIXIR_DEEP_DIVE.md. For the complete learning path, see the parent guide.