Self-hosted Applications Overview

This document catalogs a curated list of self-hosted applications along with their storage characteristics and alternatives for database-heavy apps.

Self-hosted Apps

These are self-hosted apps with varying storage backends. Most support SQLite or offer file-based alternatives.

App	SQLite Support	S3 Support	Needs Local File Storage?	Alternative(s)
Actual Budget	Yes (`.sqlite` by default)	No	Yes	N/A
Beszel	Yes – uses PocketBase (SQLite)	Yes – automatic backups to S3-compatible storage	Yes	N/A
Gitea	Yes – SQLite option	Optional (via LFS/backups)	Yes	N/A
Grist	Yes (`.grist` files are SQLite)	No	Yes	N/A
Linkding	Yes – default SQLite DB	No	Yes	N/A
Immich	No – SQLite unsupported	Yes – object-storage backend	Yes	PhotoPrism
Jellyfin	Yes (SQLite or MySQL/MariaDB)	No	Yes	N/A
Mealie	Yes – supports SQLite	No	Yes	N/A
Miniflux	v1: Yes; v2: PostgreSQL-only	No	Yes	FreshRSS
Nextcloud	Yes (SQLite, MySQL, PostgreSQL)	Yes – external S3 storage	Yes	N/A
Outline	No (Postgres-only)	Optional (cloud uploads)	Yes	DokuWiki
paperless-ngx	Yes (SQLite default)	Optional S3 for document storage	Yes	N/A
Pingvin Share	Unknown	Yes – local & S3 file providers	Yes	N/A
SonarQube	No (H2, PostgreSQL, etc.)	No	Yes	SpotBugs / Checkstyle
Wekan	No (MongoDB only)	No	Yes	Kanboard
Homarr	No (JSON-file config)	No	Yes	N/A
Jenkins	No (XML/H2 + RDBs)	Yes – via plugins	Yes	N/A
Zulip	No (PostgreSQL only)	Optional S3 for uploads	Yes	Matrix Synapse

Overall Management

These tools are part of the core infrastructure or service ecosystem.

Auth

App	SQLite Support	S3 Support	Needs Local File Storage?
Pocket ID	Yes – SQLite & Postgres	No	Yes

Storage

App	SQLite Support	S3 Support	Needs Local File Storage?	Redundancy/Backups Support
Minio	No	Yes – native S3	Yes	Yes – supports erasure coding and external backup tools

Virtualization (Base system)

App	SQLite Support	S3 Support	Needs Local File Storage?	Alternative(s)
Proxmox	Yes (SQLite for some subsystems)	Yes – via backup integrations	Yes	XCP-ng, Harvester, Virtual Machine Manager (virt-manager)

Alternatives Summary (File-Based, SQLite-Friendly)

Original App	Required DB	Recommended Alternative	Alt. Storage Type	OIDC Support?
Wekan	MongoDB only	Kanboard	SQLite	Yes
Miniflux v2	PostgreSQL only	FreshRSS	SQLite	Yes
Immich	PostgreSQL	PhotoPrism	SQLite	Yes
Outline	PostgreSQL	DokuWiki	Plain files	Yes
Zulip	PostgreSQL	Matrix Synapse (small scale)	SQLite (<10 users)	Yes
SonarQube	MySQL/PostgreSQL	SpotBugs / Checkstyle	File-based CLI tools	No

Comparisons

Pocket ID vs GoAuthentik

Pocket ID is a lightweight OIDC provider built for minimal deployments, storing data in SQLite or PostgreSQL. It is ideal for small-scale environments with minimal dependency chains. In contrast, GoAuthentik is a full-fledged identity management system supporting OIDC, SAML, LDAP, and SCIM. It offers extensive UI, group policies, fine-grained permissions, and external directory integrations.

Pocket ID Pros: minimal, SQLite-compatible, easy to deploy. Cons: lacks user management UI and advanced policy enforcement.

GoAuthentik Pros: enterprise-grade features, UI-driven, flexible protocols. Cons: requires PostgreSQL and more resources; overkill for small needs.

Advantage: Use Pocket ID for simple, embedded OIDC flows. Use GoAuthentik for multi-provider, user-heavy, policy-controlled environments.

Nextcloud vs ownCloud

Both offer file sync, collaboration, and plugin ecosystems. Nextcloud was forked from ownCloud and has since grown more rapidly with broader community support.

Nextcloud Pros: richer app ecosystem, more active development, better integration with self-hosted tools. Cons: heavier resource usage if all apps are enabled.

ownCloud Pros: focused enterprise-grade performance, optional use of proprietary file backend (Infinite Scale). Cons: smaller community, some features locked behind enterprise license.

Advantage: Nextcloud for extensibility and community; ownCloud for corporate file-centric use with tighter resource constraints.

NAS Solution – OpenMediaVault vs TrueNAS (formerly FreeNAS)

Both are open-source NAS platforms.

OpenMediaVault (OMV): Debian-based, plugin-rich, very lightweight. Suitable for Raspberry Pi to enterprise servers. Better for advanced users who prefer modularity.

TrueNAS: BSD-based (TrueNAS Core) or Linux-based (TrueNAS SCALE). Includes ZFS natively. Better UI for storage pools, replication, snapshots.

OMV Pros: simple architecture, lightweight, good community plugins. Cons: lacks native ZFS support without extra setup.

TrueNAS Pros: ZFS baked in, enterprise storage features, easy GUI. Cons: more RAM-hungry, limited plugin ecosystem vs OMV.

Advantage: OMV for light/modular deployments or ARM boards. TrueNAS for ZFS-centric workflows, snapshots, high-availability storage.

SnapRAID+mergerFS vs ZFS

ZFS is a combined filesystem and volume manager with built-in support for checksumming, compression, snapshots, deduplication, and high redundancy. It is ideal for always-on systems with ECC RAM and performance headroom.

SnapRAID+mergerFS is a two-part system: SnapRAID handles snapshot-style parity-based redundancy (not real-time), and mergerFS presents multiple disks as a single mount point. It's favored for media servers where write-once-read-many is common.

ZFS Pros: real-time parity and redundancy; excellent data integrity; snapshot and replication built-in; self-healing.
Cons: heavy RAM usage (8GB+ recommended); not friendly with drive spindown; less flexible for mixing drive sizes.

SnapRAID+mergerFS Pros: flexible disk sizes; disks can spin down when idle; low RAM requirements; good for large media archives.
Cons: no real-time parity; manual sync needed; not suitable for databases or fast-changing files.

Advantage: ZFS for always-on high-integrity storage and VM datasets; SnapRAID+mergerFS for archival use, media collections, and power-conscious setups.

SQLite Tuning

References:

SQLite can be tuned for better performance depending on the workload. Rails 8, for example, applies optimizations like:

Write-Ahead Logging (WAL) Mode: PRAGMA journal_mode = WAL; allows concurrent reads and writes.
Synchronous Mode: PRAGMA synchronous = NORMAL; or even OFF for less disk durability but faster writes.
Cache Size: Increase with PRAGMA cache_size = -N; (negative means KB). E.g., -65536 gives 64MB.
Temp Store in Memory: PRAGMA temp_store = MEMORY; avoids disk I/O for temp tables/indexes.
Foreign Keys Enforcement: Disable with PRAGMA foreign_keys = OFF; if you don’t need constraints.
Exclusive Locking Mode: PRAGMA locking_mode = EXCLUSIVE; can be beneficial for single-user applications.
Batch Transactions: Enclose multiple writes in a single BEGIN; ... COMMIT; block.
Auto Vacuum Mode: Use PRAGMA auto_vacuum = INCREMENTAL; and periodically PRAGMA incremental_vacuum;.

Each setting involves trade-offs between consistency, memory, and disk I/O—profiling your workload is essential.

SQLite PRAGMA Summary

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL; -- or OFF for higher speed, less durability
PRAGMA cache_size = -65536;  -- sets cache to 64MB
--PRAGMA mmap_size = 134217728;   -- 128MB; Can cause issues
PRAGMA journal_size_limit = 67108864; -- 64MB
PRAGMA temp_store = MEMORY;
PRAGMA foreign_keys = ON;
PRAGMA locking_mode = EXCLUSIVE;
PRAGMA busy_timeout   = 5000;        -- 5s retry on busy

Use BEGIN; and COMMIT; blocks to wrap large inserts/updates for batching.

Periodic run for SQLite DBs using cron:

To keep SQLite performant over time, add periodic maintenance commands:

PRAGMA optimize;
VACUUM;
PRAGMA integrity_check; --Might take time to run

PRAGMA optimize; analyzes and updates indexes and performs opportunistic cleanup.
VACUUM; rebuilds the entire database file, reclaiming space and defragmenting.

These can be run via cron daily or weekly depending on write volume.

Connecting to Server

There are several ways to securely connect to your self-hosted server:

WireGuard VPN (manually managed): Offers full control, encryption, and no exposure to the public internet. Best for private access, though requires client setup and dynamic IP handling if not static.
Cloudflare Tunnels: Proxies traffic via Cloudflare network, exposing only selected services to the internet without opening ports. Easy to set up, with robust DDoS protection. Relies on Cloudflare infra.
Public IP with Port Forwarding: Simplest option, but exposes services directly to the internet. Requires strict firewall rules and hardened auth (like Pocket-ID) to mitigate risk.
Tailscale or ZeroTier: Mesh VPN with automatic NAT traversal. Easier setup than WireGuard, includes ACLs, DNS integration, and mobile clients. No need for public IP.
Tor Hidden Services: For fully anonymous access and censorship resistance. Higher latency and less performance, but no IP exposure at all.

Security Note: Even if you use Cloudflare or a public IP, OIDC auth through Pocket-ID adds a crucial layer of protection by limiting access to authenticated users. Still, avoid unauthenticated exposure of any admin interfaces.

Access Method Comparison

Method	Exposes to Internet?	DNS Integration	Ease of Setup	Trust Model	Notes
WireGuard (manual)	No	External DNS with IP	Moderate	Full control, local infra	Must manage DDNS or static IP for DNS; no built-in discovery
Tailscale / ZeroTier	No	MagicDNS / custom DNS	Easy	Requires trust in provider	DNS routing via internal `.tailnet`, can map domains locally
Cloudflare Tunnel	Yes	Native + DNS proxy	Easy	Cloudflare-controlled	Seamless with subdomains like `auth.example.com`
Public IP	Yes	Native	Moderate	Fully self-managed	Ensure firewall + TLS + strong auth
Tor Hidden Services	No (hidden)	`.onion` only	Moderate	Fully decentralized	Not usable with standard DNS; not ideal for latency-sensitive apps

DNS with VPNs (WireGuard, Tailscale)

For setups like WireGuard or Tailscale, hosting auth.mydomain.com is possible by:

Using Dynamic DNS (e.g., duckdns, cloudflare-ddns) if your IP changes
Pointing auth.mydomain.com to your public IP and opening ports (defeats VPN-only intent)
Preferred: Route mydomain.com to a VPS/nginx/CDN proxy that forwards traffic via WireGuard to your LAN server
With Tailscale, MagicDNS enables internal resolution like auth.yourmachine.tailnet. For public DNS, a split-DNS or public proxy is required

These require additional DNS tricks or proxies to map domain names to internal VPN routes if you're avoiding public exposure.

Security Hardening

Fedora Server

FirewallD: Enable and configure using firewall-cmd. Only expose needed ports (e.g., 80/443 for HTTP/S).
Fail2ban: Protect SSH and exposed web services from brute force. Set custom jail rules.
SELinux: Leave enabled in enforcing mode. Audit denials and apply policies as needed.
SSH: Disable root login, enforce key-only auth, and change default port optionally.
System Updates: Use dnf-automatic or enable dnf-automatic.timer for regular patching.
ModSecurity (with nginx/apache): Use OWASP ruleset to harden web services.

Proxmox

iptables/nftables: Use built-in firewall per VM and at host level. Default deny inbound except management and VM ports.
Fail2ban: Protect Proxmox web UI (pveproxy) and SSH from brute-force attacks.
Web UI Hardening: Restrict UI access via VPN or whitelist IPs in datacenter.cfg ACLs.
SSH: Same hardening as Fedora—key-only login, custom port, disable root.
Two-Factor Auth: Enable TOTP for web UI access.
Unprivileged Containers: Use where possible instead of root LXC to limit scope of breaches.

Across both setups, keep backups encrypted and isolate sensitive apps in VLANs or firewall zones. Even with Pocket-ID protecting OIDC endpoints, underlying OS and service surface must be minimized.

Alternatives to Cloudflare Tunnels

Cloudflare Tunnels offer a highly appealing combination of ease, security, and privacy, making them a strong default choice when exposing services with minimal surface area. However, alternatives do exist:

Ngrok: Similar tunneling system, offers subdomain-based HTTPS tunnels. Commercial for persistent domains.
LocalTunnel: Lightweight open-source alternative. Less stable but easy to self-host.
Inlets / Inlets Pro: Expose local services via a VPS relay. Open-source core with encrypted traffic (Pro adds TLS and commercial support).
Teleport: Enterprise-grade reverse tunnel with audit and RBAC. Heavier setup.
FRP (Fast Reverse Proxy): Lightweight, fully self-hosted tunnel system from China, suited for custom infrastructure.

Self-hosted Proxy Option

Yes, you can host a VPS (with static IP) that acts as a public proxy. Run an nginx or Caddy reverse proxy on the VPS and create a persistent WireGuard tunnel from your home server to the VPS. Services on your local machine (e.g. auth.mydomain.com) can be accessed securely through the VPS, without revealing your home IP.

Benefit: Full control, TLS termination, and integration with Let's Encrypt on the VPS. Combine with fail2ban + Cloudflare DNS API for dynamic updates.

Risk Model

A comparison of tunnel options based on risk exposure, failure modes, and availability guarantees:

Method	IP Exposure	External Infra Required	Failure Mode	Data Exposure Risk	Recommended Mitigation
Cloudflare Tunnels	No	Yes (Cloudflare)	Tunnel disconnection (e.g., service loss)	Low	Health check alerts; OIDC + IP ACLs
WireGuard (manual)	No	No	Peer disconnects, IP change	Low (if ports closed)	DDNS; watchdog to auto-restart
Tailscale / ZeroTier	No	Yes (vendor-managed)	Agent disconnect, auth expiry	Low	Exit node fallback; ACLs via control panel
Public IP	Yes	No	Port scans, targeted attacks	High	Strict firewall; OIDC auth; fail2ban
VPS + WireGuard Tunnel	No	Yes (VPS provider)	VPS downtime or WG failure	Low	Redundant VPS; monitoring and fallback

Observation:

Cloudflare Tunnels offer lowest exposure and built-in DDoS protection, but you're dependent on their infra.
WireGuard-based options provide isolation but need vigilant routing and IP monitoring.
Public IP is most vulnerable without layered defenses.

Use health checks, uptime monitors, and multi-layered auth (like Pocket-ID) in all cases to reduce real-world risk.

theKAKAN/self-hosted.md

Select an option

No results found