Saphira Linux databaseDragon

Relational databases on infrastructure you control: choose SQLite, MariaDB or PostgreSQL, understand the access you need, and keep your data where it belongs.

In testing, functionality present — helpers missing

Expose the service, not the whole world

Saphira uses nftables. When a remote application host needs a database, the network policy may need a rule allowing that approved host or network to reach the relevant database service. The useful intention is not “open the MariaDB port”; it is “allow this application host to reach this database service.”

Inspect and extend the machine's existing nftables ruleset. Do not flush, replace or redesign it merely to add database access. The service port, public interface, client address and permitted protocol are all part of the specific rule, and they should reflect your application design.

# Inspect the existing rules before changing anything
nft list ruleset

# Conceptual rule shape — adapt it to your existing table and chain.
# Permit only the approved IPv4 application host to reach MariaDB.
ip saddr 192.0.2.25 tcp dport 3306 accept

# An IPv6 client is a separate, equally ordinary case.
ip6 saddr 2001:db8:100::25 tcp dport 3306 accept

NoteThe documentation addresses above are examples, not rules to paste unchanged. PostgreSQL conventionally uses TCP 5432; use the service, hosts and existing nftables structure that actually apply to your server.

Two layers, one intention

Network permission lets an approved host reach the database service. Database permission lets the approved user from that host work with the intended database and privileges. Neither layer replaces the other. Keeping them aligned makes remote access understandable and easy to review.