Wallabag

Last reviewed Aug 26, 2026 · 835 words

The most common wallabag failure is a login form that bounces you straight back to itself, and the cause is almost always SYMFONY__ENV__DOMAIN_NAME not matching the URL in your address bar, scheme included. Set it to https://read.example.com exactly, redeploy, and the problem is gone. I open with that because wallabag is otherwise a well-behaved application, and that one variable accounts for most of the "wallabag is broken" threads you will find while searching for help.

Compose with Postgres and registration off

services:
  wallabag:
    image: wallabag/wallabag:latest
    ports:
      - "8085:80"
    environment:
      SYMFONY__ENV__DOMAIN_NAME: https://read.example.com
      SYMFONY__ENV__SERVER_NAME: "wallabag"
      SYMFONY__ENV__FOSUSER_REGISTRATION: "false"
      SYMFONY__ENV__DATABASE_DRIVER: pdo_pgsql
      SYMFONY__ENV__DATABASE_HOST: db
      SYMFONY__ENV__DATABASE_PORT: 5432
      SYMFONY__ENV__DATABASE_NAME: wallabag
      SYMFONY__ENV__DATABASE_USER: wallabag
      SYMFONY__ENV__DATABASE_PASSWORD: change-this
      POSTGRES_USER: wallabag
      POSTGRES_PASSWORD: change-this
    volumes:
      - ./wb-images:/var/www/wallabag/web/assets/images
    depends_on:
      - db
    restart: unless-stopped
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: wallabag
      POSTGRES_USER: wallabag
      POSTGRES_PASSWORD: change-this
    volumes:
      - ./pg-data:/var/lib/postgresql/data
    restart: unless-stopped

First login is wallabag / wallabag; change it, then create real users from the internal settings. The image also runs on SQLite if you leave the database variables out, and for one reader that is adequate, but the catalogue's "requires a database" is literal: wallabag is a PHP Symfony application with a real schema, and Postgres makes the backup story a pg_dump instead of copying a file the app might be writing to. Budget the listed 512 MB; the PHP workers are the bulk of it.

Extraction is good, fixable, and never perfect

wallabag pulls the article body with the graby library, using a shared database of per-site rules that say where the content lives on each domain. When a site is covered, the saved article is clean: text, images, no sidebar. When it is not, you get either a reasonable guess or the site's cookie banner. Two fixes. You can write a site config file yourself (a few lines naming the selectors for title and body) and drop it into the site_config directory. And some failures are structural: paywalled pages, articles rendered entirely by JavaScript, and sites that block anything without a browser fingerprint will not extract from a server, whatever the rules say. Saving those as a bookmark and reading at the source is the honest workaround.

Bringing Pocket in after the shutdown

Pocket closed in 2025, and its export was a CSV of URLs with tags and timestamps. Recent wallabag releases accept that file on the import page, alongside Instapaper CSV, wallabag v1 and v2 exports, Readability, Pinboard, Omnivore and browser bookmark files. Imports re-fetch every article, so 3,000 saved links means a long-running job and a burst of outbound traffic; an optional Redis-backed queue moves the fetching to a background worker and is worth setting up for anything above a few hundred items. Expect a percentage of old links to be dead or to extract badly. That loss is real, but the alternative was losing all of them.

Apps, offline reading and getting articles back out

The Android app (on F-Droid and Google Play) and the iOS app both sync the article list for offline reading, which is the whole point of read-it-later on a commute, and there are extensions for Firefox and Chrome plus a bookmarklet for everything else. Tagging and annotations live in the web app and the mobile apps. Every article exports to ePub, PDF, MOBI, plain text, CSV, JSON and HTML, and the full account exports as JSON, so the reading list stays yours in a way Pocket users learned the hard way. The API is what the apps use, so anything you script gets the same access.

wallabag against linkding and Readeck

Two neighbours are worth naming. linkding is a bookmark manager: it stores the link, the title and tags in a fraction of the memory and does not try to save the article body for later reading, so it is the pick if what you want is a searchable list of URLs. Readeck is the newer read-it-later tool, a single Go binary with a lighter footprint and a pleasant reader, which makes it the strongest competitor on a small box. wallabag's advantages are 13 years of maturity, the mobile apps, the import breadth and the annotation features; its cost is the PHP stack and the memory. If you read articles rather than merely file links, it is wallabag or Readeck, and wallabag still has the deeper ecosystem.

What I'd do

wallabag with Postgres, DOMAIN_NAME set to the exact public URL before the first start, registration off, the mobile app installed, and a weekly pg_dump shipped off the box. Import the Pocket export once, tag the articles worth keeping, and delete the rest without guilt. Pair it with FreshRSS so the save-for-later button in your feed reader lands here, and you have replaced both halves of the reading pipeline that keep getting shut down.