Skip to content

Roadmap Item: 🛠️ Self-hosting Framework

Status

PROPOSED

Date: 2025-07-06

Changelog

Date Revision Description Author
2025-07-06 1.0 Initial version @souperk

Context

The Loryth project vision strongly emphasizes self-hosting as a key differentiator, stating that "The entire platform can be self-hosted, giving users complete ownership and control of their personal data." Additionally, "Complete Data Ownership" is listed as a core differentiator where "Users maintain full control over where their data resides."

Despite the importance of self-hosting to the project's vision, the current roadmap lacks specific initiatives focused on making self-hosting accessible and straightforward for users with varying technical abilities. Without dedicated effort in this area, the platform risks becoming accessible only to those with significant technical expertise, limiting its adoption and impact.

This roadmap item addresses the need to develop a comprehensive self-hosting framework that enables users of different technical backgrounds to deploy, manage, and maintain their Loryth instances.

Proposal

Overview

Develop a comprehensive self-hosting framework that simplifies deployment, management, and maintenance of Loryth instances across various environments. This includes creating deployment tools, infrastructure-as-code templates, monitoring solutions, backup systems, and detailed documentation to empower users to host their own instances with confidence.

Goals

  • Create streamlined deployment solutions for various hosting environments
  • Develop infrastructure-as-code templates for major cloud providers
  • Build local deployment options for home servers and personal devices
  • Implement monitoring, backup, and recovery solutions
  • Provide comprehensive documentation for self-hosting scenarios
  • Lower the technical barrier for self-hosting

Non-Goals

  • Managed hosting service (contradicts self-hosting philosophy)
  • Support for legacy or obscure hosting environments
  • Hardware-specific optimizations beyond common platforms
  • Complex enterprise deployment scenarios

Technical Details

Approach

  • Create containerized deployment solutions using Docker and Kubernetes
  • Develop infrastructure-as-code templates for AWS, Azure, and GCP
  • Build deployment tools for home server environments
  • Create backup and disaster recovery tooling
  • Design update mechanisms that preserve user data

Dependencies

  • Requires Plugin System Foundation (Release 0.2.5)
  • Depends on Security Implementation (Release 0.3)
  • Builds on Performance Optimization (Release 0.4)

Backwards Compatibility

  • Initial implementation with no backward compatibility concerns
  • Will establish upgrade paths for future versions
  • Deployment configurations will be versioned

Implementation Plan

Phase 1: Containerization

  • Containerize all Loryth services
  • Create Docker Compose files for simple deployments
  • Develop Kubernetes manifests for production deployments
  • Build container health checks and readiness probes
  • Create documentation for container-based deployments

Phase 2: Cloud Deployment

  • Develop Terraform templates for AWS
  • Create ARM templates for Azure
  • Build Deployment Manager configurations for GCP
  • Implement cloud-specific storage solutions
  • Create documentation for cloud deployments

Phase 3: Home Server Solutions

  • Develop deployment tools for popular NAS platforms
  • Create single-binary deployment option for simpler setups
  • Build resource-optimized configurations
  • Implement local network discovery protocols
  • Create documentation for home server deployments

Phase 4: Management Tools

  • Create backup and restore utilities
  • Build update management tools
  • Implement diagnostic utilities
  • Create comprehensive operations documentation

Community Impact

For Contributors

  • Introduces infrastructure-as-code practices
  • Requires familiarity with containerization and deployment technologies
  • Creates new opportunities for contributions in operations and infrastructure
  • Establishes deployment testing requirements

For Users

  • Enables self-hosting with reduced technical barriers
  • Provides options for different hosting environments
  • Improves reliability through monitoring and backup solutions
  • Simplifies maintenance and updates

Alternatives Considered

  1. Managed hosting service

    • Description: Offer a managed hosting option for users who don't want to self-host
    • Pros:
      • Removes technical barriers completely
      • Ensures optimal configuration and performance
      • Provides a revenue stream for project sustainability
    • Cons:
      • Contradicts core philosophy of user control and data ownership
      • Creates privacy concerns with centralized hosting
      • Requires significant operational infrastructure
    • Why not chosen: Fundamentally conflicts with project vision of user control and data ownership

  2. Single deployment method

    • Description: Focus on a single deployment method (e.g., Docker only)
    • Pros:
      • Simpler implementation and maintenance
      • Consistent support experience
      • Focused documentation
    • Cons:
      • Excludes users with different preferences or requirements
      • Less adaptable to diverse hosting environments
      • May not optimize for all use cases
    • Why not chosen: Would unnecessarily limit accessibility for different user environments

  3. Manual deployment only

    • Description: Provide only documentation for manual deployment without automation
    • Pros:
      • Simpler development requirements
      • More educational for users
      • Greater flexibility for customization
    • Cons:
      • Significantly higher technical barrier
      • More error-prone deployments
      • Poor user experience for non-technical users
    • Why not chosen: Would severely limit accessibility to technical users only

Open Questions

  • What minimum hardware requirements should be established for self-hosting?
  • How should updates be managed across diverse deployment environments?
  • How can the backup process be simplified while remaining robust?
  • What deployment environments should be prioritized?

References