wallabag

Read-it-later that keeps the article text, not a link that rots

FeedsMITMaturearm64 builds

Last reviewed 8 September 2026Profile maintained against the project's own documentation

Operational load

3 / 5

Moderate

Idle memory

180 MB

typical use ~350 MB

Moving parts

containers in a normal deployment

Backup shape

SQLite backup

needs a dump or a stop

A save-for-later service that extracts and stores the readable text of a web page, tags it, and serves it back as HTML, EPUB, PDF or a feed. It replaces Pocket, which Mozilla shut down in 2025, and Instapaper.

Our verdict on wallabag#

wallabag does the one thing Pocket did and does it on your disk: fetch the page, extract the readable text, keep it forever. It is worth being blunt about the cadence. The last release was 2.6.14 in October 2025, and as of September 2026 there has not been another, so the published Docker image is roughly a year old. The repository is not dead (there is daily activity on master), but most of it is dependency maintenance, and wallabag 3.0, the Symfony upgrade and restructure, has still not landed years after it was announced; the team's own position is that it ships when it is ready, with no calendar. Treat wallabag as stable-and-slow, not as abandoned. In practice it works, it has mobile apps and browser extensions, the documented Docker default is SQLite in a single container, and 2.6.14 added Pocket CSV import specifically to catch people leaving Pocket. If you want something under active weekly development, look at Karakeep instead and accept a much larger stack.

Who wallabag is for#

Choose it if

Ex-Pocket users who want the same workflow and the article text stored locally rather than a link in someone else's cloud
People who read on an e-reader, since EPUB, MOBI and PDF export are first-class and there is a per-tag feed
Anyone pairing it with a feed reader; Miniflux and FreshRSS both push directly into wallabag
Long-horizon archivists who want plain extracted text they can still read in ten years, not a snapshot bundle

Look elsewhere if

You want full visual page archives with images and layout preserved; wallabag keeps readable text, not a rendering
You need OIDC or LDAP login without an auth proxy
A year between releases makes you nervous, or you need a fix for something and cannot wait for an unscheduled release

What running it actually looks like#

The documented Docker path is one container: wallabag/wallabag on port 80, published on 8080, with two volumes, /var/www/wallabag/data and /var/www/wallabag/web/assets/images, and SQLite as the backend. The variable that must be right on first boot is SYMFONY__ENV__DOMAIN_NAME, set to the full external URL including scheme and port, because it is baked into generated links, the API and password reset emails. Default credentials are wallabag:wallabag; change them before you expose anything. For anything past a few thousand articles, point SYMFONY__ENV__DATABASE_DRIVER at pdo_mysql or pdo_pgsql and add a database container. Redis or RabbitMQ is optional and only exists for asynchronous imports. Upgrades run Doctrine migrations and then need the Symfony cache cleared, which the image does on start.

Resource profile#

Memory: 180 MB idle, around 350 MB in ordinary use. PHP-FPM plus nginx in one image. `PHP_MEMORY_LIMIT` is the number that actually matters: content extraction on a heavy page and bulk imports are what push a worker over it. Estimates, not documented minimums.
CPU and acceleration: Bursty. Every save runs the content extractor over the fetched HTML, and an import of a few thousand Pocket entries will saturate a core for a long time; use the Redis or RabbitMQ async import path if you have more than a few hundred.
Storage growth: Article text is small, a few kilobytes each, but downloaded images go to `web/assets/images` and that directory is what grows. Ten thousand saved articles with images is realistically single-digit gigabytes.
Operational load: 3 of 5, Moderate. A Symfony app with a database, a cache directory that has to be cleared after config changes, and an install where the domain name is baked into configuration. It upgrades cleanly, but a restore has an order and the cache is a real footgun.

Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.

Data and backup surface#

Two paths and a database. data/ holds config and, on the default Docker setup, the SQLite file; web/assets/images holds every downloaded article image and is usually the bulk of the bytes. On MySQL or PostgreSQL take a dump instead of copying files, and keep parameters.yml or the environment variables with it, because the Symfony secret and the database credentials live there and a restore without them will not boot. Do not back up var/cache; it is generated and a stale cache restored onto a different domain is a classic cause of a wallabag that returns 500s. Also export your library as JSON from the UI periodically: it contains the extracted article text and is the format-independent escape hatch.

Derived backup shape

SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.

Traps and surprises#

Getting SYMFONYENVDOMAIN_NAME wrong is not a quick fix

The domain name is written into configuration at install and used to build every absolute URL, including API endpoints and the links in reset emails. Set it to http://localhost:8080 for a test and later move to https://read.example.com and the app keeps emitting the old URL until you change the variable and clear var/cache. Decide the final URL before the first boot.

Default credentials are published

A fresh install has user wallabag with password wallabag. That is in the official installation docs, so it is in every scraper's wordlist. Change it in the first session, and if the instance is internet-facing enable the built-in two-factor before you tell anyone the address.

Large imports need the async queue

Importing a Pocket or Instapaper export synchronously runs the content extractor once per entry in the web request path. A few thousand entries will time out, half-import, and leave you deduplicating. Configure Redis or RabbitMQ and run the import through the queue, or split the export file and feed it in chunks.

SQLite is the Docker default, not the recommendation

The single-container quickstart uses SQLite because it needs no second service. It is fine for a personal library of a few thousand articles and it gets slow and lock-prone beyond that, particularly during imports and tag queries. Moving later means an export and re-import rather than a driver switch, so pick MySQL or PostgreSQL up front if you expect to save heavily.

The published PHP requirement is stale

The requirements page still states PHP 7.4 or greater, which reflects the 2.6 line rather than what current PHP releases support. If you are installing outside Docker, use the PHP version the current release's CI actually tests against rather than the documented floor, and prefer the official image if you would rather not make that judgment yourself.

Specifications#

Category: Feeds, bookmarks and read-it-later
Licence: MIT (Permissive)
Written in: PHP / Symfony
First release: 2013
Maturity: Mature
Datastore: SQLite by default in Docker; MySQL/MariaDB or PostgreSQL supported and preferred at scale
Default ports: 80
Ships as: docker, php on any web server, shared hosting package
arm64 builds: Yes
Identity: Auth proxy only. Local accounts with optional two-factor by email or TOTP; there is no OIDC and no supported LDAP in core, so SSO means an auth proxy in front and a matching local user.
Replaces: Pocket, Instapaper, Readwise Reader, Safari Reading List
Project site: wallabag.org
Source: github.com/wallabag/wallabag
Documentation: doc.wallabag.org

Alternatives to wallabag#

Everything else in feeds, bookmarks and read-it-later, closest in operational weight first.

Tool	Ops load	Idle RAM	Licence
Karakeep	3, Moderate	700 MB	AGPL-3.0
Miniflux	3, Moderate	40 MB	Apache-2.0
FreshRSS	2, Light	90 MB	AGPL-3.0
linkding	1, Set and forget	90 MB	MIT

Where wallabag comes up elsewhere#

Head to head

FreshRSS vs Miniflux

Migration guides

Sources#

Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.

Published 8 September 2026. Last reviewed 8 September 2026. Found something out of date? Tell us and we will fix it and log the change.