On the other day I was messing with my MiniFlux selfhosted instance, and I pressed the clear history option (don’t do that if you want to keep all the unread articles).
I’ve learned 2 things with this action:
- First, I need a better backup routine.
- And second, the entries table, keeps the entries with the status ‘removed’. Fact that I learned after checking the database myself.
In my current setup, I have a server running docker. And a compose file for my Miniflux instalation:
services:
miniflux:
image: miniflux/miniflux:latest
ports:
- "{miniflux_port}:8080"
depends_on:
db:
condition: service_healthy
environment:
- DATABASE_URL=postgres://{postgres_user}:{postgres_password}@db/miniflux?sslmode=disable
- BASE_URL={miniflux_base_url}
- RUN_MIGRATIONS=1
- CREATE_ADMIN=1
- ADMIN_USERNAME={miniflux_admin_username}
- ADMIN_PASSWORD={miniflux_admin_password}
db:
image: postgres:15
environment:
- POSTGRES_USER={postgres_user}
- POSTGRES_PASSWORD={postgres_password}
volumes:
- {host_volume}:/var/lib/postgresql/data
healthcheck:
test: ["CMD", "pg_isready", "-U", "miniflux"]
interval: 10s
start_period: 30s
For me, the fastest solution I’ve found to see the postgres content was to add another service to the compose file. Here comes Adminer.
services:
...
adminer:
image: adminer
restart: always
depends_on:
- db
ports:
- {adminer_port}:8080
...
Adminer is a simple web ui to manage databases.
I did my thing, changed some records and then I changed again my compose file to remove Adminer. Not that I don’t like the tool, it’s realy fast and easy to use. But I don’t need to keep it running after fixing my issue. It’s a container. I can instantiate it when I need it, and then, puff! There goes the bits.