- C++ 54.2%
- CMake 18.4%
- PHP 9.8%
- Shell 8.1%
- CSS 5.1%
- Other 4.4%
| actions | ||
| alpine | ||
| cmake | ||
| data | ||
| debian | ||
| desktop | ||
| fedora_rpm | ||
| gentoo/app-antivirus/bastionguard | ||
| locale | ||
| mageia | ||
| openmandriva | ||
| opensuse_leap16 | ||
| opensuse_rpm | ||
| pkgbuild | ||
| src | ||
| thirdparty | ||
| webui | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| GOVERNANCE.md | ||
| LICENSE | ||
| PROJECT_MANIFEST.md | ||
| README.md | ||
| ROADMAP.md | ||
| sanitize_po_keep_last.py | ||
| SECURITY.md | ||
| TRADEMARK.md | ||
BastionGuard
BastionGuard is a Linux security platform designed for users who want deterministic behavior, explicit policies, and visible decisions — not opaque “trust us” protection.
Release Status
BastionGuard 2.0 was officially released on July 15, 2026.
Version 2.0 is the current stable, production-ready release. It builds on the original 1.0 release of February 27, 2026 and follows extensive development, production use, and testing.
Official Linux Repositories
BastionGuard is available through official Linux package repositories for the supported distributions.
Repository configuration instructions and distribution-specific installation commands are available at:
This page explains how to add the official BastionGuard repository and install or update the application using the native package manager of each supported Linux distribution.
Build and Installation
Detailed instructions for compiling and installing BastionGuard are available in the official documentation:
https://bastionguard.eu/documentation/
See the section:
BastionGuard – Technical Documentation – Application Install
When compiling BastionGuard from source, use the CMake configuration prepared for your Linux distribution. Each configuration includes distribution-specific dependency handling, packaging policies, CEF options, paths, and compatibility adjustments.
BastionGuard supports the following CMake init-system values:
AUTO
SYSTEMD
OPENRC
SYSVINIT
DINIT
AUTO detects the active init system during CMake configuration.
For reproducible distribution packages, an explicit init system should be selected instead of AUTO.
Example:
cmake -S . -B build \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_INSTALL_SYSCONFDIR=/etc \
-DBG_PACKAGING=ON \
-DBG_DEBIAN_NO_INSTALL_CODE=ON \
-DENABLE_SYSTEMD_SERVICES=OFF \
-DENABLE_USER_AGENT_AUTO=OFF \
-DINSTALL_NGINX_DEFAULTS=OFF \
-DBASTIONGUARD_INIT_SYSTEM=OPENRC
Supported explicit values are:
SYSTEMD
OPENRC
SYSVINIT
DINIT
Use a separate build directory for each init-system configuration.
Supported Init Systems
BastionGuard provides native service integration for:
- systemd
- OpenRC
- SysVinit
- Dinit
Only the service definitions for the selected init system are installed.
The build system also makes libsystemd optional where possible, allowing BastionGuard to be built on distributions that do not use systemd.
The Secure Connection service uses the canonical service name:
bsc-daemon
Supported Distributions
BastionGuard officially supports the following Linux distributions:
- Debian
- Ubuntu
- Fedora
- Arch Linux
- openSUSE
- OpenMandriva Lx
- Mageia 10
- Gentoo Linux
- Alpine Linux
Distribution-specific CMake files are provided where required.
Gentoo Linux
Gentoo packaging is provided through an EAPI 8 ebuild.
The ebuild supports init-system selection through USE flags:
systemd
sysvinit
dinit
When none of these flags is selected, OpenRC is used.
Optional build features include:
cef
secure-connection
Alpine Linux
Alpine Linux packaging is provided through an APKBUILD.
The Alpine package uses OpenRC:
BASTIONGUARD_INIT_SYSTEM=OPENRC
The precompiled embedded CEF runtime is disabled in the Alpine package because Alpine uses musl libc and the bundled CEF runtime is not treated as a native musl-compatible component.
The rest of BastionGuard, including supported native services and Secure Connection, is built using Alpine-compatible dependencies.
Packaging
BastionGuard includes or supports packaging configurations for:
- Debian and Ubuntu packages
- RPM-based distributions
- Arch Linux packages
- Gentoo ebuilds
- Alpine APKBUILD packages
Packaging builds should use:
BG_PACKAGING=ON
BG_DEBIAN_NO_INSTALL_CODE=ON
ENABLE_SYSTEMD_SERVICES=OFF
ENABLE_USER_AGENT_AUTO=OFF
INSTALL_NGINX_DEFAULTS=OFF
These options prevent the build process from starting services, restarting system components, modifying user sessions, or performing privileged installation actions on the build host.
Package installation should be staged with DESTDIR.
Example:
DESTDIR="$PWD/pkg" cmake --install build
Development and Release Process
BastionGuard is used in production and is therefore developed with a stability-first approach.
Development changes are tested extensively before being published. Commits are pushed to the public repository only when the corresponding functionality is complete, operational, and considered stable enough for release.
The main branch is not used to publish intentionally broken, incomplete, or untested development snapshots. Repository activity may therefore be less frequent than in projects that expose every intermediate development step.
This release model prioritizes reliability, deterministic behavior, compatibility, and production safety.
License
This project is licensed under the GNU General Public License version 3.
See the LICENSE file for details.
Trademark
“BastionGuard” and related branding are protected.
See TRADEMARK.md for details.
Issue Tracking
This project does not use the built-in Forgejo issue tracker.
Please report bugs and feature requests at:
https://bastionguard.eu/issues