Configuration

Configuration

Languages: English | Français

This page gathers the practical configuration details that used to be scattered between the CLI page, examples, and release notes.

Where ngPost stores configuration

Since v5.4.0, ngPost uses a per-user application configuration directory:

Platform	Default config file
Linux	$XDG_CONFIG_HOME/ngPost/ngPost.conf or ~/.config/ngPost/ngPost.conf
Windows	%LOCALAPPDATA%\ngPost\ngPost.conf
macOS	~/Library/Application Support/ngPost/ngPost.conf

You can still use a specific file for one run:

ngPost -c /path/to/ngPost.conf

Migration from legacy paths (v5.4)

Older versions used different locations:

Platform	Legacy path
Linux/macOS	~/.ngPost
Windows	ngPost.conf next to the executable

On first launch, if a legacy config exists and the new config file does not, ngPost copies the legacy file to the new location and keeps the original file in place. This lets v5.4+ use the new layout without breaking older installs.

Stable folder name and adoption (from version 5.5)

Before version 5.5, the last directory segment could still be derived from the program file name. Renaming an executable or installing/updating a renamed AppImage could therefore create a second configuration folder and make settings or history appear to have disappeared. From version 5.5, the segment is always exactly ngPost, using the paths in the table above.

On the first normal start, when the canonical folder has no configuration or history, ngPost can adopt one older name-derived folder:

• ngPost.conf, GUI settings, post-info models and persistent VPN profiles are copied atomically, without overwriting existing files;
• symbolic links, special files, backups and temporary VPN secrets are left untouched;
• the SQLite database and its WAL/SHM files are never copied or moved. An existing POST_DB is preserved; if an old default database exists but the config had no usable POST_DB, the adopted config points back to that exact old database;
• the old configuration file still reads the same settings with -c, but it no longer records its posts in the same database — see the note below. When that folder is writable, a snapshot is written as ngPost.conf.save, or a timestamped .save variant when necessary;
• if several old folders exist, one is selected and the others are reported and left untouched.

A completed adoption or recorded decision writes .ngPost_config_migration, making the decision one-shot. A failed adoption does not start ngPost on a new empty history: it stops safely and retries on a later launch. --help, --version and invalid syntax do not create or migrate the folder. Supplying -c bypasses this automatic adoption; relative models and VPN profiles continue to resolve from the explicitly selected config folder.

A script that keeps pointing at the old file

Adoption copies, it never moves, so a cron job passing -c <old folder>/ngPost.conf keeps working — same servers, same options. One thing does change: that old file has no POST_DB line, so it falls back to the default database, which is now the one in the new folder, while the adopted configuration points at the database left in the old one. Nothing is lost, but the history quietly ends up in two files.

ngPost says so when it adopts the folder, and again on every run that passes that exact file, naming both databases. Two ways out, either is enough:

• point the script at the new ngPost.conf; or
• add a POST_DB = <path to the old database> line to the old file.

A configuration that already chooses its own POST_DB, and any file outside the adopted folder, are never concerned.

Related files in the config directory

The same directory is also used for per-user ngPost data:

• ngPost.conf: main configuration file.
• ngPost_history.sqlite: default structured SQLite post history database.
• vpn/: imported OpenVPN/WireGuard profile files.
• vpn/runtime/: short-lived VPN authentication files while a VPN connection is active.

Checking for a new version

CHECK_FOR_UPDATES is on by default: ngPost asks GitHub once a day whether a newer release exists. It stays on the channel your build belongs to.

• A stable build is only ever offered another stable release. An unstable build published in the meantime is ignored, so nothing pulls you onto a test version by accident.
• An unstable build follows the unstable channel, and also accepts the stable release it leads to: 5.5-unstable is superseded by a later 5.5-unstable, and by 5.5 when it comes out.

AppImage users are the exception: the check is skipped entirely, because an AppImage carries its own zsync update information and is updated by the tool that installed it.

Set CHECK_FOR_UPDATES = false, or untick the box in the preferences, and ngPost never contacts GitHub.

History database

POST_HISTORY was the old CSV history file. Since v5.4.0, the main history is a SQLite database.

POST_DB = /path/to/ngPost_history.sqlite
HISTORY_STORE_PASSWORDS = true

Use POST_DB to move the database somewhere else. Existing CSV history can be imported from the CLI:

ngPost --history_import_csv /path/to/POST_HISTORY.csv

See History and resume for the full workflow.

Common configuration keys

Key	Purpose
nzbPath	Default folder for generated NZB files.
GROUPS	Newsgroups used for posting.
GROUP_POLICY	How posts are distributed when several groups are configured.
FROM / GEN_FROM	Fixed or generated poster email.
POST_DB	Structured SQLite history database path.
RAR_PATH, PAR2_PATH	External tool paths when bundled tools are not used.
VPN_AUTO_CONNECT	Automatically start/stop the configured VPN profile when needed.
POST_INFO_TEMPLATE	Model used to write a post info file after each post.

Post info files

From version 5.5 on.

ngPost can write a small text file next to each NZB, describing the post: name, size, archive name, plus your own title, portal link or category. Some Usenet indexes ask for such a file.

It knows no index format: you provide the model, it fills in the blanks. The feature is off until POST_INFO_TEMPLATE is set.

See Post info files for the step by step guide.

For every CLI switch and automation option, see Command line usage.

For the complete configuration-file reference, including all supported keys and examples, see ngPost.conf reference.