User Image

Admiral-project's Profile

admiral-project (fas) | Fedora badges

Admiral-project's Projects

admiral-project/admiral

Admiral Admiral is a simple, billing-aware Platform as a Service (PaaS) designed for software agencies and SaaS builders who want to provision, monetize, and operate customer applications quickly without the operational complexity of Kubernetes. Admiral focuses on simplicity, predictable operations, low cost, and a secure-by-default deployment model. Status: Early development — not production ready. Current integration status in this repository: admirald, admiral-fleet, and admiralctl are the active backend E2E focus. admiral-flagship is functional, with working dashboard and instance management views. admiral-flagship is part of the normal single-node installation flow. admiral-harbor remains pre-alpha and is planned for a later phase. What Admiral Is Admiral is a lightweight PaaS for running SaaS applications using containers. It helps software agencies and independent software vendors: Provision customer applications Operate SaaS products Monetize software offerings Manage customer lifecycle Pause and resume customer environments Execute backups Scale application resources Offer subscription-based services Admiral is intentionally designed around simple, well-understood infrastructure: Linux servers Containers Podman systemd PostgreSQL PostgreSQL-backed durable queue (admiral_queue) No Kubernetes required. The goal is simple: Install platform, provision customers, ship software. What Admiral Is NOT Admiral is not: A Kubernetes replacement for hyperscale workloads A cloud provider A general-purpose container orchestration system A platform for arbitrary enterprise infrastructure A complex DevOps framework Admiral exists to solve a specific problem: Small and medium software agencies need a practical way to deploy and operate SaaS products without building a DevOps department. If you need: service meshes hundreds of microservices multi-region orchestration advanced scheduling cluster-level elasticity hyperscale infrastructure You probably want Kubernetes. If what you need is: Provision customer → charge customer → operate software Admiral may be a good fit. Why Admiral Exists Modern infrastructure is often unnecessarily complex for small SaaS businesses. Many software agencies simply need: Customer provisioning Billing and subscriptions Backups Resource management Secure operations Predictable infrastructure Customer self-service But frequently end up managing: Kubernetes Helm ingress controllers complex networking secret management systems cluster administration overengineered CI/CD pipelines For many small and medium SaaS businesses, this complexity is operationally expensive and unnecessary. Admiral embraces boring, predictable infrastructure. Principles: Simple Secure by default Low operational cost Easy to install Easy to understand Minimal moving parts Linux-native Pragmatic scaling Billing-aware operations Sometimes boring technology is the best technology. Billing First Principle Admiral is designed around a billing-first architecture. Billing is not an afterthought. Billing is a first-class concern of the platform. Every provisioned application is assumed to exist within a commercial relationship. This architectural principle influences the entire system. Examples: Applications belong to subscriptions Tiers define allowed resources Resource changes may affect billing Suspension and resume are billing-aware operations Backup retention may depend on plan limits Provisioning assumes a commercial plan Customer lifecycle is tied to subscription lifecycle Operational actions can be constrained by plan capabilities Admiral intentionally avoids a common mistake: Build infrastructure first, figure out monetization later. Instead: Infrastructure and monetization are designed together. The result is a platform optimized for agencies that want to launch SaaS products quickly while maintaining predictable operational and commercial behavior. A simple rule summarizes this philosophy: Every application exists within a commercial context. Architecture Admiral consists of five components. admirald The core control plane. Responsibilities: Provision applications Deprovision applications Pause and resume workloads Execute backups Change application resources Expose the provisioning API Coordinate fleet operations Propagate application state admiral-fleet The worker runtime. Responsibilities: Execute provisioning instructions Manage application containers Perform health checks Enforce resource policies Monitor node state Execute node-level actions Report execution status to admirald admiral-harbor Customer portal. Responsibilities: User accounts Application catalog Subscription lifecycle Billing experience Plan selection Backup access Pause and resume applications Resource upgrades and downgrades admiral-flagship Administrative interface. Responsibilities: Node management Fleet visibility Application definitions Tier management Operational administration Platform configuration admiralctl Administrative command line interface. Responsibilities: Platform administration Diagnostics Provisioning workflows Debugging Maintenance operations
  • Alma+epel 10 : x86_64_v2
  • EPEL 10 : aarch64, x86_64
  • Fedora 44 : aarch64, x86_64
  • Fedora 45 : aarch64, x86_64
  • Fedora rawhide : aarch64, x86_64
  • Rhel+epel 10 : aarch64, x86_64