Vincent/Obsidian-Vault

Fork 0

Files

Vincent Verbruggen fd37421245 Init

2025-10-25 20:11:21 +02:00

15 KiB

Raw Blame History

Alternatives Considered - Oracle Cloud Project

Date: 2025-10-25 Status: Archived for reference

This document captures the alternatives we researched but decided not to pursue for this project.

Git Server: Forgejo vs Gitea

Decision: Chose Gitea ✅ Rationale: CapRover one-click support, faster setup, adequate for personal use

Forgejo Deep Dive

What is Forgejo:

Community-driven fork of Gitea (since Oct 2022)
Managed by non-profit Codeberg e.V.
Hard fork as of v10.0 (Jan 2025)

Why Forgejo Would Be Better:

Security Practices:
- Public security advisories for everyone (vs Gitea's paying-customers-only)
- Proactive disclosure to Gitea team before public release
- Faster vulnerability patching
- Example: At FOSDEM 2025, demonstrated Forgejo Runner fixed all security issues while Gitea Runner remains vulnerable
Development Activity (2024-2025):
- 232 contributors vs Gitea's 153
- 3,039 commits vs Gitea's 1,228 (last 12 months)
- 2.5x more active development
- More frequent releases
Governance:
- Community-governed non-profit
- No corporate control
- Free/libre software commitment
- Developed using Forgejo (dogfooding)
Features (v10.0, Jan 2025):
- Revamped repository dialog
- Modify Git notes via API/UI
- Markdown table creation button
- Consolidated issues/PRs view
- Improved TOTP security (keying module)

Why We Didn't Choose Forgejo:

No CapRover one-click app (only feature request from Dec 2023)
Manual Docker Compose setup required (15-30 minutes vs 5 minutes)
Smaller user base (less community support)
Harder fork = no easy migration path from Gitea after v1.22
Overkill for personal knowledge repository hosting

Security Concerns with Gitea:

Advanced security notices only for paying customers
Feb 2024: Published vulnerability fix embedded in large refactor, breaking embargo
Prioritized SOC2 audit (for SaaS business) over critical community releases
"Repeatedly leaves admins exposed to known vulnerabilities for extended periods"

When to Reconsider Forgejo:

If hosting sensitive/production code
If security transparency is critical
If supporting FOSS governance matters to you
If you don't mind manual Docker setup

Manual Forgejo Deployment on CapRover:

# Custom CapRover app definition
services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:10
    restart: always
    volumes:
      - forgejo-data:/data
    ports:
      - "3000:3000"
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__database__DB_TYPE=sqlite3
volumes:
  forgejo-data:

Migration Path (if needed later):

Gitea v1.22 or below can migrate to Forgejo
After Gitea v1.23, migration no longer supported
CapRover Gitea is on v1.21.1, so migration possible

Resources:

Container Management: Alternatives to CapRover

Decision: Chose CapRover ✅ Rationale: Best PaaS experience, one-click apps, built-in reverse proxy + SSL

Alternative 1: Portainer CE

What it is: Full-featured Docker/Kubernetes management GUI

Pros:

Most mature container management tool
Excellent documentation and large community
Full granular control over Docker
Multi-environment support
Good mobile interface
App templates included

Cons:

Need separate reverse proxy (Traefik/Nginx Proxy Manager)
Manual SSL configuration for each app
More complex setup for each service
Community edition has limitations vs Business edition
Not a PaaS - focuses on container management, not app deployment

Best for: Deep Docker infrastructure control, learning Docker internals

Why we didn't choose it:

User wanted "TrueNAS-like app store experience"
More manual work per app deployment
No built-in reverse proxy or SSL automation

Alternative 2: Dockge

What it is: Lightweight Docker Compose stack manager with modern UI

Pros:

Modern, fast, clean interface
Built specifically for docker-compose stacks
Direct compose.yaml editing with syntax highlighting
Real-time container logs
Interactive terminal
Very lightweight (~100MB RAM)

Cons:

Newer/less battle-tested
Need separate reverse proxy
No app marketplace or templates
Focused on stacks, less granular container control
Smaller community

Best for: Docker Compose power users who want modern UX

Why we didn't choose it:

No one-click app marketplace
Still requires manual configuration for each service
Not a full PaaS solution

Alternative 3: Coolify

What it is: Modern self-hosted PaaS (Heroku/Vercel alternative)

Pros:

Most similar to Vercel/Netlify experience
Deploy directly from Git repos
Built-in database management
Automatic SSL, backups, monitoring
Modern UI and active development
Growing community

Cons:

Heavier resource usage (~500MB+ for Coolify itself)
More complex initial setup
More opinionated (less flexibility)
Newer than CapRover (less mature)

Best for: Modern PaaS experience with Git-based deployments

Why we didn't choose it:

Higher resource overhead
CapRover is lighter and more established
CapRover has larger one-click app marketplace

Alternative 4: Traditional Stack (Portainer + Nginx Proxy Manager)

What it is: Combine Portainer for container management with NPM for reverse proxy

Pros:

Best of both worlds
Beautiful GUI for proxy management (NPM)
Full container control (Portainer)
Clean separation of concerns
Easy SSL certificate management in NPM

Cons:

Two separate tools to learn and manage
More initial setup complexity
Still no one-click app deployment
Manual configuration for each service

Best for: Those who want clean architecture with dedicated proxy GUI

Why we didn't choose it:

More complexity than needed
No app marketplace
CapRover combines both in one tool

Alternative 5: Yacht

What it is: Template-focused Docker management with modern UI

Pros:

Beautiful, modern interface
Strong template system for one-click deployments
Good for deploying common apps quickly
Active development

Cons:

Less mature than Portainer or CapRover
Smaller ecosystem and community
Need separate reverse proxy
Limited compared to CapRover's marketplace

Best for: Simple deployments with nice UI

Why we didn't choose it:

CapRover has more features and larger app catalog
Yacht still needs separate proxy setup

Container Runtime: Docker vs Podman

Decision: Chose Docker ✅ Rationale: Required by CapRover (Docker Swarm dependency)

Podman Analysis

What is Podman:

Daemonless, rootless container engine
Drop-in replacement for Docker
Better security model (rootless by default)
Kubernetes-native (generates K8s YAML from pods)

Advantages of Podman:

Rootless by default - containers run as non-privileged users
No daemon - no dockerd background process (reduced attack surface)
Kubernetes-native - easier path to K8s if needed
Oracle Linux native - officially supported on Oracle's OS
Better security - no root daemon, container breakout harder

Why NOT Podman:

❌ CapRover incompatible - CapRover requires Docker Swarm
❌ Podman explicitly won't implement Swarm - architectural decision
❌ Less GUI tooling - Portainer has limited Podman support
❌ Smaller ecosystem - fewer tutorials and solutions
❌ Docker Compose compatibility - improved but not 100%

CapRover + Podman = Impossible: From CapRover GitHub discussions:

"CapRover is built with Docker Swarm, and Podman has docker-compose capability now, but it seems explicitly unwilling to implement swarm capabilities."

When to Use Podman:

CLI-only workflow (no GUI needed)
Maximum security is paramount (defense/aerospace)
Running rootless containers is hard requirement
Deploying to Kubernetes eventually (Podman → K8s YAML)
Oracle Linux and want native tooling

Rootless Docker Alternative: If you want rootless security with Docker:

Docker has rootless mode (not default, but available)
Run: dockerd-rootless-setuptool.sh install
Not as mature as Podman's implementation
Some features limited (like Swarm)

Verdict: Docker is required for CapRover. If you want better security, consider Docker's rootless mode after setup, but be aware of limitations.

Reverse Proxy: Alternatives to CapRover's Built-in Nginx

Decision: Use CapRover's built-in proxy ✅ Rationale: Automatic, integrated with app deployments, no separate setup

Alternative 1: Traefik

What it is: Modern, cloud-native reverse proxy and load balancer

Pros:

Automatic service discovery via Docker labels
Built-in Let's Encrypt support (automatic SSL)
Modern architecture, designed for dynamic containers
Great for microservices
Dashboard for monitoring

Cons:

Steeper learning curve
Configuration via Docker labels can be verbose
Requires manual setup and configuration
Need to manage separately from apps

Example configuration:

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.app.rule=Host(`app.yourdomain.com`)"
  - "traefik.http.routers.app.entrypoints=websecure"
  - "traefik.http.routers.app.tls.certresolver=letsencrypt"

Best for: Dynamic container environments, microservices, learning modern proxy tech

Why we didn't choose it: CapRover already provides this functionality automatically

Alternative 2: Caddy

What it is: Web server with automatic HTTPS

Pros:

Zero-config HTTPS - automatically gets Let's Encrypt certificates
Simple Caddyfile syntax (easier than Nginx)
Built-in reverse proxy
Great for simple setups
Modern and actively developed

Cons:

Less dynamic than Traefik (more manual config per service)
Need to restart/reload for config changes
Less automation than CapRover's approach

Example Caddyfile:

app.yourdomain.com {
    reverse_proxy localhost:3000
}

Best for: Simple setups, users who want easy HTTPS without complexity

Why we didn't choose it: Still manual configuration, CapRover does this automatically

Alternative 3: Nginx Proxy Manager

What it is: Nginx with beautiful GUI for managing proxies and SSL

Pros:

Beautiful web GUI - easiest to use visually
Point-and-click SSL certificate management
Great for beginners
Visual workflow for adding services
Nice dashboard

Cons:

Another container to deploy and manage
Less automation than Traefik or CapRover
Manual configuration for each service (though via GUI)
Separate tool to learn

Best for: Users who prefer GUI over config files, clean architecture

Why we didn't choose it: CapRover already does this, adding NPM would be redundant

Domain Strategy: Alternatives to Cloudflare

Decision: Use existing Cloudflare domain ✅ Rationale: Already owned, free DNS, reliable

Alternative 1: DuckDNS

What it is: Free dynamic DNS service

Pros:

Completely free (subdomain + DNS)
Simple setup
Good for testing/personal projects
No account needed (just a token)

Cons:

Shared domain (yourname.duckdns.org)
Less professional
Limited to single subdomain or wildcard

Setup:

yourname.duckdns.org → Your Oracle IP
*.yourname.duckdns.org → Your Oracle IP

Best for: Testing, don't want to buy domain, quick setup

Why we didn't choose it: User already has Cloudflare domain

Alternative 2: Tailscale (Private Network)

What it is: Zero-config VPN / mesh network

Pros:

Most secure - no public exposure at all
Access services via private Tailscale network only
Free for personal use (up to 100 devices)
Works on iPad easily
No need for public SSL certs (can use Tailscale HTTPS)

Cons:

Services only accessible via Tailscale (not public internet)
Need Tailscale installed on all devices
More complex for sharing with others
Not traditional "cloud hosting"

Setup:

# Install Tailscale on Oracle VM
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Access services via Tailscale IPs
http://100.x.x.x:3000 (CapRover)

Best for: Maximum security, private development, accessing from specific devices only

Why we didn't choose it: User wants public access from anywhere (not just Tailscale network)

Alternative Architectures

Multi-VM Architecture

What it is: Split services across multiple ARM VMs (Oracle Free Tier allows up to 4 ARM cores total, divisible)

Example:

VM1 (1 core, 6GB RAM):
  - CapRover
  - Nginx Proxy Manager
  - Monitoring

VM2 (3 cores, 18GB RAM):
  - Gitea
  - code-server
  - Application containers

Pros:

Isolation between management and apps
Can rebuild one VM without affecting the other
Better resource allocation
Failure isolation

Cons:

More complex networking setup
Two VMs to manage and secure
Network latency between VMs
More complex backup strategy
Overkill for personal use

Why we didn't choose it: Single VM is simpler and sufficient for personal use case

Kubernetes (K3s) on Oracle Cloud

What it is: Lightweight Kubernetes distribution

Pros:

Industry-standard orchestration
Scalable architecture
Great learning experience
Better for microservices

Cons:

Massive overkill for this use case
Much more complex to set up and manage
Higher resource overhead
Steeper learning curve
No "one-click apps" like CapRover

Why we didn't choose it: Far too complex for personal Git + code-server setup

Summary: Why Our Chosen Stack Wins

Requirement	Our Choice	Why It Wins
Git Server	Gitea	CapRover one-click, 5 min setup vs 30 min manual
Code Editor	code-server	Proven iPad PWA support, Claude Code extension works
Container Platform	CapRover	One-click apps, built-in proxy+SSL, TrueNAS-like UX
Container Runtime	Docker	Required by CapRover (Swarm dependency)
Reverse Proxy	CapRover's Nginx	Automatic, zero config, integrated
SSL	Let's Encrypt (via CapRover)	Automatic, free, renewal handled
Domain	Existing Cloudflare	Already owned, free DNS

Result: Complete iPad dev environment in ~3-4 hours vs days/weeks with alternatives

This document is for reference only. See IMPLEMENTATION_PLAN.md for what we're actually building.

15 KiB Raw Blame History

Alternatives Considered - Oracle Cloud Project

Git Server: Forgejo vs Gitea

Forgejo Deep Dive

Container Management: Alternatives to CapRover

Alternative 1: Portainer CE

Alternative 2: Dockge

Alternative 3: Coolify

Alternative 4: Traditional Stack (Portainer + Nginx Proxy Manager)

Alternative 5: Yacht

Container Runtime: Docker vs Podman

Podman Analysis

Reverse Proxy: Alternatives to CapRover's Built-in Nginx

Alternative 1: Traefik

Alternative 2: Caddy

Alternative 3: Nginx Proxy Manager

Domain Strategy: Alternatives to Cloudflare

Alternative 1: DuckDNS

Alternative 2: Tailscale (Private Network)

Alternative Architectures

Multi-VM Architecture

Kubernetes (K3s) on Oracle Cloud

Summary: Why Our Chosen Stack Wins

15 KiB

Raw Blame History