Introduction
If you read a lot of articles online, you've probably had the same problem a hundred times: you find something worth reading, you don't have time right now, and by the time you go looking for it again it's gone, paywalled, or buried in forty open browser tabs. Pocket shut down its service to new users a while back, and a lot of people went looking for something they could run themselves. Wallabag is that something.
This tutorial walks you through installing Wallabag on Proxmox VE 9.2, using the community-maintained install script that most homelab users rely on for this kind of app. You don't need any PHP or MariaDB experience. You just need a Proxmox host and about fifteen minutes.
What You'll Learn
- What Wallabag actually does and why people choose it over browser bookmarks
- How to spin up a Wallabag LXC container using the Proxmox VE community script
- Where the config file and credentials live once it's running
- How to log in for the first time and immediately fix the default password
- What to do when the container won't start or the web page won't load
What Is Wallabag?
Wallabag is a self-hosted "read it later" app. You install a browser extension or use the mobile app, and whenever you find an article you want to read, you save it to your own Wallabag server instead of a third-party company's servers. It strips out ads and clutter, keeps a clean readable copy (even if the original page later disappears), and lets you tag, search, and organize everything you've saved.
It's written in PHP, stores its data in a MariaDB database, and uses Redis for caching. None of that matters much for day-to-day use — the community script handles all of it — but it's worth knowing because it explains why the container needs a bit more RAM than something like Pi-hole or a barebones text app.
Under the hood it runs on an LXC container, which is Proxmox's version of a lightweight Linux container. Unlike a full virtual machine, an LXC container shares the host's kernel instead of running its own, so it starts in a second or two and uses a fraction of the RAM and disk a VM would need for the same job. That's exactly the kind of workload Wallabag is: a small web app that doesn't need its own virtualized hardware.
Why Run Wallabag on Proxmox VE?
You could install Wallabag directly on your desktop, but then it's tied to a machine you turn off at night. Running it in a Proxmox LXC container means it lives on a host that's always on, gets its own IP address, and doesn't compete with anything else for resources beyond what you allocate to it.
It's also disposable in the good sense. If you mess something up during setup, you delete the container and run the script again — you're back to a clean install in under two minutes. Try doing that with a service installed straight onto your daily-driver laptop.
And honestly, once you've got Pi-hole, Nginx Proxy Manager, or Jellyfin running in their own containers on the same host, adding Wallabag is barely any extra effort. That's the appeal of the LXC-per-service pattern that most Proxmox homelabs end up using.
Prerequisites
Before you start, make sure you have:
- A working Proxmox VE host — this guide was tested on 9.2, but 8.x works the same way
- At least 6 GB of free disk space and 2 GB of free RAM on the node you're deploying to
- Root or an admin-level login to the Proxmox web interface
- Internet access from the Proxmox host, since the script downloads packages during install
- A few minutes where the container isn't going to be interrupted mid-install
You don't need to create the container manually first. The script does that part for you, which is really the whole point of using it.
Step-by-Step Tutorial
Step 1: Open the Proxmox Shell
Log in to the Proxmox web interface, click on your node in the left-hand tree (not a specific VM or container — the node itself), and click >_ Shell near the top right. This gives you a root terminal running directly on the Proxmox host.
Step 2: Run the Wallabag Install Script
Paste this command into the shell and press Enter:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/wallabag.sh)"This pulls the install script from the community-scripts project's GitHub repository and runs it. You'll see a text-based menu appear asking whether you want the default settings or advanced settings.
Step 3: Pick Default or Advanced Settings
For a first install, choose the default option. It creates the container with these specs:
| Setting | Default Value |
|---|---|
| OS Template | Debian 13 |
| CPU Cores | 2 |
| RAM | 2048 MB |
| Disk Size | 6 GB |
| Networking | DHCP on vmbr0 |
If you're running this on a node that's already tight on resources, pick Advanced instead and lower the RAM to 1024 MB — Wallabag will run, just a little slower under load. I wouldn't go below that; PHP-FPM and Redis both want their own headroom.
Step 4: Let the Script Finish
The script now creates the container, installs Debian 13, then installs and configures nginx, PHP 8.3-FPM, Redis, MariaDB, and finally Wallabag itself on top of all of it. This takes somewhere between five and ten minutes depending on your internet connection and how fast the node's storage is. You'll see a wall of package-manager output — that's normal, let it run.
When it's done, the script prints the container's IP address and the ports Wallabag is listening on. Write that IP down.
Step 5: Open Wallabag in Your Browser
Go to http://<container-ip>:8000 in your browser. You should see the Wallabag login screen. Port 8000 is the default HTTP port the script configures nginx to listen on for this app.
Step 6: Log In and Change the Default Password
The default install creates one admin account: username wallabag, password wallabag. Log in with that, then go to your profile settings inside Wallabag and change the password immediately. Leaving the default credentials in place on anything reachable outside your own network is asking for trouble.
If you'd rather do it from the command line instead of the web UI, jump ahead to the Commands Explained section below.
Step 7: Install the Browser Extension or Mobile App
Wallabag has official extensions for Firefox and Chrome, plus apps for Android and iOS. Point any of them at your container's URL and the same login you just set up. That's what actually makes it useful day to day — most people don't visit the web UI directly very often once the "save to Wallabag" button is one click away in their browser.
Commands Explained
A short breakdown of what you actually typed, and a couple of useful follow-ups:
| Command | What It Does |
|---|---|
curl -fsSL <url> | Downloads the install script quietly (-s), fails loudly on a bad HTTP response (-f), and follows redirects (-L) instead of silently ignoring them. |
bash -c "$(...)" | Takes whatever curl downloaded and runs it immediately as a bash script, without saving a copy to disk first. |
pct enter <vmid> | Run this from the Proxmox host shell to get a root prompt inside the container itself, useful once you need to poke around beyond what the web UI shows. |
php bin/console fos:user:change-password wallabag <newpassword> | Run inside the container from /opt/wallabag to reset the admin password from the command line instead of the web UI — handy if you're locked out. |
systemctl status nginx php8.3-fpm redis-server mariadb | Checks whether the four services Wallabag depends on are actually running. If Wallabag won't load, this is the first thing to check. |
You don't need to memorize any of this before you install. It's here for when something doesn't work and you need to go digging.
Common Errors
"Connection refused" when loading the container's IP on port 8000. Either the container is still finishing its install, or nginx failed to start. Give it another minute, then check the service status from inside the container.
Script exits early with a package download failure. Almost always a DNS or internet connectivity problem on the Proxmox host or the container's network bridge, not a problem with the script itself. Confirm the container can reach the internet: pct exec <vmid> -- ping -c3 1.1.1.1.
Blank white page instead of the login screen. This is usually a PHP error being swallowed silently. It almost always means PHP-FPM isn't running, or the container ran out of disk space mid-install and left the app half-configured.
"Invalid credentials" even though you're sure the password is right. Caps lock is the boring answer nine times out of ten. The less boring answer is that you're logging into the wrong port or a leftover container from a previous attempt.
Troubleshooting
Start from the Proxmox host shell, not inside the container, so you're not fighting a broken login to debug a broken login.
First, confirm the container is actually running:
pct status <vmid>If it shows stopped, start it with pct start <vmid> and check the Proxmox task log for errors during boot.
If it's running but the web page won't load, drop into the container and check the services one at a time:
pct enter <vmid>
systemctl status nginx
systemctl status php8.3-fpm
systemctl status redis-server
systemctl status mariadbAny of these showing failed is your answer. journalctl -xeu <service-name> will usually tell you exactly why — a common one is MariaDB failing to start because the container ran low on disk during the initial database setup.
If the config genuinely got corrupted and you're not sure what's salvageable, it's often faster to delete the container from the Proxmox web UI and re-run the install script than to hand-fix a half-broken PHP config. That's one of the real advantages of the script-based install — starting over costs you ten minutes, not an afternoon.
Best Practices
Change the default password before you do anything else. This one's not optional if the container is reachable from outside your LAN.
Put Wallabag behind a reverse proxy with HTTPS if you're going to access it remotely — plain HTTP on port 8000 over the open internet is not something you want. If you've already got Nginx Proxy Manager or Traefik running elsewhere in your homelab, point a subdomain at this container instead of exposing port 8000 directly.
Take a Proxmox backup of the container after the initial setup, and again periodically after that. A vzdump backup captures the whole container — OS, database, and saved articles — in one shot, which is a lot less fiddly than trying to export just the MariaDB database by hand.
Give it real RAM if you're a heavy user. 2048 MB is fine for saving a few articles a week. If you're importing years of Pocket exports or running Wallabag for a household of readers, bump it to 4096 MB — PHP-FPM under load benefits more from RAM than from extra CPU cores.
Set up the browser extension on every device you actually read on. A self-hosted read-it-later app you only access through the web UI once a month isn't really solving the problem it's meant to solve.
Frequently Asked Questions
Does Wallabag work without an internet connection?
Once an article is saved, yes — Wallabag stores a full local copy, not just a link. You can read saved articles even if the original site goes offline.
Can I import my existing Pocket or Instapaper account?
Yes. Wallabag has a built-in import tool under Settings that accepts exports from Pocket, Instapaper, Readability, and a few other services.
Do I need a domain name to use this?
No. The container's local IP address and port 8000 work fine on your home network. A domain only matters if you want to access it from outside your LAN with a proper HTTPS certificate.
How much disk space will I actually need long-term?
The 6 GB default is enough for a few thousand saved articles with images. If you're a very heavy saver, resizing the container's disk later with pct resize takes about thirty seconds.
Is this the same as the official Wallabag Docker image?
No, this uses a native Debian install inside the LXC container rather than Docker. Functionally it behaves the same way, but there's no Docker daemon overhead sitting between you and the app.
Conclusion
Fifteen minutes and one command gets you a working, ad-free, self-hosted place to save everything you're too busy to read right now. The community script does the boring parts — Debian, nginx, PHP, MariaDB, Redis — so the only real decision you're making is how much RAM to give it.
Change that default password, hook up the browser extension, and you've got one less thing depending on a company that might shut down its free tier next year. That's really the whole pitch for self-hosting something like this.