Thank you so much for the information. The fact that it's only compatible with your own VPN containers is certainly useful, and it would probably be wise to disclose that information straight in the variable's description. Maybe like this:

 

Specify whether this container is sharing the network with another VPN container -> Specify whether this container is sharing the network with another binhex VPN container

 

I was hoping you could go a little bit more into the technical details of the implementation, though. Gluetun, like most VPN containers, offers a (configurable) health server that could be used to achieve similar results, for example. So maybe some more flexibility isn't completely out of the question.

 

Does https://supervisord.org do the cross-container health check, or how is it done?

I set this up without conifg.yml and classifier.yml and ended up with a few thousand torrents in categories that I didn't want. I editing /config/postgres/data/pg_hba.conf and posgresql.conf to be available on my local network so I could edit it with pgAdmin. No matter what I did, I couldn't get it to be accessible from the network.

Finally worked it out. Go in to the binhex-bitmagenet console cd to /home/nobody and edit the start.sh file.

Change

postgres_host='127.0.0.1'

to

postgres_host='*'

Of course, this will get reverted on the next update, but at least I can edit the tables.

Oh, I also could have done it via command line with su - nobody and psql but I wanted to browse through the tables first.

Hope this helps anyone who might want to do the same. Otherwise, you can delete them 100 at a time from the GUI. Its probably not worth suggesting a permanent workaround in the Unraid Docker Edit menu.

Thanks to binhex for all the great dockers!

Hi everyone,

I'm trying to access the web GUI of the Bitmagnet container that's using the same network as my VPN container. The VPN container is set to forward the the bitmagnet ports (3333->3334 & 3344->3345). As reference, Sonarr works fine in this setup. However, Bitmagnet gives me an ERR_CONNECTION_REFUSED when I try to access its web interface.

I've already set the network mode to container:<vpn-container> for Bitmagnet. Is there anything else I need to configure to make the web GUI accessible?

Any guidance would be appreciated!

Edited September 11, 2025Sep 11 by Frickadillen

Set the LAN_NETWORK variable correctly?

35 minutes ago, Kilrah said:

Set the LAN_NETWORK variable correctly?

Thanks for the quick reply Kilrah! The VPN container has LAN_NETWORK set and I assume it is correct as sonarr is working.

14 minutes ago, Frickadillen said:

Thanks for the quick reply Kilrah! The VPN container has LAN_NETWORK set and I assume it is correct as sonarr is working.

Got it working now. Seems that the bitmagnet container cant be reached if the vpn container is restored. Bott order, first the vpn container and then bitmagnet container.

Do I need to open torrent nat ports or anything?

Edited November 17, 2025Nov 17 by silajim

13 hours ago, silajim said:

Do I need to open torrent nat ports or anything?

no incoming port is required.

What's with the new database backup that gets enabled by default on existing installs with no heads up? Just spent an hour figuring out why all hell broke loose on my system and fixing a pool that was thrown offline due to it. My pool bitmagnet data is stored on can't just take 7 days of full DB backups on a whim.

On 12/23/2025 at 1:14 PM, Kilrah said:

What's with the new database backup that gets enabled by default on existing installs with no heads up? Just spent an hour figuring out why all hell broke loose on my system and fixing a pool that was thrown offline due to it. My pool bitmagnet data is stored on can't just take 7 days of full DB backups on a whim.

Apologies if it caused issues, i was in two minds as to whether to turn on backups by default, but as i had first hand experience of db corruption, along with other people in this thread i decided to err on the side of caution and turn it on. I am a bit surprised it knocked your pool out though, i am seeing db backup size of around 1.5GB for 2.5 Millions torrents, is your db backup significantly bigger than this?.

10 hours ago, binhex said:

is your db backup significantly bigger than this?.

Yup, been running with no filter since this was released, so ~23M torrents / ~140GB DB.

It's stored on a compressed zfs volume on a 250GB drive and takes about 60GB, I nuked the backup folder before looking at how much the backups were taking.

I'm already taking care of backups with the Appdata Backup plugin like for everything else and the backups go to another pool so this ended up bloating both since now the appdata backups included not only the DB but the built-in backups.

Edited December 25, 2025Dec 25 by Kilrah

Hi,
Just noticed the same, since last version automatic backup are enabled by default literally eating up my disk space.
And i didn't find any way to disable it.

My DB also is without filters and amounts for about 23.000.000 items (postgres folder is 156Gb at the moment).
You can imagine what happens when it starts making backups daily....

:-/

Edited December 25, 2025Dec 25 by dhstsw

8 hours ago, dhstsw said:

And i didn't find any way to disable it.

Add those. Or update the whole template where they've been added

13 hours ago, Kilrah said:

Add those. Or update the whole template where they've been added

Not in my template.
I guess template was update since i first installed it.
I'll check it out.

thx.

FYI i have reversed the defaults for POSTGRES_BACKUP_DB and POSTGRES_SCHEDULED_BACKUP, both are now set to 'false', so if not defined backups will be off.

23 minutes ago, binhex said:

FYI i have reversed the defaults for POSTGRES_BACKUP_DB and POSTGRES_SCHEDULED_BACKUP, both are now set to 'false', so if not defined backups will be off.

Is there a variable to limit how many backups are retained? I think they’re a good idea but don’t need to keep an infinite number. Checked GitHub but don’t see any of these variables listed there.

That's far more sensible.

My DB is filtered and "only" a bit under 100gb in size, and db backups compress well below 10gb - so things were a bit more uncomfortable, but quite manageable.

I pulled the new template and I found the POSTGRES_VACUUM_DB variable flag and set it to true, figuring that a full vacuum couldn't really hurt - I can live with the db being offline for a while.

Boy was I wrong, either because of a panic loop or because of a health check restarting the container, the DB from under 100gb in size to well above 1600Gb. Which is quite an impressive feat on a 1TB cache drive - rarely have I been more thankful for ZFS compression.

While I managed to cancel the vacuuming (gently), it didn't reclaim the space and my attempts at deleting only orphaned tables weren't successful - I'm restoring from backup while I'm writing this.

I found no documentation on the new variables and their use. Clearly they aren't as safe as I would have hoped. Would you be able to give some better documentation?

21 minutes ago, wgstarks said:

Is there a variable to limit how many backups are retained?

Yes, there is another env var to control this:
Container Variable: POSTGRES_BACKUP_RETENTION_DAYS
Number of days to retain database backups. Older backups will be automatically deleted.

All env vars are visible in the latest template, so if you are unsure what it is available then go to CA, search for bitmagnet and 'install' (but cancel out if you don't want a new container creating), this will show you all env vars (ensure you click on 'show more settings...').

8 minutes ago, binhex said:

All env vars are visible in the latest template, so if you are unsure what it is available then go to CA, search for bitmagnet and 'install' (but cancel out if you don't want a new container creating), this will show you all env vars (ensure you click on 'show more settings...').

Neat trick.👍

I see that many variables have been added. Is there a way to update my template without losing my current db? I know I can manually add the variables but really didn’t want to have to type out all the descriptions.

20 minutes ago, csb said:

Boy was I wrong, either because of a panic loop or because of a health check restarting the container, the DB from under 100gb in size to well above 1600Gb. Which is quite an impressive feat on a 1TB cache drive - rarely have I been more thankful for ZFS compression.

I'm sorry to hear you had a rough time with this, it SHOULD work correctly, i will do some investigation into this and try running a vacuum myself, it is entirely possible the database has to be fully dumped out, re-arranged and then imported back in so it maybe that what you saw is normal behaviour and it just takes a very long time (and lots of space!).

16 minutes ago, csb said:

either because of a panic loop or because of a health check restarting the container

A unhealthly container will NOT restart unless you set the HEALTHCHECK_ACTION to be 'kill 1', by default that is not set and it will simply be marked as unhealthly awaiting the action from the user, so going unhealthly should not be the cause.

This is the code that performs the vacuum: https://github.com/binhex/arch-bitmagnet/blob/14ecd5d440b235f40a4ca17ff86abec4aea3e011/run/nobody/start.sh#L232

As to what that a vacuum does i can point you at the official documentation: https://www.postgresql.org/docs/current/sql-vacuum.html

Just now, wgstarks said:

Is there a way to update my template without losing my current db?

I really wish there was, but sadly there is no slick way to do this, you could look at the template and then copy in the missing env vars into your existing user template on your flash drive, but that is not the most easiest operation. Really your options are manually add them in, or stop the old container, make a note of your settings and then create from CA and replace with your settings from the old template, then finally delete the old template.

34 minutes ago, binhex said:

i will do some investigation into this and try running a vacuum myself

duplicated my postgres directory in case of issues and ran vacuum on it (by setting the env var ) and it took around 10 minutes and finished successfully for me, here is a snipet of what i see in my log:

2025-12-27 14:28:44,192 DEBG 'start' stderr output:

2025-12-27 14:28:44.192 GMT [402] LOG: checkpoint complete: wrote 8355 buffers (51.0%); 0 WAL file(s) added, 1 removed, 32 recycled; write=5.614 s, sync=0.094 s, total=5.885 s; sync files=5, longest=0.029 s, average=0.019 s; distance=540652 kB, estimate=543696 kB; lsn=1C1/3D400280, redo lsn=1C1/1E3FED20

2025-12-27 14:28:44.192 GMT [402] LOG: checkpoints are occurring too frequently (6 seconds apart)

2025-12-27 14:28:44.192 GMT [402] HINT: Consider increasing the configuration parameter "max_wal_size".

2025-12-27 14:28:44.192 GMT [402] LOG: checkpoint starting: wal

2025-12-27 14:30:00,540 DEBG 'start' stderr output:

2025-12-27 14:30:00.540 GMT [402] LOG: checkpoint complete: wrote 3520 buffers (21.5%); 0 WAL file(s) added, 0 removed, 33 recycled; write=76.104 s, sync=0.167 s, total=76.349 s; sync files=22, longest=0.165 s, average=0.008 s; distance=544701 kB, estimate=544701 kB; lsn=1C1/58E8E438, redo lsn=1C1/3F7EE510

2025-12-27 14:30:15,915 DEBG 'start' stderr output:

2025-12-27 14:30:15.915 GMT [402] LOG: checkpoint starting: wal

2025-12-27 14:30:22,463 DEBG 'start' stderr output:

2025-12-27 14:30:22.463 GMT [402] LOG: checkpoint complete: wrote 1011 buffers (6.2%); 0 WAL file(s) added, 0 removed, 33 recycled; write=6.394 s, sync=0.077 s, total=6.549 s; sync files=6, longest=0.047 s, average=0.013 s; distance=536757 kB, estimate=543907 kB; lsn=1C1/7ECAADE8, redo lsn=1C1/6041BB30

2025-12-27 14:30:24,821 DEBG 'start' stderr output:

2025-12-27 14:30:24.821 GMT [402] LOG: checkpoints are occurring too frequently (9 seconds apart)

2025-12-27 14:30:24.821 GMT [402] HINT: Consider increasing the configuration parameter "max_wal_size".

2025-12-27 14:30:24.821 GMT [402] LOG: checkpoint starting: wal

2025-12-27 14:30:28,905 DEBG 'start' stdout output:

VACUUM

2025-12-27 14:30:28,906 DEBG 'start' stdout output:

[info] FULL VACUUM completed successfully

It did has some effect, disk space cosumed for the postgres directory went from 23GB to 20GB after the vacuum.

38 minutes ago, binhex said:

A unhealthly container will NOT restart unless you set the HEALTHCHECK_ACTION to be 'kill 1', by default that is not set and it will simply be marked as unhealthly awaiting the action from the user, so going unhealthly should not be the cause.

Does it mark the container as unhealthy? If so, autoheal might have been the culprit.

It's still restoring from backup, I'm not seeing anything to worry about at the moment though.

I'm getting a bunch of

2025-12-27 15:37:14.782 CET [1049] LOG: skipping vacuum of "torrent_contents" --- lock not available

2025-12-27 15:37:14.782 CET [1049] LOG: skipping vacuum of "torrent_files" --- lock not available

and in the beginning it threw the usual:

2025-12-27 14:45:07.413 CET [399] LOG: checkpoints are occurring too frequently (8 seconds apart)

2025-12-27 14:45:07.413 CET [399] HINT: Consider increasing the configuration parameter "max_wal_size".

2025-12-27 14:45:07.413 CET [399] LOG: checkpoint starting: wal

Other than that, all appears well so far.

43 minutes ago, binhex said:

I really wish there was, but sadly there is no slick way to do this, you could look at the template and then copy in the missing env vars into your existing user template on your flash drive, but that is not the most easiest operation. Really your options are manually add them in, or stop the old container, make a note of your settings and then create from CA and replace with your settings from the old template, then finally delete the old template.

I mean, if you trust your backups, and want to do it as simple as possible:

Open your current container settings in a tab and leave it open (maybe make a screenshot just in case).

"Remove" the existing container (it won't delete anything in appdata)

Reinstall from CA with the same name, copy and paste the modified settings from the open tab.

Close the open tab.

It should come right back up without data loss.

6 minutes ago, csb said:

Does it mark the container as unhealthy? If so, autoheal might have been the culprit.

It most probably will do, yes, because bitmagnet process will not be present, i should be able to add some code in to pass a flag to the healthcheck script i wrote to turn off healthchecking if a vacuum/reindex/backup/restore process is in operation.

p.s. I was not aware of the docker image autoheal.