ArchiveBox

Last reviewed Aug 26, 2026 · 868 words

Budget 5 to 20 MB per page with the default extractors on, and plan for a few hundred MB per page the moment SAVE_MEDIA finds a video. That single number explains most of the complaints about ArchiveBox: it is a thorough archiver of 28,000-star pedigree, and thoroughness is a storage bill. Turn the extractors you do not need off before you import 4,000 bookmarks, not after.

Each extractor is a separate copy of the page

ArchiveBox does not save a page once. For every URL it runs a chain of independent extractors: a wget mirror with assets, a single-file HTML, a Chromium-rendered DOM dump, a PDF, a full-page screenshot, a readability text extract, and optionally yt-dlp for any media it finds. Each writes into archive/<timestamp>/ alongside the others, so a news article ends up as six or seven redundant representations. That redundancy is the feature: when the wget copy is broken by lazy-loaded JavaScript, the screenshot and PDF still read fine 5 years later.

The controls are plain environment variables, and the two I flip on every install are these:

services:
  archivebox:
    image: archivebox/archivebox:latest
    ports:
      - "8000:8000"
    volumes:
      - ./data:/data
    environment:
      - SAVE_MEDIA=false
      - SAVE_ARCHIVE_DOT_ORG=false
    restart: unless-stopped

SAVE_MEDIA=false stops yt-dlp from pulling a 900 MB video because a blog post embedded a YouTube clip. SAVE_ARCHIVE_DOT_ORG=false stops ArchiveBox from submitting every URL you archive to the Wayback Machine, which is a fine public service but a surprising default if some of those URLs are internal or private.

Three commands do 90 percent of the work

After the compose file is in place, initialisation, adding, and serving are the whole daily interface:

docker compose run archivebox init --setup
docker compose run archivebox add 'https://example.com/article'
docker compose run archivebox add --depth=1 < bookmarks.txt

init --setup creates the SQLite index and prompts for an admin user. add accepts a URL, a file of URLs, a browser bookmarks HTML export, an RSS feed, or a Pocket export, which is why it works as a Pocket replacement for people who want the pages rather than the links. --depth=1 also archives every link found on each page, which is the second way to fill a disk by accident; I use it only for individual pages I genuinely want the context of. For recurring pulls, archivebox schedule --every=day 'https://example.com/feed.xml' sets up a cron inside the container.

The Python data path matters here: the catalogue rates this Medium difficulty and asks for 1 GB of RAM, and the reason is headless Chromium. Every screenshot and PDF spins up a browser. On a 1 GB VPS it works; on a 512 MB one it gets killed mid-page.

It is not a bookmark manager, and pretending hurts

ArchiveBox has a web UI at port 8000 with search, tags, and a snapshot list, and people keep trying to use it as their daily bookmarks tool. It is the wrong shape for that: adding is slow because it archives, the index is organised by capture time rather than by your taxonomy, and there is no browser extension worth the name. The pattern that works is a light bookmark manager in front and ArchiveBox behind it. Linkding or Wallabag for the reading queue and tags, and a nightly job that feeds their export into archivebox add. The rest of the bookmarks category is mostly variations on that front end.

Check who can see your snapshots

The web UI has separate switches for whether the index and the snapshots are viewable without logging in, and the archive-friendly defaults lean towards public. Before you reverse-proxy this onto the internet, set PUBLIC_INDEX=false and PUBLIC_SNAPSHOTS=false in the environment and confirm in a private browser window. An archive of your logged-in bank pages and private forum threads is exactly what a Chromium extractor will faithfully capture if you fed it those URLs, and exactly what you do not want indexable.

Backing up the backup

The archive is plain files in data/archive/ plus data/index.sqlite3, all open formats, which is the project's best design decision. You can grep it, rsync it, and read it with no ArchiveBox installed. Include it in the same 3-2-1 rotation as everything else, but note it is append-heavy and large, so a deduplicating tool like restic will be far kinder to your offsite storage than a nightly tarball. Re-running archivebox add on an existing URL creates a new snapshot rather than overwriting, so the archive only grows.

What I'd do

Docker on a box with a real disk rather than a VPS, SAVE_MEDIA and SAVE_ARCHIVE_DOT_ORG off from day one, public index and snapshots off before any exposure. Linkding as the daily front door, a nightly script that pipes its export into archivebox add, and a monthly glance at du -sh data/archive. Treat ArchiveBox as the cold, permanent layer under a lighter bookmarks tool and it is the best self-hosted answer to "that page I saved in 2019 is gone now".