Forem: selfhosting.sh

Pushover

selfhosting.sh — Fri, 20 Mar 2026 16:09:25 +0000

Why Replace Pushover?

Pushover charges $4.99 per platform — buy it once for Android, pay again for iOS, and again for Desktop. A family using both platforms across multiple people quickly racks up $20-30 in license fees for what amounts to an HTTP POST endpoint.

Updated March 2026: Verified with latest Docker images and configurations.

Beyond cost, Pushover routes every notification through its cloud servers. Your home automation alerts, server monitoring pings, and security notifications all pass through a third party. If Pushover's servers go down, your notifications stop. If they change their API or shut down, you lose everything.

Self-hosted alternatives give you unlimited notifications, zero recurring cost, and complete control over your data.

Best Alternatives

ntfy — Best Overall Replacement

ntfy is a simple HTTP-based pub/sub notification service. Send notifications with a single curl command — no client libraries, no SDKs, no API keys required for basic use.

curl -d "Server backup completed" ntfy.sh/your-private-topic

That's it. Any device subscribed to that topic gets the notification instantly. ntfy supports Android (via Google Play or F-Droid with UnifiedPush), iOS, and web browsers.

Why it wins: Zero-config notifications. The API is just HTTP POST to a URL. Every monitoring tool, script, and automation platform can send an HTTP request. ntfy also supports attachments, priorities, action buttons, scheduled delivery, and access control.

Docker setup:

services:
  ntfy:
    image: binwiederhier/ntfy:v2.19.2
    container_name: ntfy
    command: serve
    environment:
      TZ: UTC
    volumes:
      - ./ntfy-cache:/var/cache/ntfy
      - ./ntfy-config:/etc/ntfy
    ports:
      - "8080:80"
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-q", "--tries=1", "http://localhost:80/v1/health", "-O", "/dev/null"]
      interval: 60s
      timeout: 10s
      retries: 3

Create a server.yml config file in ./ntfy-config/:

base-url: "https://ntfy.yourdomain.com"
cache-file: "/var/cache/ntfy/cache.db"
cache-duration: "12h"
auth-default-access: "deny-all"
behind-proxy: true

Read our full guide: How to Self-Host ntfy

Gotify — Best for Simple Setups

Gotify is a self-hosted notification server with a clean web UI for managing applications and messages. Each application gets its own token, and messages arrive via WebSocket — no polling, no push service dependency.

Why choose Gotify: If you want a web dashboard to manage notifications with application-level organization, Gotify's UI is more polished than ntfy's. It stores message history in a database you control.

services:
  gotify:
    image: gotify/server:2.9.1
    container_name: gotify
    ports:
      - "8080:80"
    environment:
      GOTIFY_DEFAULTUSER_PASS: "your-strong-password-here"
      TZ: UTC
    volumes:
      - ./gotify-data:/app/data
    restart: unless-stopped

Read our full guide: How to Self-Host Gotify

Apprise — Best for Multi-Platform Routing

Apprise isn't a notification server itself — it's a notification gateway that can route alerts to 100+ services simultaneously. Send one notification and have it delivered to Slack, Discord, email, SMS, Matrix, Telegram, and your self-hosted ntfy or Gotify instance.

Use Apprise when you need to bridge notifications across multiple platforms from a single API call.

Read our full guide: How to Self-Host Apprise

Migration Guide

Pushover uses a simple HTTP POST API. Migrating to ntfy or Gotify is straightforward because they use the same pattern.

Pushover API Call

curl -s --form-string "token=APP_TOKEN" \
  --form-string "user=USER_KEY" \
  --form-string "message=Hello" \
  https://api.pushover.net/1/messages.json

ntfy Equivalent

curl -d "Hello" https://ntfy.yourdomain.com/your-topic

Gotify Equivalent

curl -X POST "https://gotify.yourdomain.com/message?token=APP_TOKEN" \
  -F "title=Alert" -F "message=Hello"

For scripts and automations that use Pushover's API, replace the endpoint URL and adjust the payload format. Most home automation tools (Home Assistant, Uptime Kuma, Grafana) have built-in ntfy and Gotify integrations.

Cost Comparison

	Pushover	Self-Hosted (ntfy/Gotify)
License cost	$4.99/platform (one-time)	$0
Family (2 people, 2 platforms each)	$19.96	$0
Monthly API cost	Free (10K messages/month)	$0 (unlimited)
Hosting cost	$0	~$3-5/month electricity (existing server)
Privacy	Notifications routed through Pushover servers	Stays on your network
Availability	Depends on Pushover uptime	Depends on your server uptime

What You Give Up

Mobile app polish. Pushover's Android and iOS apps are mature and well-designed. ntfy's Android app is solid (and on F-Droid), but its iOS app is newer. Gotify only has a third-party iOS client.
Zero maintenance. Pushover just works. Self-hosted servers need Docker updates and occasional troubleshooting.
Email gateway. Pushover can receive notifications via a special email address. ntfy supports this too, but it requires additional configuration.
Established integrations. Some commercial tools support Pushover natively but not ntfy or Gotify. Most support generic webhooks as a workaround.

FAQ

Does ntfy work with Home Assistant, Uptime Kuma, and other self-hosted tools?

Yes. ntfy has native integrations in Home Assistant, Uptime Kuma, Grafana, Prometheus Alertmanager, and many other self-hosted tools. For tools without built-in ntfy support, any tool that supports webhooks can send to ntfy — it's just an HTTP POST to a URL. Gotify also has growing integration support, though ntfy's is broader due to its simpler API.

Can ntfy send notifications to iOS devices?

Yes. ntfy has an iOS app on the App Store that uses Apple's Push Notification Service for reliable delivery even when the app is in the background. When self-hosting, you need to configure your ntfy server with APNs credentials, or use the ntfy.sh public relay for iOS push delivery while your server handles the backend. Gotify's iOS support is weaker — only third-party clients exist.

How do I secure ntfy so random people can't send me notifications?

Set auth-default-access: "deny-all" in ntfy's server config, then create user accounts with read/write permissions on specific topics. Use strong, random topic names as an additional layer — topics act as passwords when access control is enabled. For sensitive notifications, enable HTTPS via a reverse proxy and use authentication tokens in API headers.

Can I use ntfy or Gotify as a replacement for SMS notifications?

Yes, and it's more reliable. SMS depends on carrier delivery and has length limits. ntfy/Gotify deliver instantly over the internet with no character limits, support images/attachments, and include priority levels for alert severities. Configure critical alerts with Priority: urgent in ntfy to override Do Not Disturb on Android. For redundancy, pair ntfy with Apprise to route critical alerts to both ntfy and an SMS gateway simultaneously.

How much server resources does a self-hosted notification server need?

Minimal. ntfy uses about 30-50 MB RAM and negligible CPU. Gotify uses about 50-80 MB RAM. Both run comfortably on the smallest VPS or a Raspberry Pi alongside other services. Neither requires an external database — ntfy uses SQLite for caching, Gotify uses SQLite by default. A typical homelab generating 50-100 notifications per day uses less than 100 MB of cache storage.

Can I migrate my Pushover integrations to ntfy without breaking everything?

Migrate one integration at a time. Pushover and ntfy both use HTTP POST — the only changes are the endpoint URL and payload format. For scripts: replace curl https://api.pushover.net/1/messages.json with curl -d "message" https://ntfy.yourdomain.com/topic. For Home Assistant: change the notification platform from pushover to ntfy. Run both in parallel during transition until you've verified all integrations work.

Is there a way to route one notification to multiple platforms simultaneously?

Yes — that's exactly what Apprise does. Send one API call to Apprise, and it forwards the notification to ntfy, Gotify, Slack, Discord, email, Telegram, Matrix, and 100+ other services simultaneously. This is useful for critical alerts that need redundancy — if your ntfy server is down, the notification still reaches you via Telegram or email.

Paperless Ngx Vs Teedy

selfhosting.sh — Fri, 20 Mar 2026 14:19:23 +0000

Quick Verdict

Paperless-ngx is the better choice for most self-hosters. Its automated document classification, machine learning tagging, and consumption folder workflow make it the gold standard for going paperless. Choose Teedy only if you specifically need document approval workflows, LDAP authentication, or a traditional enterprise DMS structure with formal routing.

Updated March 2026: Verified with latest Docker images and configurations.

Overview

Paperless-ngx is a community-maintained document management system focused on the paperless office workflow. Scan a document, drop it in a folder, and Paperless-ngx automatically OCRs it, classifies it by correspondent and type, applies tags based on content, and makes everything searchable. Active development with frequent releases.

Teedy (formerly Sismics Docs) is a lightweight document management system with built-in workflow routing, 256-bit AES encryption, and LDAP support. It handles a wider range of file formats (Office docs, presentations) but lacks the automated classification that defines Paperless-ngx. Development has slowed — v1.11 released March 2023.

Feature Comparison

Feature	Paperless-ngx	Teedy
OCR engine	Tesseract + text layer injection	Tesseract 4
Automatic classification	Yes — ML-based tagging	No — manual tagging only
Consumption folder	Yes — auto-ingest from watched directory	No
Email ingestion	Yes — IMAP polling	Yes — email import
Document types	PDF, images (primary focus)	PDF, images, ODT, DOCX, PPTX
Workflow/approval routing	No	Yes — multi-step approval chains
Full-text search	Yes (excellent)	Yes (advanced search mode)
Correspondents model	Yes — auto-detected	No
Tags	Yes — auto-assigned + manual	Yes — manual only
LDAP/SSO	No native LDAP	Yes — built-in LDAP
Two-factor authentication	No native 2FA	Yes — TOTP
AES encryption at rest	No	Yes — 256-bit AES
Webhooks	No	Yes
REST API	Yes	Yes
Mobile app	PWA (responsive web)	Android app
Multi-user	Yes	Yes (with permissions)
Docker Compose complexity	4 services (app + Redis + PostgreSQL + Gotenberg)	2 services (app + PostgreSQL)
RAM usage	1-2 GB	512 MB - 1 GB
Development activity	Very active (monthly releases)	Slow (last release March 2023)
License	GPL-3.0	GPL-2.0

Document Ingestion

The core difference: Paperless-ngx is built around automated ingestion. Drop a scanned receipt into a consumption folder (or email it), and Paperless-ngx:

OCRs the document and creates a searchable PDF
Detects the correspondent (who sent it)
Assigns a document type (invoice, receipt, contract)
Applies tags based on content matching rules
Extracts and stores the creation date

Teedy requires you to upload documents through the web UI or API, then manually tag and categorize them. There's no watched folder, no automatic classification, no machine learning. You do all the organizing yourself.

For a household scanning invoices and receipts, Paperless-ngx's automation saves hours. For an office managing formal documents with approval chains, Teedy's manual workflow may be preferred.

Docker Setup Comparison

Paperless-ngx (4 containers):

services:
  paperless:
    image: ghcr.io/paperless-ngx/paperless-ngx:2.20.11
  redis:
    image: redis:7-alpine
  postgres:
    image: postgres:16-alpine
  gotenberg:
    image: gotenberg/gotenberg:8.17

Teedy (2 containers):

services:
  teedy:
    image: sismics/docs:v1.11
  postgres:
    image: postgres:16-alpine

Teedy is simpler to deploy — half the containers, fewer moving parts. Paperless-ngx needs Redis for task queuing and Gotenberg for document conversion.

Resource Usage

Resource	Paperless-ngx	Teedy
RAM (idle)	800 MB - 1.5 GB	400-700 MB
RAM (OCR processing)	1.5-3 GB	700 MB - 1.5 GB
CPU during OCR	High (multi-threaded)	Medium
Disk (app + dependencies)	~2 GB	~500 MB
Database growth	Fast (full-text index + thumbnails)	Moderate

Teedy is lighter because it's a simpler Java application without the task queue, thumbnail generation, and ML classification pipeline that Paperless-ngx runs.

Search Capabilities

Both support full-text search, but Paperless-ngx is significantly better:

Paperless-ngx: Searches document content, correspondents, types, tags, dates, and custom fields. Filtered views. Saved searches. The search is central to the UX — it's how you find everything.
Teedy: Full-text search is available but requires using "advanced search." Basic search may not surface OCR'd text. The experience is more like a traditional file browser with search bolted on.

Security

Teedy has the edge on built-in security features:

AES-256 encryption at rest — all stored documents are encrypted
LDAP integration — connect to Active Directory or OpenLDAP
TOTP two-factor authentication — native 2FA support
Audit logging — track all document access and modifications

Paperless-ngx has none of these natively. For LDAP or 2FA, you'd need a reverse proxy with Authelia or Authentik in front. Documents on disk are not encrypted (you'd use filesystem-level encryption).

Use Cases

Choose Paperless-ngx If...

You scan receipts, invoices, and letters regularly
You want documents automatically classified and tagged
Search and retrieval speed matter most
You prefer active, well-maintained software
You're a household or small business going paperless
You want the best OCR pipeline (text layer injection into PDFs)

Choose Teedy If...

You need document approval workflows (review → approve → archive)
LDAP authentication is a requirement
You want built-in 2FA without extra infrastructure
Encrypted storage at rest is mandatory
You manage Office documents (DOCX, PPTX) alongside PDFs
You need webhook integrations for automation
Simpler Docker deployment matters (2 containers vs 4)

Final Verdict

Paperless-ngx dominates for the use case most self-hosters care about: turning paper into searchable, organized digital documents automatically. Its machine learning classification, consumption folder, and active development make it the category leader. Teedy serves a different niche — formal document management with approval workflows and enterprise authentication. If you're going paperless at home, Paperless-ngx is the obvious choice. If you're managing contract approvals or need LDAP and encryption, Teedy fills gaps Paperless-ngx doesn't.

Matrix Vs Discord

selfhosting.sh — Fri, 20 Mar 2026 12:24:22 +0000

Quick Verdict

Matrix is the only viable self-hosted alternative to Discord that supports federation, end-to-end encryption, and community features like spaces. You trade Discord's polish and massive user base for full data ownership and privacy. For private communities, gaming groups wanting independence from Discord's ToS, or organizations needing compliance, Matrix wins. For casual social hangouts where everyone already has Discord, switching is a hard sell.

Overview

Discord is a proprietary chat platform built for gaming communities that expanded into general-purpose communication. 200+ million monthly active users. Free tier is generous but monetized through Nitro subscriptions. All data lives on Discord's servers — you have no control and no export.

Matrix is an open, federated communication protocol with multiple server implementations (Synapse, Conduit, Dendrite). Anyone can run a server and federate with the global Matrix network. The reference client is Element. Self-hosting gives you complete control over your data, encryption keys, and server policies.

Feature Comparison

Feature	Matrix (Element)	Discord
Self-hostable	Yes (Synapse, Conduit)	No
End-to-end encryption	Yes (Megolm/Olm, on by default in DMs)	No
Federation	Yes — servers communicate across domains	No — single platform
Voice/video calls	Yes (via Jitsi or native Element Call)	Yes (excellent quality)
Screen sharing	Yes (via Element Call or Jitsi)	Yes (built-in, smooth)
Communities/Spaces	Yes (Spaces = Discord server equivalent)	Yes (Servers with channels)
Threads	Yes	Yes
Bots	Yes (bridges, appservices)	Yes (massive ecosystem)
Rich embeds	Basic	Excellent
Mobile apps	Element (iOS/Android)	Discord (iOS/Android)
Desktop apps	Element Desktop	Discord Desktop
Message search	Yes (full-text)	Yes (limited on free tier)
File sharing	Yes (size depends on server config)	25 MB free, 500 MB with Nitro
Custom emoji	Yes (per-room)	Yes (per-server, Nitro for global)
Roles/permissions	Yes (power levels)	Yes (granular role system)
User verification	Yes (cross-signing, emoji verification)	No
Data export	Yes (full server data, you own it)	Limited (GDPR request only)
Open source	Yes (Apache 2.0)	No
Cost	Free (self-hosted)	Free tier + Nitro ($9.99/mo)
Protocol bridges	IRC, Slack, Telegram, XMPP, Discord	None (walled garden)

Voice and Video Quality

Discord's voice chat is its killer feature — low latency, excellent quality, seamless channel switching. Matrix voice/video exists through Element Call (native WebRTC) or Jitsi integration, but it's noticeably rougher. Group calls work but lack Discord's polish: no "move between voice channels" fluidity, occasional connectivity issues, and higher latency.

For text-heavy communities, this doesn't matter. For gaming groups that live in voice channels, it's the biggest gap.

Bot and Integration Ecosystem

Discord's bot ecosystem is enormous — thousands of bots for moderation, music, games, automation, and community management. Matrix has a growing but much smaller ecosystem. Where Matrix shines is bridges — you can bridge Matrix rooms to Discord, Telegram, IRC, Slack, and more using mautrix bridges. This means your Matrix server can connect to Discord without anyone leaving their preferred platform.

Community Management

Aspect	Matrix	Discord
Server structure	Spaces → Rooms (nested hierarchy)	Servers → Categories → Channels
Moderation tools	Power levels, bans, ACLs, Mjolnir bot	Built-in moderation, AutoMod, bots
User onboarding	Invite links or open registration	Invite links with customizable landing
Member limits	Unlimited (server capacity)	500K per server
Discovery	Room directory, Spaces	Server discovery, templates
Verification	Cross-signing with emoji or QR	Phone verification, ID verification

Discord's moderation tools are more mature and user-friendly. Matrix's power level system is more flexible but less intuitive. For large public communities, Discord's built-in AutoMod and raid protection are significant advantages.

Privacy and Data Ownership

This is where Matrix dominates:

E2E encryption is built into the protocol. DMs are encrypted by default. Room encryption is optional and widely used.
Federation means no single entity controls the network. Your messages can't be deleted by a company policy change.
Self-hosting means your data lives on your hardware. No training AI models on your conversations.
No tracking — Discord tracks extensive user behavior for advertising and recommendation systems.

Discord has no end-to-end encryption, scans all messages for "safety," and has been known to share data with law enforcement without user notification.

Self-Hosting Requirements

Resource	Matrix (Synapse)	Matrix (Conduit)
RAM	1-2 GB minimum	70-200 MB
CPU	2+ cores recommended	1 core sufficient
Disk	50+ GB (grows fast)	1-5 GB
Database	PostgreSQL (required)	RocksDB (embedded)
Setup time	30-60 minutes	10-15 minutes

For a small community (under 50 users), Conduit is ideal — it runs on a Raspberry Pi. For larger deployments, Synapse provides full spec compliance.

Use Cases

Choose Matrix If...

Privacy and data ownership matter to your community
You need end-to-end encryption for sensitive conversations
You want to federate with other Matrix servers or bridge to other platforms
You're building a community for an organization with compliance requirements
You want to escape vendor lock-in and platform risk
You're comfortable with self-hosting or using a Matrix hosting provider

Choose Discord If...

Voice chat quality is critical (gaming groups)
You need the massive bot ecosystem
Your community members already use Discord and won't switch
You want the easiest setup with zero maintenance
You're building a large public community (10K+ members)
Moderation tools and raid protection are top priorities

Bridging: The Best of Both Worlds

You don't have to choose entirely. Matrix bridges let you connect Matrix rooms to Discord channels bidirectionally. Messages flow between both platforms transparently. Run your own Matrix server for members who care about privacy, while keeping a Discord presence for discoverability. The mautrix-discord bridge handles this.

Final Verdict

Matrix is a credible self-hosted alternative to Discord for communities that value privacy, data ownership, and independence. The voice/video gap is real but narrowing. The bot ecosystem gap is wide but mitigated by bridges. If your community's primary mode is text chat and you care about where your data lives, Matrix is the clear choice. If you're a gaming community that lives in voice channels and uses 15 different bots, Discord remains hard to replace entirely — but bridging lets you have a foot in both worlds.

Nextcloud Upload Limit

selfhosting.sh — Fri, 20 Mar 2026 10:40:02 +0000

The Problem

Nextcloud rejects file uploads above a certain size. Users see errors like:

"Upload failed. Could not upload file because the file is too large"
"Request Entity Too Large" (413 error)
Upload progress bar reaches 100% but the file disappears
Desktop client shows sync errors for large files

The default upload limit depends on your PHP configuration — typically 2 MB or 512 MB. When using a reverse proxy, the proxy may impose its own limit.

The Cause

Four layers can each impose upload size limits:

Layer	Default Limit	Config Location
PHP	2 MB (`upload_max_filesize`)	`php.ini` or `.htaccess`
PHP	8 MB (`post_max_size`)	`php.ini` or `.htaccess`
Nextcloud	512 MB (chunked upload)	Admin settings
Web server (nginx)	1 MB (`client_max_body_size`)	`nginx.conf`
Reverse proxy	Varies	Proxy config

The most restrictive layer wins. You need to increase limits at every layer.

The Fix

Method 1: PHP Configuration (Docker)

For the official Nextcloud Docker image, create a custom PHP config:

# Create custom PHP config
cat > /path/to/nextcloud/config/upload.ini << 'EOF'
upload_max_filesize = 16G
post_max_size = 16G
max_input_time = 3600
max_execution_time = 3600
memory_limit = 512M
EOF

Mount it in Docker Compose:

services:
  nextcloud:
    image: nextcloud:33.0.0
    volumes:
      - nextcloud_data:/var/www/html
      - ./upload.ini:/usr/local/etc/php/conf.d/upload.ini:ro

Restart the container:

docker compose restart nextcloud

Method 2: PHP Configuration (Non-Docker)

Edit the PHP config file (location depends on your OS):

# Find the active php.ini
php -i | grep "php.ini"

# Edit it
sudo nano /etc/php/8.3/fpm/php.ini

Change these values:

upload_max_filesize = 16G
post_max_size = 16G
max_input_time = 3600
max_execution_time = 3600
memory_limit = 512M

Alternatively, add to Nextcloud's .htaccess file:

php_value upload_max_filesize 16G
php_value post_max_size 16G
php_value max_input_time 3600
php_value max_execution_time 3600

Restart PHP-FPM:

sudo systemctl restart php8.3-fpm

Method 3: Nginx Reverse Proxy

If you're using nginx as a reverse proxy in front of Nextcloud:

server {
    listen 443 ssl;
    server_name cloud.yourdomain.com;

    client_max_body_size 16G;          # Maximum upload size
    client_body_timeout 3600s;         # Time to wait for request body
    proxy_read_timeout 3600s;          # Time to wait for proxy response
    proxy_connect_timeout 3600s;

    location / {
        proxy_pass http://nextcloud:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_request_buffering off;   # Stream uploads directly, don't buffer
    }
}

Reload nginx:

sudo nginx -t && sudo systemctl reload nginx

Method 4: Nginx Proxy Manager

In Nginx Proxy Manager:

Go to your Nextcloud proxy host
Click the Advanced tab
Add this custom configuration:

client_max_body_size 16G;
proxy_request_buffering off;
client_body_timeout 3600s;

Method 5: Apache Reverse Proxy

<VirtualHost *:443>
    ServerName cloud.yourdomain.com

    ProxyPass / http://nextcloud:80/
    ProxyPassReverse / http://nextcloud:80/

    # Increase upload limit
    LimitRequestBody 17179869184

    ProxyTimeout 3600
    TimeOut 3600
</VirtualHost>

Method 6: Nextcloud Admin Settings

Log into Nextcloud as admin
Go to Administration Settings > Basic Settings
Under Upload, check the current chunked upload limit
Nextcloud uses chunked uploads (10 MB chunks by default), so the PHP limit mainly affects the web UI uploader rather than desktop/mobile clients

Verify the Fix

After applying changes, verify the effective limits:

# Check PHP settings inside the Docker container
docker exec nextcloud php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

Expected output:

upload_max_filesize => 16G => 16G
post_max_size => 16G => 16G
memory_limit => 512M => 512M

Test by uploading a file larger than the previous limit.

Prevention

Set upload limits during initial deployment — add the custom PHP config to your Docker Compose from the start
Use the desktop client for large files — Nextcloud desktop clients use chunked uploads that bypass PHP limits
Set proxy_request_buffering off in nginx to prevent the proxy from buffering the entire upload in memory before forwarding
Monitor disk space — large uploads can fill your volume unexpectedly; set up disk usage alerts

Syncthing Not Connecting

selfhosting.sh — Fri, 20 Mar 2026 08:38:08 +0000

The Problem

Syncthing devices show as "Disconnected" in the web UI. Folders display "Out of Sync" or "Waiting to Connect." Devices that previously synced stop communicating, or newly added devices never establish a connection.

Updated March 2026: Verified with latest Docker images and configurations.

Common error messages in the Syncthing log:

Connection to DEVICE-ID at tcp://192.168.1.100:22000 refused
Relay connection failed: dial tcp relay.syncthing.net:443: i/o timeout
Discovery: no addresses returned

The Cause

Syncthing uses three connection methods in this priority order:

Direct connection — TCP on port 22000 (default) between devices on the same LAN or port-forwarded through NAT
Relay — Through Syncthing relay servers when direct connections fail
Discovery — Global discovery servers to find device addresses, plus local discovery via broadcast

Connection failures happen when:

Firewalls block port 22000 (TCP) and/or 21027 (UDP for local discovery)
NAT/router configuration prevents incoming connections
Relay servers are unreachable (corporate networks, restrictive ISPs)
Device IDs are mismatched between peers
Syncthing is bound to the wrong network interface

The Fix

Method 1: Fix Firewall Rules (Most Common)

On the server running Syncthing, open the required ports:

# UFW (Ubuntu/Debian)
sudo ufw allow 22000/tcp comment "Syncthing file sync"
sudo ufw allow 21027/udp comment "Syncthing local discovery"

# firewalld (Fedora/RHEL)
sudo firewall-cmd --permanent --add-port=22000/tcp
sudo firewall-cmd --permanent --add-port=21027/udp
sudo firewall-cmd --reload

For Docker deployments, ensure the ports are mapped in your Docker Compose:

services:
  syncthing:
    image: syncthing/syncthing:2.0.15
    ports:
      - "8384:8384"     # Web UI
      - "22000:22000/tcp"  # File sync (TCP)
      - "22000:22000/udp"  # File sync (QUIC)
      - "21027:21027/udp"  # Local discovery

Method 2: Fix NAT/Router Configuration

If devices are on different networks, port forward on your router:

Log into your router admin panel
Forward port 22000 TCP to your Syncthing server's LAN IP
Forward port 21027 UDP for discovery (optional but helps)
Forward port 22000 UDP for QUIC connections (optional, improves performance)

Verify the port is reachable from outside:

# From another network
nc -zv your-public-ip 22000

Method 3: Force Relay Connections

If direct connections aren't possible (both devices behind strict NAT), verify relay access:

Open Syncthing web UI → Actions > Settings > Connections
Ensure "Enable Relaying" is checked
Ensure "Global Discovery" is enabled
Default relay servers: default (uses Syncthing's public relays)

Test relay connectivity:

curl -s https://relays.syncthing.net/endpoint | head -5

If your network blocks outbound connections to relay servers (port 443), you may need to configure a corporate proxy or use a VPN.

Method 4: Verify Device IDs

Mismatched device IDs prevent connections entirely:

On Device A: Actions > Show ID — copy the full device ID
On Device B: Add Remote Device — paste Device A's ID exactly
Repeat in reverse (Device B's ID on Device A)
Both devices must accept each other

Method 5: Check Listen Address

If Syncthing is bound to a specific interface:

Go to Actions > Settings > Connections
Check "Sync Protocol Listen Addresses"
Default is default which listens on all interfaces
If set to a specific IP (e.g., tcp://192.168.1.100:22000), ensure that IP is correct and reachable

Prevention

Use the default listen address unless you have a specific reason to bind to one interface
Keep relay enabled as a fallback even if you primarily use direct connections
Set up port forwarding on your router for at least one device per network
Monitor connection status in the Syncthing web UI — the "Connections" tab shows which method each device uses
Use Syncthing's built-in NAT traversal (enabled by default) — it handles UPnP and NAT-PMP automatically if your router supports them

Splitwise

selfhosting.sh — Fri, 20 Mar 2026 06:48:07 +0000

Why Replace Splitwise?

Splitwise knows exactly how you split dinner, who owes what on the electricity bill, and how much your housemate spent on groceries last Tuesday. It's a detailed financial profile of your relationships — stored on someone else's servers.

Beyond privacy, Splitwise has been progressively paywalling features. Splitwise Pro ($4.99/month or $49.99/year) gates receipt scanning, currency conversion, chart visualizations, search, and more. Features that were free in 2020 now cost money.

Concern	Splitwise	Self-Hosted
Monthly cost	Free (limited) / $4.99/mo (Pro)	$0
Annual cost	$0-50/year	$0
Data location	Splitwise's cloud	Your server
Ads	Yes (free tier)	No
Receipt scanning	Pro only	Varies by app
Currency conversion	Pro only	Available
Search expenses	Pro only	Available
Privacy	Third-party access	Full control

Best Alternatives

IHateMoney — Best Overall Replacement

IHateMoney does exactly what Splitwise does — track shared expenses in a group and calculate who owes whom. No accounts needed. Create a project with a shared link, add expenses, and the app calculates the simplest settlement plan.

What matches Splitwise:

Add expenses with payer and participants
Automatic debt simplification (minimizes number of transfers)
Multi-currency support
Project-based groups (one per trip, household, etc.)
No registration required — just a project name and password

What's different:

No mobile app (responsive web UI only)
No receipt scanning
Simpler UI — functional, not pretty
No push notifications for new expenses

Setup:

services:
  ihatemoney:
    image: ihatemoney/ihatemoney:7.0.1
    container_name: ihatemoney
    environment:
      - IHATEMONEY_SETTINGS_FILE_PATH=/etc/ihatemoney/ihatemoney.cfg
    volumes:
      - ./data:/database
      - ./ihatemoney.cfg:/etc/ihatemoney/ihatemoney.cfg:ro
    ports:
      - "8000:8000"
    restart: unless-stopped

Create ihatemoney.cfg:

# IHateMoney configuration
SQLALCHEMY_DATABASE_URI = "sqlite:////database/ihatemoney.db"
SECRET_KEY = "change-this-to-a-random-string"
ALLOW_PUBLIC_PROJECT_CREATION = True

One container, ~30 MB RAM. Create a project, share the URL, start splitting. Read our full guide: How to Self-Host IHateMoney

Firefly III — Best for All-in-One Finance

If you want expense splitting as part of a complete personal finance system, Firefly III handles shared expenses through its split transaction feature and tagging system. It's not purpose-built for Splitwise-style group splitting, but if you already run Firefly III for budgeting, you can track shared expenses within the same system.

Best for people who want one financial tool instead of multiple specialized apps. Read our full guide: How to Self-Host Firefly III

Actual Budget — Best Budget-First Approach

Actual Budget can track shared expenses through categories and payees, though it doesn't calculate settlement balances automatically. Pair it with IHateMoney — use Actual Budget for personal budgeting and IHateMoney for group expense splitting. Read our full guide: How to Self-Host Actual Budget

Cost Comparison

	Splitwise Free	Splitwise Pro	IHateMoney
Monthly cost	$0	$4.99/month	$0
Annual cost	$0	$49.99/year	$0
3-year cost	$0	$150	$0
Ads	Yes	No	No
Receipt scanning	No	Yes	No
Charts	No	Yes	Yes (basic)
Search	No	Yes	Yes
Currency conversion	No	Yes	Yes
Data ownership	No	No	Yes

Migration Guide

Exporting from Splitwise

Log in to Splitwise on the web
Go to Account Settings → Export Data
Download your expense history as CSV
Each group exports separately

Importing into IHateMoney

IHateMoney supports CSV import:

Create a new project in IHateMoney matching your Splitwise group
Reformat the Splitwise CSV to match IHateMoney's expected columns (date, description, payer, amount, participants)
Import via the project settings

Manual entry is also fast for active groups — most people have 5-20 expenses per month per group.

What You Give Up

Native mobile apps. Splitwise's iOS and Android apps are polished and purpose-built. IHateMoney is web-only — functional on mobile browsers but not as convenient for quick expense entry at the register.

Push notifications. Splitwise notifies group members when expenses are added. Self-hosted alternatives rely on manual checking or email notifications you'd need to configure yourself.

Receipt scanning. Splitwise Pro scans receipts and extracts amounts automatically. No self-hosted expense splitter has this feature — you'll type amounts manually.

Friend network. Splitwise maintains persistent debts across groups and over time. IHateMoney treats each project independently — settling up in one project doesn't affect balances in another.

Simplicity. Splitwise is "download app, create group, add expense." Self-hosted requires deploying a container and sharing a URL. For a group of non-technical housemates, this is a real friction point.

Frequently Asked Questions

Can I import my Splitwise expense history into IHateMoney?

Yes, with reformatting. Export your Splitwise data as CSV (Account Settings → Export Data), then reformat the columns to match IHateMoney's expected format: date, description, payer, amount, and participants. IHateMoney supports CSV import through project settings. You'll need to create a project for each Splitwise group and import them separately. For small groups with recent activity, manual entry may be faster than reformatting the CSV.

Does IHateMoney have a mobile app?

No native app — IHateMoney is web-only with a responsive interface that works in mobile browsers. You can add it to your home screen as a PWA for quick access. The mobile experience is functional for viewing balances and adding expenses, but it lacks the polished tap-to-add workflow of Splitwise's native apps. For groups where quick expense entry at the register matters, this is the biggest trade-off.

Can multiple groups share the same IHateMoney instance?

Yes. Each IHateMoney "project" is independent with its own URL, password, and participants. You can run as many projects as you want on a single instance — one for your household, another for a trip, another for office lunches. Projects don't interact with each other. There's no cross-project debt tracking like Splitwise's friend-level balances, but each group works independently without issue.

How does IHateMoney handle different currencies?

IHateMoney supports multi-currency expenses within a single project. When adding an expense, you can specify the currency. The settlement calculation handles conversion based on rates you set. It's not as automatic as Splitwise Pro's real-time currency conversion, but it works for trips where expenses happen in mixed currencies. Set the exchange rate manually when adding the expense.

Is IHateMoney secure enough for financial data?

IHateMoney protects projects with a shared password — anyone with the project ID and password can view and add expenses. There's no per-user authentication or audit trail. For household expense splitting, this is fine. For anything involving sensitive financial data, pair it with a reverse proxy that adds proper authentication (OAuth2, basic auth). The data itself is stored in a SQLite database on your server, so you control access at the infrastructure level.

Can I self-host Splitwise itself instead of using an alternative?

No. Splitwise is a proprietary, closed-source application with no self-hosted option. The only way to use Splitwise is through their cloud service. IHateMoney is the closest open-source equivalent in terms of functionality — shared expense tracking with automatic debt simplification. If you need features IHateMoney lacks (receipt scanning, push notifications), you'll need to combine multiple tools or accept those limitations.

Privacy Friendly Analytics Setup

selfhosting.sh — Fri, 20 Mar 2026 04:58:05 +0000

Why Privacy-Friendly Analytics Matter

Google Analytics collects 72 data points per visitor. It tracks users across sites, builds advertising profiles, and requires cookie consent banners that annoy everyone and tank your conversion rates. Since GDPR enforcement began, running GA4 without a consent banner is a legal risk in the EU. Running it with a banner means 30-50% of visitors decline cookies and disappear from your data entirely.

Privacy-friendly analytics solve all three problems at once:

No cookies. No consent banner needed. No GDPR headaches. You see 100% of your traffic.
You own the data. Visitor data never leaves your server. No third party mines it for ad targeting.
Lighter pages. Google's gtag.js is 28 KB gzipped and makes multiple network requests. Plausible's script is under 1 KB.

The tradeoff is real: you lose user-level tracking, cross-site attribution, and the deep integration Google Analytics has with Google Ads. If you depend on those for paid acquisition campaigns, privacy-friendly analytics are a complement, not a replacement. For content sites, blogs, documentation, and most self-hosted projects, they are strictly better.

What Data You Actually Need

Most site owners use less than 5% of what GA4 collects. Here is what matters for a content site:

Metric	Privacy Analytics	GA4
Pageviews	Yes	Yes
Unique visitors (anonymized)	Yes	Yes
Traffic sources / referrers	Yes	Yes
Top pages	Yes	Yes
Country-level location	Yes (IP-based, not stored)	Yes (cookie-based)
Device / browser / OS	Yes	Yes
Bounce rate	Yes	Yes
Session duration	Varies by tool	Yes
UTM campaign tracking	Yes	Yes
User-level journey tracking	No	Yes
Cross-domain tracking	No	Yes
Conversion funnels	Limited	Yes
Google Ads integration	No	Yes

If the "No" column does not affect your business, self-hosted privacy analytics give you everything you need with none of the baggage.

The Three Lightest Options Compared

Three tools dominate the self-hosted privacy analytics space. Each takes a different approach.

Feature	Plausible CE	Umami	GoAccess
Approach	JavaScript snippet	JavaScript snippet	Server log parsing
Cookie-free	Yes	Yes	Yes (no JS at all)
GDPR compliant without consent	Yes	Yes	Yes
Real-time dashboard	Yes	Yes	Yes
Script size	<1 KB	~2 KB	N/A (no script)
Database	PostgreSQL + ClickHouse	PostgreSQL	None (flat files)
RAM usage (idle)	~500 MB	~200 MB	~50 MB
Custom events	Yes	Yes	No
API	Yes	Yes	Limited (JSON export)
Multi-site support	Yes	Yes	Yes (separate configs)
Docker support	Official	Official	Official
License	AGPL-3.0	MIT	MIT
Latest version	v3.2.0	v3.0.3	1.10.1
Best for	Simplicity, drop-in GA replacement	Customization, multi-site dashboards	Zero-JS, minimal infrastructure

The short answer: Use Plausible if you want the simplest path from GA4 to privacy analytics. Use Umami if you want more control over dashboards and event tracking. Use GoAccess if you want zero JavaScript on your site and already have access logs.

Prerequisites

A Linux server with Docker and Docker Compose installed (Docker Compose Basics)
A domain or subdomain for your analytics instance (e.g., analytics.example.com)
1 GB RAM minimum for Umami, 2 GB for Plausible (ClickHouse is hungry)
A reverse proxy for HTTPS termination (Reverse Proxy Setup)

Option 1: Plausible Community Edition

Plausible is the closest thing to a drop-in GA4 replacement. The dashboard is clean, opinionated, and shows exactly what you need on a single page. No training required — anyone on your team can read it.

Plausible CE requires three services: the Plausible application, PostgreSQL for metadata, and ClickHouse for analytics event data.

Create a project directory and the required files:

mkdir -p /opt/plausible && cd /opt/plausible

ClickHouse Configuration

ClickHouse needs a few config tweaks for low-resource operation. Create these files before starting the stack.

Create clickhouse/clickhouse-config.xml:

<clickhouse>
    <logger>
        <level>warning</level>
        <console>true</console>
    </logger>
    <listen_host>0.0.0.0</listen_host>
    <http_port>8123</http_port>
    <tcp_port>9000</tcp_port>
    <profiles>
        <default>
            <log_queries>0</log_queries>
            <log_query_threads>0</log_query_threads>
        </default>
    </profiles>
</clickhouse>

Create clickhouse/clickhouse-user-config.xml:

<clickhouse>
    <listen_host>0.0.0.0</listen_host>
</clickhouse>

Docker Compose

Create docker-compose.yml:

services:
  plausible_db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=plausible-db-password  # Change this
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

  plausible_events_db:
    image: clickhouse/clickhouse-server:24.12-alpine
    restart: unless-stopped
    volumes:
      - event-data:/var/lib/clickhouse
      - event-logs:/var/log/clickhouse-server
      - ./clickhouse/clickhouse-config.xml:/etc/clickhouse-server/config.d/logging.xml:ro
      - ./clickhouse/clickhouse-user-config.xml:/etc/clickhouse-server/users.d/logging.xml:ro
    ulimits:
      nofile:
        soft: 262144
        hard: 262144
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://localhost:8123/ping || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 5

  plausible:
    image: ghcr.io/plausible/community-edition:v3.2.0
    restart: unless-stopped
    command: sh -c "/entrypoint.sh db createdb && /entrypoint.sh db migrate && /entrypoint.sh run"
    depends_on:
      plausible_db:
        condition: service_healthy
      plausible_events_db:
        condition: service_healthy
    ports:
      - "8000:8000"
    volumes:
      - plausible-data:/var/lib/plausible
    ulimits:
      nofile:
        soft: 65535
        hard: 65535
    environment:
      - BASE_URL=https://analytics.example.com  # Your analytics domain — MUST change
      - SECRET_KEY_BASE=REPLACE_WITH_64_BYTE_SECRET  # Generate with: openssl rand -base64 48
      - DATABASE_URL=postgres://postgres:plausible-db-password@plausible_db:5432/plausible_db
      - CLICKHOUSE_DATABASE_URL=http://plausible_events_db:8123/plausible_events_db
      - DISABLE_REGISTRATION=invite_only  # Set to 'true' after creating your account
      - MAILER_EMAIL=analytics@example.com  # From address for emails
      # Uncomment and configure for email (account creation, reports):
      # - SMTP_HOST_ADDR=smtp.example.com
      # - SMTP_HOST_PORT=587
      # - SMTP_USER_NAME=your-smtp-user
      # - SMTP_USER_PWD=your-smtp-password
      # - SMTP_HOST_SSL_ENABLED=true

volumes:
  db-data:
  event-data:
  event-logs:
  plausible-data:

Generate the Secret Key

openssl rand -base64 48

Copy the output and replace REPLACE_WITH_64_BYTE_SECRET in the compose file.

Start Plausible

docker compose up -d

The first startup takes 30-60 seconds as ClickHouse initializes and migrations run. Check logs:

docker compose logs -f plausible

Once you see [info] Running Plausible on port 8000, the instance is ready at http://your-server-ip:8000.

Initial Setup

Open your Plausible instance in a browser
Create your admin account (the first account becomes the owner)
Add your site domain
Copy the tracking script (covered below in "Adding the Tracking Script")
Set DISABLE_REGISTRATION=true in the compose file and restart to lock down signups

Option 2: Umami

Umami is lighter than Plausible (no ClickHouse), offers more dashboard customization, and has a built-in API for pulling data into other tools. It supports custom events, multiple dashboards per site, and ad-blocker evasion through script/endpoint renaming.

Umami needs two services: the Node.js application and PostgreSQL.

Create a project directory:

mkdir -p /opt/umami && cd /opt/umami

Docker Compose

Create docker-compose.yml:

services:
  umami:
    image: ghcr.io/umami-software/umami:v3.0.3
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:change-this-password@umami_db:5432/umami
      APP_SECRET: REPLACE_WITH_RANDOM_STRING  # Min 32 chars. Generate with: openssl rand -hex 32
      # Rename tracking paths to bypass ad blockers (optional):
      # TRACKER_SCRIPT_NAME: custom-script-name
      # COLLECT_API_ENDPOINT: /api/custom-endpoint
    depends_on:
      umami_db:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:3000/api/heartbeat || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 5
    init: true

  umami_db:
    image: postgres:15-alpine
    restart: unless-stopped
    volumes:
      - umami-db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: change-this-password  # Must match DATABASE_URL above
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  umami-db-data:

Generate the App Secret

openssl rand -hex 32

Replace REPLACE_WITH_RANDOM_STRING in the compose file with the output.

Start Umami

docker compose up -d

Umami starts faster than Plausible — typically under 15 seconds. Check logs:

docker compose logs -f umami

Once healthy, Umami is available at http://your-server-ip:3000.

Initial Setup

Log in with the default credentials: admin / umami
Change the admin password immediately (Settings > Profile)
Add your website (Settings > Websites > Add Website)
Copy the tracking script from the website settings page

Bypassing Ad Blockers

Many ad blockers target analytics scripts by URL pattern. Umami lets you rename the script and collection endpoint:

environment:
  TRACKER_SCRIPT_NAME: custom-data
  COLLECT_API_ENDPOINT: /api/custom-collect

With this configuration, the tracking script URL becomes /custom-data.js instead of the default /script.js, which ad blockers are less likely to block. Proxy the analytics subdomain through your main domain's reverse proxy for even better results.

Option 3: GoAccess (No JavaScript)

GoAccess takes a fundamentally different approach: it parses your web server's access logs instead of injecting JavaScript. Zero scripts on your site. Zero impact on page load. No data sent to any external server — not even your own analytics instance.

The tradeoff: GoAccess cannot track client-side events, single-page app navigation, or JavaScript-dependent metrics. It sees what your web server sees — HTTP requests. For static sites and server-rendered pages, this is often enough.

GoAccess runs as a single binary with no database. Feed it a log file and it produces a real-time HTML dashboard or terminal UI.

Quick Docker Setup

docker run --rm -v /var/log/nginx:/var/log/nginx:ro \
  -v /opt/goaccess/data:/srv/data \
  -v /opt/goaccess/html:/srv/report \
  allinurl/goaccess:1.10.1 \
  --log-file=/var/log/nginx/access.log \
  --log-format=COMBINED \
  --output=/srv/report/index.html \
  --real-time-html \
  --ws-url=wss://stats.example.com \
  --port=7890

For persistent operation, create a docker-compose.yml:

services:
  goaccess:
    image: allinurl/goaccess:1.10.1
    restart: unless-stopped
    ports:
      - "7890:7890"
    volumes:
      - /var/log/nginx:/var/log/nginx:ro  # Mount your web server logs
      - goaccess-data:/srv/data
      - goaccess-html:/srv/report
    command: >
      --log-file=/var/log/nginx/access.log
      --log-format=COMBINED
      --output=/srv/report/index.html
      --real-time-html
      --ws-url=wss://stats.example.com
      --port=7890
      --persist
      --restore
      --db-path=/srv/data

volumes:
  goaccess-data:
  goaccess-html:

Serve the generated index.html from the goaccess-html volume through your reverse proxy, and use WebSocket passthrough for real-time updates.

GoAccess is best suited for operators who want analytics without touching their frontend code. For most self-hosters running content sites, Plausible or Umami will be more practical.

Adding the Tracking Script

Both Plausible and Umami work by adding a single <script> tag to your site.

Plausible

Add this to the <head> of every page:

<script defer data-domain="yoursite.com" src="https://analytics.example.com/js/script.js"></script>

Replace yoursite.com with the domain you registered in Plausible and analytics.example.com with your Plausible instance URL.

Plausible offers script extensions for additional tracking:

<!-- Track outbound link clicks -->
<script defer data-domain="yoursite.com" src="https://analytics.example.com/js/script.outbound-links.js"></script>

<!-- Track file downloads -->
<script defer data-domain="yoursite.com" src="https://analytics.example.com/js/script.file-downloads.js"></script>

<!-- Combine multiple extensions -->
<script defer data-domain="yoursite.com" src="https://analytics.example.com/js/script.outbound-links.file-downloads.js"></script>

Umami

Add this to the <head> of every page:

<script defer src="https://analytics.example.com/script.js" data-website-id="YOUR-WEBSITE-ID"></script>

The data-website-id is a UUID generated when you add the site in Umami's dashboard.

For custom event tracking:

// Track a button click
umami.track('signup-button-click');

// Track with properties
umami.track('download', { file: 'docker-compose.yml', format: 'yaml' });

Reverse Proxy Configuration

Run your analytics instance behind a reverse proxy on a subdomain like analytics.example.com or stats.example.com. This gives you HTTPS and keeps the analytics service isolated.

If you use Nginx Proxy Manager, create a new proxy host pointing to your analytics container's port (8000 for Plausible, 3000 for Umami). Enable SSL with Let's Encrypt.

For Caddy, add to your Caddyfile:

analytics.example.com {
    reverse_proxy localhost:8000  # or :3000 for Umami
}

For Nginx:

server {
    listen 443 ssl;
    server_name analytics.example.com;

    ssl_certificate /etc/letsencrypt/live/analytics.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/analytics.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;  # or :3000 for Umami
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # WebSocket support (needed for Plausible real-time)
    location /api/live/websocket {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

See Reverse Proxy Setup for detailed configuration guides.

Performance Impact

Privacy-friendly analytics scripts are dramatically smaller than Google's.

Script	Transfer Size	Requests	Blocking Time
Google Analytics (gtag.js)	~28 KB gzipped	2-3	~50-80 ms
Plausible	~0.8 KB gzipped	1	<5 ms
Umami	~2 KB gzipped	1	<5 ms
GoAccess	0 KB (no script)	0	0 ms

Both Plausible and Umami use the defer attribute, meaning the script loads asynchronously and never blocks page rendering. The performance difference is negligible on modern connections but adds up across millions of pageviews — fewer bytes served, lower CDN costs, faster Time to Interactive.

Common Mistakes

Running ClickHouse on a 1 GB RAM server. Plausible requires ClickHouse, which allocates significant memory at startup. Budget at least 2 GB total RAM for a Plausible stack. If you only have 1 GB, use Umami instead.

Forgetting to set DISABLE_REGISTRATION after creating your account. Both tools allow open registration by default. Lock this down immediately after creating your admin account or anyone who finds your analytics URL can create an account.

Using the old Plausible Docker Hub image. The plausible/analytics image on Docker Hub is frozen at v2.0.0 (July 2023). The current image is ghcr.io/plausible/community-edition on GitHub Container Registry. Using the old image means missing two years of features and security fixes.

Not configuring IP anonymization. Both tools hash or discard IP addresses by default, but verify this in your configuration. Storing raw IP addresses, even on your own server, has GDPR implications.

Exposing the analytics port directly. Always put your analytics instance behind a reverse proxy with HTTPS. Running on a bare HTTP port means your tracking data transits the network unencrypted.

Next Steps

Deploy your chosen analytics tool using the Docker Compose configs above
Add the tracking script to your site and verify data is flowing
Set up a reverse proxy with HTTPS for your analytics subdomain
Configure email (SMTP) if you want weekly reports from Plausible
Explore custom events in Umami for tracking specific user actions
For a deeper comparison, see Plausible vs Umami

Ghostfolio Vs Maybe

selfhosting.sh — Fri, 20 Mar 2026 02:58:04 +0000

Ghostfolio is a purpose-built portfolio tracker that pulls live market data, calculates performance metrics, and actively receives updates. Maybe aimed to combine budgeting and investment tracking but was archived in July 2025 after the founding company shut down. For self-hosted investment tracking in 2026, the choice is straightforward.

Overview

Ghostfolio focuses specifically on investment portfolio management — tracking stocks, ETFs, bonds, crypto, and other assets with automatic price updates via Yahoo Finance and other data providers. It shows allocation breakdowns, performance charts, dividend tracking, and net worth over time. Built with NestJS and Angular.

Maybe was a broader personal finance app covering budgeting, transaction tracking, and investment monitoring. It was built by a venture-backed startup that pivoted to open source before shutting down. The v0.6.0 release in July 2025 was the last, and the GitHub repository is archived.

Feature	Ghostfolio	Maybe
Focus	Investment portfolio tracking	All-in-one personal finance
Docker image	`ghostfolio/ghostfolio:2.250.0`	`ghcr.io/maybe-finance/maybe:0.6.0`
Language	TypeScript (NestJS + Angular)	Ruby on Rails
License	AGPL-3.0	AGPL-3.0
Actively maintained	Yes (weekly releases)	No (archived July 2025)
Market data	Yahoo Finance, manual, data providers	None (manual entry only)
Asset types	Stocks, ETFs, bonds, crypto, commodities, real estate	Stocks, crypto, real estate (basic)
Performance metrics	TWR, MWR, dividends, fees	Basic balance tracking
Allocation analysis	By asset class, region, sector, account	None
Multi-currency	Yes (automatic conversion)	Basic
Database	PostgreSQL + Redis	PostgreSQL
RAM usage	~200-350 MB	~300-500 MB
Benchmark comparison	Yes (compare against S&P 500, etc.)	No

Installation Complexity

Ghostfolio

Three containers — app, PostgreSQL, Redis:

services:
  ghostfolio:
    image: ghostfolio/ghostfolio:2.250.0
    container_name: ghostfolio
    environment:
      - DATABASE_URL=postgresql://ghostfolio:changeme-gf-db-pass@ghostfolio-db:5432/ghostfolio
      - REDIS_HOST=ghostfolio-redis
      - REDIS_PORT=6379
      - ACCESS_TOKEN_SALT=generate-random-string-here
      - JWT_SECRET_KEY=generate-another-random-string-here
    ports:
      - "3333:3333"
    depends_on:
      - ghostfolio-db
      - ghostfolio-redis
    restart: unless-stopped

  ghostfolio-db:
    image: postgres:15-alpine
    container_name: ghostfolio-db
    environment:
      - POSTGRES_DB=ghostfolio
      - POSTGRES_USER=ghostfolio
      - POSTGRES_PASSWORD=changeme-gf-db-pass
    volumes:
      - ./db:/var/lib/postgresql/data
    restart: unless-stopped

  ghostfolio-redis:
    image: redis:7-alpine
    container_name: ghostfolio-redis
    restart: unless-stopped

Default login: admin / Admin1234 — change immediately after first login.

Maybe

Two containers — app and PostgreSQL:

services:
  maybe:
    image: ghcr.io/maybe-finance/maybe:0.6.0
    container_name: maybe
    environment:
      - RAILS_ENV=production
      - SECRET_KEY_BASE=generate-a-64-char-hex-string
      - DB_HOST=maybe-db
      - DB_PORT=5432
      - DB_NAME=maybe
      - DB_USERNAME=maybe
      - DB_PASSWORD=changeme-maybe-db-pass
    ports:
      - "3000:3000"
    depends_on:
      - maybe-db
    restart: unless-stopped

  maybe-db:
    image: postgres:16-alpine
    container_name: maybe-db
    environment:
      - POSTGRES_DB=maybe
      - POSTGRES_USER=maybe
      - POSTGRES_PASSWORD=changeme-maybe-db-pass
    volumes:
      - ./db:/var/lib/postgresql/data
    restart: unless-stopped

Performance and Resource Usage

Metric	Ghostfolio	Maybe
Containers	3 (app + PostgreSQL + Redis)	2 (app + PostgreSQL)
RAM (idle)	~200 MB	~300 MB
RAM (under load)	~350 MB	~500 MB
Docker image size	~300 MB	~500 MB
Startup time	~10 seconds	~15-20 seconds
Market data updates	Automatic (configurable interval)	None

Ghostfolio's Redis dependency adds a container but barely impacts resources (~20 MB). Maybe's Rails stack is heavier despite doing less.

The Maintenance Reality

Ghostfolio ships weekly releases with:

New data provider integrations
Performance improvements
Bug fixes and security patches
New asset type support
UI improvements

Maybe has received zero updates since July 2025. Known issues include:

No security patches for Ruby on Rails dependencies
Gem vulnerabilities accumulating over time
No community maintaining the fork
API integrations (if any) breaking as external services change

Running Maybe means accepting increasing security risk with each passing month.

Use Cases

Choose Ghostfolio If...

You want automatic market data updates for your portfolio
Performance metrics (TWR, dividends, fees) matter to you
You want allocation analysis by sector, region, and asset class
Long-term support and regular updates are important
You want to benchmark your portfolio against indices

Choose Maybe If...

You want a combined budgeting + investment view (and accept unmaintained software)
You plan to fork and maintain the codebase yourself
You only need basic balance tracking without live market data
You're using it as a starting point for a custom Rails app

Final Verdict

If you need investment tracking, choose Ghostfolio — there's no practical alternative here. The question isn't which is better; it's whether you want maintained software with live market data or an abandoned project with manual entry only. Ghostfolio paired with Actual Budget covers both budgeting and investment tracking better than Maybe ever did alone.

FAQ

Can Ghostfolio track real estate?

Yes. Add real estate as a manual asset with periodic value updates. It won't pull Zillow estimates automatically, but you can record your property's value and track it alongside your financial portfolio.

Does Maybe support automatic market data?

The self-hosted version does not. The original SaaS product had Plaid integration, but that was never included in the open-source release.

Can I run both and migrate later?

Yes, but there's no built-in migration path. You'd export Maybe's data as CSV and manually re-enter positions in Ghostfolio. For new users, start with Ghostfolio directly.

Hoarder Vs Shiori

selfhosting.sh — Fri, 20 Mar 2026 01:18:03 +0000

Quick Verdict

Hoarder is the better choice if you save a lot of content and want AI to automatically tag and categorize it. Shiori is the better choice if you want a minimal, lightweight bookmark manager that archives full pages and runs on almost any hardware. They represent opposite ends of the bookmark manager spectrum — smart automation vs. bare-bones efficiency.

Overview

Hoarder is a relatively new bookmark manager that uses AI (via local models or OpenAI) to automatically tag and organize saved links. It focuses on the "save now, organize later" workflow — you dump links and let the AI figure out the categorization.

Shiori is a Go-based bookmark manager inspired by the old Pocket experience. It's a single binary with embedded SQLite — no external dependencies, no AI, no frills. You save pages, it archives the content for offline reading, and you tag things manually.

Feature Comparison

Feature	Hoarder	Shiori
Language	TypeScript (Next.js)	Go
License	AGPL-3.0	MIT
Database	SQLite or PostgreSQL	SQLite, PostgreSQL, or MySQL
AI tagging	Yes (local or OpenAI)	No
Auto-categorization	Yes (AI-powered)	No
Page archiving	Screenshots + text extraction	Full readable content
Browser extensions	Chrome, Firefox	Chrome (beta), Firefox
Mobile app	PWA + iOS/Android (beta)	PWA
CLI	No	Yes
API	Yes	Yes
Full-text search	Yes	Yes
Pocket import	Yes	Yes (Netscape format)
Multi-user	Yes	Limited
Docker image	~500 MB+	~30 MB
Minimum RAM	~512 MB	~30-50 MB

Installation Complexity

Hoarder requires more infrastructure. The Docker Compose includes the main app, a Chromium container for page screenshots, and optionally a local AI model (Ollama). The stack uses 500+ MB of RAM at minimum, and more with local AI inference.

Shiori runs as a single container with an embedded SQLite database. No external services needed. Total footprint is ~30-50 MB of RAM. You can run it on a Raspberry Pi Zero without issues.

Winner: Shiori. Dramatically simpler setup and smaller footprint.

Performance and Resource Usage

Metric	Hoarder	Shiori
RAM (idle)	~300-500 MB (with Chromium)	~30-50 MB
RAM (with AI)	~2-4 GB (with local Ollama)	N/A
CPU	Moderate (AI inference, rendering)	Very low
Disk	Screenshots + DB	Archived text + DB
Startup time	10-30 seconds	<2 seconds

Hoarder is 10-15x heavier on RAM due to the Chromium rendering engine and optional AI backend. If you're running on limited hardware or alongside many other services, this matters.

Winner: Shiori. Runs on almost any hardware.

Content Archiving

Both save page content, but differently:

Hoarder takes screenshots (visual snapshots) and extracts text. The screenshots provide a visual reference but can't be searched. Text extraction enables full-text search.
Shiori downloads and parses the full page into readable content (similar to Reader View in Firefox). The result is searchable text with formatting preserved, available for offline reading.

Winner: Shiori for offline reading and searchability. Hoarder for visual reference (screenshots show the exact page layout).

Organization

This is where they diverge most:

Hoarder's AI tagging analyzes saved content and applies tags automatically. You configure your preferred AI backend (OpenAI or local Ollama) and the AI processes each bookmark. The more you save, the more useful the automatic organization becomes.
Shiori's manual tagging requires you to add tags yourself when saving or editing bookmarks. It's predictable and doesn't require AI infrastructure.

Winner: Hoarder if you save dozens of links daily and don't want to categorize each one. Shiori if you prefer manual control and don't want AI dependencies.

Community and Support

Metric	Hoarder	Shiori
GitHub stars	~4,000	~11,000+
First release	2024	2019
Development pace	Very active	Steady (less frequent releases)
Contributors	Growing	67

Shiori has a longer track record and larger community. Hoarder is newer but developing rapidly.

Use Cases

Choose Hoarder If...

You save large volumes of content and hate manual tagging
You already run Ollama or have OpenAI API access
You want screenshot previews of saved pages
You prefer a modern Next.js UI
You have 512 MB+ RAM available for bookmark management

Choose Shiori If...

You want the lightest possible bookmark manager
You run on limited hardware (Raspberry Pi, small VPS)
You prefer offline-first archiving (full readable content)
You want a CLI for scriptable bookmark management
You don't need AI features
You value a battle-tested, mature project

Final Verdict

For most users saving bookmarks casually (10-20 per week), Shiori is the better choice — it does the job with minimal resources and no complexity. The full content archiving is genuinely useful for offline reading.

For power users who save 50+ links weekly and need help organizing them, Hoarder justifies its higher resource cost with AI tagging that saves real time. If you already run an AI stack, the marginal cost of adding Hoarder is minimal.

Frequently Asked Questions

Does Hoarder require a GPU for AI tagging?

No. Hoarder's AI tagging works with cloud APIs (OpenAI, Ollama) or local CPU-based models. A GPU accelerates local model inference but is not required. With Ollama on CPU, tagging takes a few seconds per bookmark instead of sub-second with a GPU.

Can Shiori archive pages for offline reading?

Yes. Shiori downloads and stores the full HTML content of saved pages. You can read archived pages even if the original site goes offline. The archive is stored locally in Shiori's database, not as separate files.

Does Hoarder have a browser extension?

Yes. Hoarder has browser extensions for Chrome and Firefox, plus a mobile app for iOS and Android. Shiori also has browser extensions but no official mobile app — you access it through the mobile browser.

How much storage does each tool use?

Shiori uses minimal storage — typically 10-50 MB for hundreds of bookmarks since it stores compressed HTML. Hoarder uses more storage due to AI embeddings and richer metadata — expect 100-500 MB for a similar collection, more if you enable screenshot archiving.

Can I import bookmarks from Pocket or Raindrop.io?

Both support importing bookmarks from HTML files (the standard browser bookmark export format). Hoarder also supports direct Pocket import. Neither has a built-in Raindrop.io importer, but exporting from Raindrop as HTML works.

Which is better for a team or family?

Hoarder supports multiple users with shared lists — better for collaborative use. Shiori is designed for single-user use. For shared bookmark management, also consider Linkwarden which has full team support with shared collections and permissions.

Wallabag Vs Pocket

selfhosting.sh — Thu, 19 Mar 2026 23:38:01 +0000

Quick Verdict

Wallabag is the best self-hosted alternative to Pocket. It replicates Pocket's core experience — save articles, read them later in a clean interface — while giving you full data ownership. The mobile apps are less polished than Pocket's, but the reading experience, tagging, and export capabilities are equivalent or better.

Updated March 2026: Verified with latest Docker images and configurations.

Overview

Pocket (owned by Mozilla since 2017) is the most popular read-later service. The free tier is generous, but the Premium plan ($44.99/year) adds full-text search, permanent library, and suggested tags. Pocket's main concern is privacy: it tracks reading habits, integrates with Mozilla's recommendation engine, and stores all your data on their servers.

Wallabag is a self-hosted read-later application written in PHP (Symfony). It extracts readable content from web pages, strips ads and clutter, and presents a clean reading interface. It includes browser extensions, mobile apps, and API access — all for $0 and full privacy.

Feature Comparison

Feature	Pocket (Premium)	Wallabag
Price	$44.99/year	Free (self-hosted)
Article saving	Yes	Yes
Reader view	Yes	Yes (content extraction)
Full-text search	Premium only	Yes (built-in)
Tagging	Yes + suggested tags (Premium)	Yes (manual)
Permanent library	Premium only	Yes (all articles archived)
Browser extensions	Chrome, Firefox, Safari	Chrome, Firefox
Mobile apps	iOS, Android (polished)	iOS, Android (functional)
Offline reading	Yes (mobile)	Yes (mobile apps)
RSS feed of saves	No	Yes (per-tag RSS feeds)
Export	HTML only	JSON, CSV, XML, EPUB, PDF
API	Yes	Yes (full REST API)
Annotations	No	Yes (text highlighting)
Text-to-speech	Yes (Premium)	No
Dark mode reading	Yes	Yes
Sharing	To social media	Public links + social
Multi-user	No (per-account)	Yes
Integrations	IFTTT, Zapier	Many via API
Data location	Mozilla's servers	Your server

Reading Experience

Both extract readable content from web pages. Pocket's extraction is slightly more reliable on complex sites (JavaScript-heavy pages, paywalled content), but Wallabag handles most sites well. Both offer:

Adjustable font size and family
Dark/light/sepia reading modes
Estimated reading time
Progress tracking

Wallabag adds text annotations (highlight passages and add notes) — a feature Pocket doesn't offer at any tier.

Privacy

This is the primary reason to switch:

Pocket tracks which articles you read, how long you spend reading, and what you save. This data feeds Mozilla's recommendation engine ("Pocket Recommendations" in Firefox). Pocket's privacy policy allows sharing usage data with third parties.
Wallabag stores everything on your server. No tracking, no recommendations engine, no data sharing. Your reading habits are yours alone.

Mobile Experience

Pocket's mobile apps are genuinely better — smoother animations, better content rendering, offline sync that "just works." Wallabag's mobile apps (available on both iOS and Android) are functional but feel like a web wrapper. They support offline reading, but the sync mechanism occasionally needs manual triggering.

If mobile reading is your primary use case, this is the biggest trade-off.

Installation Complexity

Wallabag requires:

PHP 8.x with several extensions
PostgreSQL, MySQL, or SQLite
Redis or RabbitMQ (optional, for async processing)

Docker Compose simplifies this:

services:
  wallabag:
    image: wallabag/wallabag:2.6.14
    container_name: wallabag
    environment:
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_pgsql
      - SYMFONY__ENV__DATABASE_HOST=db
      - SYMFONY__ENV__DATABASE_PORT=5432
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=wallabag
      - SYMFONY__ENV__DATABASE_PASSWORD=wallabag_password
      - SYMFONY__ENV__DOMAIN_NAME=https://read.yourdomain.com
      - SYMFONY__ENV__SECRET=change-this-to-a-random-string
    ports:
      - "8080:80"
    depends_on:
      - db
      - redis
    restart: unless-stopped

  db:
    image: postgres:17-alpine
    environment:
      - POSTGRES_USER=wallabag
      - POSTGRES_PASSWORD=wallabag_password
      - POSTGRES_DB=wallabag
    volumes:
      - wallabag_db:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    restart: unless-stopped

volumes:
  wallabag_db:

Migration from Pocket

Export from Pocket: Go to getpocket.com/export and download the HTML file
Import to Wallabag: In Wallabag, navigate to Import > Pocket and upload the file
Articles, tags, and read/unread status are preserved
Wallabag re-fetches article content for its own archive

Wallabag also supports importing from Instapaper, Readability, and browser bookmarks.

Cost Comparison

	Pocket Free	Pocket Premium	Wallabag
Monthly cost	$0	$3.75	~$3 (VPS share)
Annual cost	$0	$44.99	~$36 (VPS share)
3-year cost	$0	$134.97	~$108 (VPS share)
Full-text search	No	Yes	Yes
Permanent copies	No	Yes	Yes
Data ownership	No	No	Yes

If you already run a homelab or VPS for other services, Wallabag's marginal cost is effectively $0.

What You Give Up

Pocket's mobile app quality — Pocket's apps are more polished and reliable for offline sync
Text-to-speech — Pocket Premium includes article narration
Pocket Recommendations — If you use Firefox's recommended articles feed, you lose that
Tag suggestions — Pocket Premium suggests tags automatically; Wallabag requires manual tagging
Zero maintenance — Self-hosting means managing updates, backups, and server uptime

Frequently Asked Questions

Can Wallabag import my Pocket articles?

Yes. Wallabag has a built-in Pocket import tool. Connect your Pocket account via OAuth, and Wallabag will import all your saved articles with tags and archive status preserved. The import takes a few minutes for large libraries.

Does Wallabag have a mobile app?

Yes. Wallabag has official apps for Android and iOS. The apps support offline reading and syncing. They are functional but less polished than Pocket's apps.

Is Wallabag hard to maintain?

Wallabag is a PHP/Symfony application with a database (PostgreSQL, MySQL, or SQLite). Updates are straightforward with Docker (docker compose pull && docker compose up -d). The main maintenance tasks are database backups and occasional PHP dependency updates.

Can Wallabag tag articles automatically?

Not natively. Wallabag supports tagging rules — you can define rules like "if domain contains 'github.com', add tag 'dev'" — but it doesn't have AI-powered auto-tagging like Hoarder. For manual tagging, the browser extension lets you add tags at save time.

What is Wallabag's Kindle integration?

Wallabag can send articles to your Kindle via Amazon's Send-to-Kindle email address. Configure your Kindle email in Wallabag settings, and articles are delivered in a Kindle-optimized format. This is one of the most popular features for e-reader users.

Does Wallabag support RSS feeds?

Yes. Each tag, starred collection, and archive in Wallabag has an RSS feed URL. You can subscribe to these feeds in your RSS reader to follow saved articles across tools.

Actual Budget Vs Maybe

selfhosting.sh — Thu, 19 Mar 2026 21:48:00 +0000

Want a self-hosted finance app that actively gets better? Actual Budget is the only serious choice between these two. Maybe showed promise as a modern portfolio tracker, but development stopped in mid-2025 and the project is no longer maintained.

Overview

Actual Budget is an envelope budgeting app — you assign every dollar a purpose, track spending against categories, and sync across devices. It started as a paid SaaS product, went open source in 2022, and now has an active community maintaining it. The sync server is lightweight and the web app works offline.

Updated March 2026: Verified with latest Docker images and configurations.

Maybe was a modern personal finance tracker that aimed to combine budgeting, investment tracking, and net worth monitoring in one app. Built with Ruby on Rails by a funded startup, it was open-sourced after the company shut down. The last release (v0.6.0) shipped in July 2025, and the repository is now archived.

Feature	Actual Budget	Maybe
Primary focus	Envelope budgeting	Portfolio + net worth tracking
Docker image	`actualbudget/actual-server:26.3.0`	`ghcr.io/maybe-finance/maybe:0.6.0`
Language	Node.js	Ruby on Rails
License	MIT	AGPL-3.0
Actively maintained	Yes (weekly updates)	No (archived July 2025)
Database	SQLite (built-in)	PostgreSQL
Bank syncing	GoCardless (EU), SimpleFIN (US)	None in self-hosted version
Offline support	Yes (local-first architecture)	No
Multi-device sync	Yes (via sync server)	Yes (web app)
Investment tracking	No	Yes
RAM usage	~50-80 MB	~300-500 MB
Mobile app	PWA (installable)	Responsive web only
Import formats	OFX, QFX, QIF, CSV	CSV

Installation Complexity

Actual Budget

One container, no external database needed. SQLite handles everything:

services:
  actual-budget:
    image: actualbudget/actual-server:26.3.0
    container_name: actual-budget
    ports:
      - "5006:5006"
    volumes:
      - ./data:/data
    restart: unless-stopped

Start it, open the web UI, create a budget file. Working in under 60 seconds.

Maybe

Requires PostgreSQL and more configuration:

services:
  maybe:
    image: ghcr.io/maybe-finance/maybe:0.6.0
    container_name: maybe
    environment:
      - RAILS_ENV=production
      - SECRET_KEY_BASE=generate-a-64-char-hex-string-here
      - DB_HOST=maybe-db
      - DB_PORT=5432
      - DB_NAME=maybe
      - DB_USERNAME=maybe
      - DB_PASSWORD=changeme-maybe-db-pass
    ports:
      - "3000:3000"
    depends_on:
      - maybe-db
    restart: unless-stopped

  maybe-db:
    image: postgres:16-alpine
    container_name: maybe-db
    environment:
      - POSTGRES_DB=maybe
      - POSTGRES_USER=maybe
      - POSTGRES_PASSWORD=changeme-maybe-db-pass
    volumes:
      - ./db:/var/lib/postgresql/data
    restart: unless-stopped

Default credentials: user@maybe.local / password. Functional, but expect no bug fixes or security patches going forward.

Performance and Resource Usage

Metric	Actual Budget	Maybe
Docker image size	~150 MB	~500 MB
RAM (idle)	~50 MB	~300 MB
RAM (under load)	~80 MB	~500 MB
CPU	Negligible	Low-medium (Rails)
Database	SQLite (no extra container)	PostgreSQL (separate container)
Startup time	~3 seconds	~15-20 seconds
Minimum server	256 MB RAM	1 GB RAM

Actual Budget is dramatically lighter. Its local-first architecture means the sync server does minimal work — the heavy lifting happens in the browser's IndexedDB.

The Maintenance Problem

This is the decisive factor. Actual Budget has:

Weekly releases with bug fixes and features
Active GitHub community (500+ contributors)
Regular security updates
New bank connection integrations being added
Responsive issue tracker

Maybe has:

No updates since July 2025
Repository archived on GitHub
Known bugs will never be fixed
No security patches
Dependencies will gradually become vulnerable

Running unmaintained software on your network with access to financial data is a risk that compounds over time.

Use Cases

Choose Actual Budget If...

You want envelope-style budgeting (the YNAB methodology)
Long-term maintenance and security updates matter
You want bank syncing (GoCardless for European banks, SimpleFIN for US)
You need offline access and mobile PWA support
You want the lightest possible deployment

Choose Maybe If...

You specifically want net worth and investment portfolio tracking
You understand the risks of running unmaintained software
You're willing to fork and maintain it yourself
You need a starting point for a custom finance app (Rails codebase)

Final Verdict

The practical choice is Actual Budget because it's actively maintained, lighter on resources, and more mature for day-to-day budgeting. Maybe's investment tracking features are genuinely useful, but a project that stopped receiving updates — including security patches — isn't something you should run long-term with access to sensitive financial data. For investment tracking, consider Ghostfolio alongside Actual Budget instead.

FAQ

Can Actual Budget track investments?

No. Actual Budget is focused on envelope budgeting and expense tracking. For investment portfolio tracking, pair it with Ghostfolio.

Is Maybe safe to run if it's unmaintained?

The code works, but dependencies won't receive security patches. If you isolate it on a private network and accept the risk, it functions. Don't expose it to the internet without a reverse proxy and network segmentation.

Can I import data from Maybe into Actual Budget?

Not directly. You'd need to export from Maybe as CSV, then reformat the CSV to match Actual Budget's import expectations. The data models are different — Maybe tracks net worth and assets, while Actual Budget tracks income and expenses by category.

Forgejo Vs Gitlab Ce

selfhosting.sh — Thu, 19 Mar 2026 20:18:00 +0000

If you need a Git server that does one thing well and runs on minimal hardware, Forgejo is the clear winner. If you need an integrated DevOps platform with built-in CI/CD, container registry, and project management — and have the RAM to spare — GitLab CE is the full-stack option.

Overview

Forgejo is a community-governed fork of Gitea, itself a fork of Gogs. It's a lightweight Git forge written in Go that provides repository hosting, pull requests, issue tracking, and GitHub Actions-compatible CI/CD. The project is governed by the Codeberg e.V. nonprofit, emphasizing community ownership over corporate control.

Updated March 2026: Verified with latest Docker images and configurations.

GitLab Community Edition is the open-source version of the GitLab DevOps platform. It bundles Git hosting with CI/CD pipelines, container registries, package management, issue boards, wikis, and dozens of other features into a single monolithic Ruby on Rails application.

Feature Comparison

Feature	Forgejo	GitLab CE
Language	Go	Ruby on Rails
License	GPL-3.0 (copyleft)	MIT (Expat)
Docker image	`codeberg.org/forgejo/forgejo:14.0.3`	`gitlab/gitlab-ce:18.9.2-ce.0`
RAM (idle)	~120 MB	~4 GB
RAM (recommended)	512 MB	8 GB
Startup time	~5 seconds	3-5 minutes
Built-in CI/CD	Forgejo Actions (GitHub Actions-compatible)	GitLab CI/CD (native `.gitlab-ci.yml`)
Container registry	Yes (basic)	Yes (advanced, integrated with CI)
Package registry	Yes (npm, Maven, PyPI, Cargo, etc.)	Yes (extensive, 15+ formats)
Issue tracking	Yes	Yes (with boards, weights, milestones)
Wiki	Yes (Git-backed)	Yes (Git-backed)
Git LFS	Yes	Yes
Federation	ActivityPub (experimental)	None
SSO/LDAP	LDAP, OAuth2, OIDC	LDAP, SAML, OAuth2, OIDC, Kerberos
Webhooks	Forgejo, Gitea, Slack, Discord, Teams	Extensive (push, merge, pipeline, etc.)
Project management	Basic (issues + milestones)	Advanced (boards, epics, roadmaps)

Installation Complexity

Forgejo

Two containers — Forgejo and PostgreSQL. Runs comfortably on 512 MB RAM:

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:14.0.3
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=forgejo-db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=changeme-forgejo-db-pass
    volumes:
      - ./data:/data
    ports:
      - "3000:3000"
      - "2222:22"
    depends_on:
      - forgejo-db
    restart: unless-stopped

  forgejo-db:
    image: postgres:16-alpine
    container_name: forgejo-db
    environment:
      - POSTGRES_DB=forgejo
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=changeme-forgejo-db-pass
    volumes:
      - ./db:/var/lib/postgresql/data
    restart: unless-stopped

GitLab CE

One massive container with everything bundled. Needs 4 GB RAM minimum, 8 GB recommended:

services:
  gitlab:
    image: gitlab/gitlab-ce:18.9.2-ce.0
    container_name: gitlab
    hostname: gitlab.example.com
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.example.com'
        gitlab_rails['lfs_enabled'] = true
        # Reduce memory: disable monitoring
        prometheus_monitoring['enable'] = false
        # SSH on custom port
        gitlab_rails['gitlab_shell_ssh_port'] = 2424
    ports:
      - "80:80"
      - "443:443"
      - "2424:22"
    volumes:
      - ./config:/etc/gitlab
      - ./logs:/var/log/gitlab
      - ./data:/var/opt/gitlab
    shm_size: "256m"
    restart: unless-stopped

GitLab's Omnibus container includes PostgreSQL, Redis, Sidekiq, Puma, Nginx, and Gitaly — all in one image. This simplifies deployment but means everything scales together (or doesn't).

Performance and Resource Usage

This is where the difference is stark:

Metric	Forgejo	GitLab CE
Docker image size	~100 MB	~3 GB
RAM (idle)	~120 MB	~3.5-4 GB
RAM (under load)	~350 MB	~6-8 GB
CPU (idle)	Negligible	~5-10% (background jobs)
Startup time	5-10 seconds	3-5 minutes
Disk (application)	~200 MB	~5 GB
Minimum viable server	1 vCPU, 512 MB RAM	2 vCPU, 4 GB RAM

Forgejo runs on a Raspberry Pi 4. GitLab CE struggles below 4 GB RAM — if you disable Prometheus monitoring (prometheus_monitoring['enable'] = false), you can reclaim ~300 MB, but it still demands significantly more resources.

For teams under 20 developers, Forgejo handles Git operations, CI, and package hosting without breaking a sweat on a $5/month VPS. GitLab CE needs a $20-40/month server to run comfortably.

CI/CD

Forgejo Actions

Compatible with GitHub Actions workflow syntax. You deploy a separate runner container (codeberg.org/forgejo/runner:6.3.1) that picks up jobs defined in .forgejo/workflows/ or .github/workflows/ YAML files. Most GitHub Actions from the marketplace work with minor adjustments.

GitLab CI/CD

Native pipeline system using .gitlab-ci.yml. Deeply integrated — pipelines can trigger deployments, publish to the container registry, run security scans, and manage environments. The CI/CD system is more mature and has features like DAG pipelines, parent-child pipelines, and multi-project pipelines that Forgejo Actions doesn't match.

If you're migrating from GitHub Actions, Forgejo is easier. If you need advanced CI/CD orchestration, GitLab's pipeline system is more capable.

Community and Ecosystem

Forgejo is governed by Codeberg e.V., a German nonprofit. Development is transparent and community-driven. The project guarantees it will never become a commercial product. Federation via ActivityPub is an active development area — Forgejo aims to let instances communicate across the Fediverse.

GitLab CE is maintained by GitLab Inc., a publicly traded company. The CE edition gets features after the paid tiers (EE, Premium, Ultimate). Some features available in Forgejo's free tier are paywalled in GitLab (e.g., certain security scanning, compliance features). However, GitLab's ecosystem is vastly larger — more integrations, more documentation, and more third-party tooling.

Use Cases

Choose Forgejo If...

You want a lightweight Git server that runs on modest hardware
You're migrating from GitHub and want compatible Actions CI/CD
Community governance and nonprofit ownership matter to you
You're hosting personal projects or a small team (under 50 developers)
Federation and Fediverse integration interest you
You need multiple instances on limited server resources

Choose GitLab CE If...

You need a complete DevOps platform, not just Git hosting
Your team uses advanced CI/CD features (DAG pipelines, environments, review apps)
You need integrated container and package registries tightly coupled with CI
You have 4+ GB RAM available and don't mind the resource footprint
You need enterprise SSO (SAML, Kerberos) beyond basic OAuth/OIDC
Your organization already uses GitLab and you want to self-host

Final Verdict

Forgejo wins on efficiency — it's 30x lighter on RAM and starts in seconds. For personal projects, small teams, and anyone on constrained hardware, there's no reason to absorb GitLab's overhead. GitLab CE wins when you genuinely need the DevOps platform: integrated CI/CD pipelines, security scanning, container registries, and project management in one tool. If you're only using GitLab for Git hosting and basic CI, you're paying a steep resource tax for features you don't use.

FAQ

Can I migrate repositories from GitLab to Forgejo?

Yes. Forgejo has a built-in migration tool that imports repositories, issues, pull requests, labels, and milestones from GitLab, GitHub, Gitea, and other platforms.

Does Forgejo support GitLab CI/CD syntax?

No. Forgejo Actions uses GitHub Actions syntax (.github/workflows/), not .gitlab-ci.yml. You'd need to rewrite CI pipelines if migrating from GitLab.

Can GitLab CE run on a Raspberry Pi?

Technically possible on a Pi 5 with 8 GB RAM, but not recommended. Background jobs alone consume 2-3 GB. Forgejo is a much better fit for ARM hardware.

Is Forgejo compatible with Gitea?

Yes. Forgejo forked from Gitea in late 2022 and maintains compatibility with Gitea's API and plugin ecosystem. Most Gitea themes and plugins work with Forgejo.

Forem: selfhosting.sh

Pushover

Why Replace Pushover?

Best Alternatives

ntfy — Best Overall Replacement

Gotify — Best for Simple Setups

Apprise — Best for Multi-Platform Routing

Migration Guide

Pushover API Call

ntfy Equivalent

Gotify Equivalent

Cost Comparison

What You Give Up

FAQ

Does ntfy work with Home Assistant, Uptime Kuma, and other self-hosted tools?

Can ntfy send notifications to iOS devices?

How do I secure ntfy so random people can't send me notifications?

Can I use ntfy or Gotify as a replacement for SMS notifications?

How much server resources does a self-hosted notification server need?

Can I migrate my Pushover integrations to ntfy without breaking everything?

Is there a way to route one notification to multiple platforms simultaneously?

Related

Paperless Ngx Vs Teedy

Quick Verdict

Overview

Feature Comparison

Document Ingestion

Docker Setup Comparison

Resource Usage

Search Capabilities

Security

Use Cases

Choose Paperless-ngx If...

Choose Teedy If...

Final Verdict

Related

Matrix Vs Discord

Quick Verdict

Overview

Feature Comparison

Voice and Video Quality

Bot and Integration Ecosystem

Community Management

Privacy and Data Ownership

Self-Hosting Requirements

Use Cases

Choose Matrix If...

Choose Discord If...

Bridging: The Best of Both Worlds

Final Verdict

Related

Nextcloud Upload Limit

The Problem

The Cause

The Fix

Method 1: PHP Configuration (Docker)

Method 2: PHP Configuration (Non-Docker)

Method 3: Nginx Reverse Proxy

Method 4: Nginx Proxy Manager

Method 5: Apache Reverse Proxy

Method 6: Nextcloud Admin Settings

Verify the Fix

Prevention

Related

Syncthing Not Connecting

The Problem

The Cause

The Fix

Method 1: Fix Firewall Rules (Most Common)

Method 2: Fix NAT/Router Configuration

Method 3: Force Relay Connections

Method 4: Verify Device IDs

Method 5: Check Listen Address

Prevention

Related

Splitwise

Why Replace Splitwise?

Best Alternatives

IHateMoney — Best Overall Replacement

Firefly III — Best for All-in-One Finance