Cloud Parts

Observable Framework

An open-source static site generator for dashboards and reports: data loaders in any language run at build time and save data snapshots that the pages load as static files.

What it is
Static read models (data apps built ahead of time)
Type
Open source
Made by
Observable, Inc.
License
ISC
Facts checked
9 October 2026
Website Source code

What it is

A Framework project is a folder of Markdown pages with reactive JavaScript code blocks, plus data loaders. A data loader is a script named for the file it produces: daily-orders.csv.py runs Python and whatever it prints to stdout becomes daily-orders.csv. JavaScript, TypeScript, Python and R are built in, shell scripts and executables work too, and more interpreters can be configured. Loaders run when observable build needs their output, which is saved to a cache in .observablehq/cache; the build only reruns a loader whose output isn’t cached. Pages load the snapshots with FileAttachment("data/daily-orders.csv"), and because those calls are found by static analysis, only referenced files are copied to dist, each with a content hash in its name so caches never serve an old version under a new page.

The result is plain HTML, JavaScript and data files that any static host or CDN can serve. Its docs make the case for that shape: data is precomputed so pages load instantly, snapshots can be aggregated and anonymized before they leave, and viewers never need access to the warehouse. Freshness comes from rebuilding; the deploy guide’s GitHub Actions workflow builds once a day and on every push. Interactivity happens in the browser: inputs re-run the reactive code, and SQL code blocks query CSV, JSON, Arrow or Parquet snapshots with DuckDB-Wasm. Parameterized routes let one page or loader generate many, such as one page per product.

Why teams pick it

  • Polyglot data loaders: query the warehouse in SQL, model in Python or R, and chart in JavaScript, in one project
  • Precomputed snapshots load instantly and keep warehouse credentials and raw data out of the browser
  • Plain files and git: any editor, code review, CI, and hosting on GitHub Pages, S3 behind a CDN or any static host
  • A large library set out of the box, including Observable Plot, D3, Mosaic, Vega-Lite and client-side DuckDB

Watch out for

  • Data is only as fresh as the last build: hourly or daily rebuilds are fine for reports, not for live operations
  • Everyone gets the same snapshot; per-user data needs runtime fetches to an API or access control in front of the site
  • Snapshots are shipped to the browser, so they must be small and pre-aggregated, and nothing in them is secret from viewers
  • Development has slowed: since January 2025 there have been two releases, a deprecation notice for deploying to Observable Cloud (April 2025) and dependency upgrades (1.13.4, March 2026), so hosting is now up to you

Alternatives

What all data apps built ahead of time have in common →
EvidenceOpen sourceBI as code: reports written in Markdown with SQL blocks and chart components. It began as a static site generator that ran every query at build time; the current version runs queries when a page loads.

How it fits with other technologies

src/data/daily-orders.csv.py: runs during `observable build`; pages load the result with `FileAttachment("data/daily-orders.csv")` · python

# Runs once per build; Framework saves stdout as data/daily-orders.csv
import csv, sqlite3, sys

db = sqlite3.connect(":memory:")  # stands in for your warehouse connection
db.executescript("""
  CREATE TABLE orders (day TEXT, amount REAL);
  INSERT INTO orders VALUES ('2026-10-01', 40), ('2026-10-01', 25), ('2026-10-02', 90);
""")
rows = db.execute("SELECT day, COUNT(*) AS orders, SUM(amount) AS revenue FROM orders GROUP BY day ORDER BY day")

out = csv.writer(sys.stdout)
out.writerow(["day", "orders", "revenue"])
out.writerows(rows)

# After the build: dist/_file/data/daily-orders.<hash>.csv contains
# day,orders,revenue
# 2026-10-01,2,65.0
# 2026-10-02,1,90.0

See it in a real stack

No architecture uses Observable Framework yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2023–2026

Before Framework, Observable was known for its hosted notebooks: reactive JavaScript documents for exploring and sharing data, written in a dialect of JavaScript of their own. Framework kept the reactive runtime but moved the work into local files, so data teams could use their own editor, source control, code review and CI, and host the result anywhere.

In February 2024 the company released Observable Framework 1.0 and billed it as Observable 2.0. Mike Bostock introduced it on Hacker News as a new open-source tool for developing data apps, written in 100% vanilla JavaScript syntax so it keeps the reactive runtime without the notebook dialect. Instead of a hosted document, a project is local files compiled to a static site, and data loaders take snapshots at build time, so dashboards load instantly without querying a database per visitor.

Releases through 2024 filled in the model: client-side SQL on DuckDB in March, parameterized routes and page loaders in September, and DuckDB-Wasm 1.29 with self-hosted extensions in November. Since then releases have been rare. In April 2025 Observable deprecated deploying data apps to Observable Cloud and pointed users to GitHub Pages, Render, Cloudflare Pages, Vercel or Netlify instead.

Why it’s built this way

A static site, not a server
Dashboards only create value if people look at them, and people don’t wait. Precomputing data at build time makes pages fast by construction and removes the need for viewers to reach the data source.
Data loaders in any language
Data teams already work in SQL, Python or R. Letting any executable produce a data file means they keep their tools for analysis and use JavaScript only for the interactive display.
Vanilla JavaScript, not the notebook dialect
Standard syntax with static imports from npm improves interoperability with editors, linters and other code, while keeping notebook-style reactivity.
Static analysis of file references
Because FileAttachment takes only literal paths, the build knows which loaders to run and which files to ship, and can give each file a content hash for cache busting on deploy.

Timeline

  1. 2023

    First preview releases on GitHub in October

  2. 2024

    Observable Framework 1.0 released in February as “Observable 2.0”

  3. 2024

    Client-side SQL powered by DuckDB arrives in 1.2 (March)

  4. 2024

    Parameterized routes and page loaders in 1.11 (September)

  5. 2025

    Deploying to Observable Cloud deprecated in April; apps move to other static hosts

  6. 2026

    1.13.4 in March, a dependency-upgrade release

Sources13 · facts checked 9 October 2026

Improve this page on GitHub