FOSSBilling de 0 a Hero

FOSSBilling es una aplicación PHP de facturación y automatización para negocios que venden servicios recurrentes: hosting compartido, dominios, licencias, retainers. Cubre el circuito completo — catálogo de productos, carrito, pedido, factura proforma, cobro por pasarela, aprovisionamiento en un panel de control, renovación, suspensión y cancelación — con 40 módulos en el núcleo, un área de cliente propia y una API JSON. Se instala en tu servidor, la base de datos es tuya y la licencia del código de la aplicación es Apache-2.0.

Su origen explica casi todo lo demás. FOSSBilling es un fork de BoxBilling, un producto comercial cuyo último release fue el 4.22.1.5 del 3 de abril de 2022. El repositorio FOSSBilling/FOSSBilling se creó el 18 de mayo de 2022 para rescatar ese código y publicarlo bajo licencia libre; el LICENSE todavía lleva doble copyright, “Copyright 2022 FOSSBilling” y “Copyright 2011-2021 Boxbilling, Inc”. El fork no fue cosmético: heredó un framework propio con router propio, contenedor Pimple y dos ORM conviviendo. Y heredó también el namespace: los módulos siguen viviendo bajo Box\Mod\ en 2026, con el issue #1679 abierto para renombrarlos.

Ahora la parte incómoda, que este curso pone al principio y no al final. El proyecto se declara beta en tres sitios oficiales. El README dice literalmente “FOSSBilling is under active development and currently considered beta. Expect rough edges and limited support.” La página de descargas dice “FOSSBilling is currently pre-production software”. Y el propio changelog de la versión que aquí se documenta cierra con la frase “0.8.5 should be considered the recommended security baseline.” No es marketing invertido: es la posición declarada del proyecto.

Los números que hay detrás de esa declaración: 32 advisories publicados, todos en 2026 — 4 críticos, 12 altos, 11 medios y 5 bajos. Los cuatro críticos, todos parcheados en 0.8.0, son un bypass de autenticación que permitía crear un administrador sin credenciales (CVE-2026-33543), una inyección de plantilla en Twig (CVE-2026-28496), una validación de rol defectuosa en la API (CVE-2026-27604) y un bypass de pago falsificando el IPN (CVE-2026-42341). El proyecto publica además una alerta central no descartable para toda instalación con versión igual o inferior a 0.7.2, con el título “This version of FOSSBilling is insecure”. De ahí la regla que atraviesa el curso entero: 0.8.5 es el mínimo, no una recomendación. Cualquier instancia por debajo de 0.8.0 se considera comprometible, no desactualizada.

El contexto de sostenibilidad importa igual de mucho para decidir. Detrás de FOSSBilling no hay fundación ni empresa: hay un Steering Committee de cinco personas, 108 contribuidores y un Open Collective con un ingreso anual de 791 dólares y 33 backers. La cadencia de releases tuvo huecos largos en 2024 y 2025 y se aceleró notablemente en 2026. No existe autenticación de dos factores en 0.8.5: el issue #62 sigue abierto en el milestone 0.9.x y el PR que la implementaba se cerró sin fusionar. Si tu criterio de compra incluye MFA en el panel de administración, hoy tienes que montarla fuera de la aplicación, y el capítulo 16 detalla las cuatro mitigaciones de infraestructura que quedan.

Con eso sobre la mesa, la decisión es tuya y este índice existe para que puedas tomarla antes de leer nada más. FOSSBilling tiene sentido cuando quieres control total del dato y del código, toleras parchear rápido cuando salga un advisory y tu operación cabe en los seis módulos de servicio y las cuatro pasarelas que existen de verdad. No lo tiene si necesitas MFA hoy, si dependes de una pasarela o un panel de virtualización que no está en el núcleo — no hay Proxmox, Virtualizor, VirtFusion ni SolusVM — o si tu cumplimiento normativo exige un proveedor con soporte contractual.

Recorrido del curso

flowchart TD
    A["Fundamentos e instalacion<br/>Cap. 1-3"] --> B["Operacion del negocio<br/>Cap. 4-9"]
    B --> C["Integraciones externas<br/>Cap. 10-12"]
    C --> D["Desarrollo y extension<br/>Cap. 13-15"]
    D --> E["Seguridad y produccion<br/>Cap. 16"]

El flujo de negocio que vas a montar

flowchart LR
    CLI["Cliente se registra"] --> CAR["Carrito y checkout"]
    CAR --> PED["Pedido en estado pending_setup"]
    PED --> FAC["Factura proforma"]
    FAC --> PAS["Pasarela de pago"]
    PAS --> IPN["ipn.php valida y crea transaccion"]
    IPN --> PAG["Factura pagada y numerada"]
    PAG --> ACT["Activacion del pedido"]
    ACT --> APR["Server manager o registrador aprovisiona"]
    APR --> ACTIVO["Servicio activo con expires_at"]
    ACTIVO --> CRON["Cron genera factura de renovacion"]
    CRON --> REC["Recordatorios de vencimiento"]
    REC --> COB{"Se paga a tiempo"}
    COB -->|Si| ACTIVO
    COB -->|No| SUS["Suspension automatica"]
    SUS --> CAN["Cancelacion tras el plazo"]

Los 16 capítulos

Bloque 1. Fundamentos e instalación

#	Capítulo	Qué resuelve
1	Qué es FOSSBilling y en qué estado está realmente	Los 40 módulos del núcleo, el fork de BoxBilling y sus rastros vivos en el código, la trampa de leer el AGPL del sitio web cuando la aplicación es Apache-2.0, los 32 advisories con sus cuatro críticos, la gobernanza real y una comparativa con WHMCS, Blesta y HostBill que termina en un árbol de decisión
2	Instalación: VPS con nginx, PHP-FPM y MariaDB, y con Docker	Los requisitos que comprueba el código y no coinciden con la documentación, el enlace oficial de descarga que hoy devuelve 404, un bloque nginx endurecido con las siete carencias del oficial corregidas, el asistente por dentro y el compose de producción con la trampa del volumen que tapa el código de la imagen
3	config.php de la A a la Z, la CLI y los logs	Cada clave del único fichero de configuración con su default y su efecto real, trusted_proxies y el bucle de redirección infinito, el salt que no puedes perder, las treinta políticas del rate limiter, las seis discrepancias verificadas entre doc y código, los seis comandos de console.php y los once canales de Monolog

Bloque 2. Operación del negocio

#	Capítulo	Qué resuelve
4	Configuración inicial: empresa, monedas, impuestos y numeración de facturas	El orden exacto de configuración antes de vender nada, porque los datos de empresa, la tasa de IVA y la serie se congelan dentro de cada factura y no se recalculan nunca. El modelo de monedas de 0.8.x sin price_format, los tres proveedores de tasas de cambio y la mecánica del contador único de numeración
5	Catálogo de productos: tipos, precios recurrentes, addons y promociones	Los siete tipos de producto frente a los seis módulos de servicio que existen de verdad, la tabla de precios con su trío de columnas por periodo, los límites reales — no hay periodos de 4 y 5 años tarificables ni prorrateo en upgrades — y el sistema de cupones con redenciones reservadas
6	Clientes: grupos, campos personalizados, balance y el área de cliente	Los estados que bloquean el login, los 20 campos personalizados, qué hacen y qué no hacen los grupos, el balance como tabla de movimientos y no como saldo, la impersonación que solo escribe client_id en la sesión, y el estado real del GDPR en el núcleo
7	Pedidos y ciclo de vida del servicio: del carrito a la suspensión	Qué crea createOrder() dentro de su transacción, los seis estados y las reglas exactas de transición con los mensajes de error que las delatan, el aprovisionamiento vía _callOnService, los batches de suspensión y cancelación del cron, y la cancelación al final del periodo de 0.8.5
8	Facturación, pagos y cobranza	Una sola fila que pasa de proforma a factura, las cuatro condiciones del SQL que debe cumplir un pedido para generar renovación, los recordatorios con su candado reminded_at, las tres capas de deduplicación de una transacción, el claimForProcessing() atómico y los tres modos de reembolso
9	Soporte, staff, permisos y correo saliente	El módulo Support con sus helpdesks y auto-cierre, el modelo de permisos reescrito en 0.8.4 a grupos con herencia y super_admin, los cuatro transportes de correo con DSN de Symfony Mailer, la cola mod_email_queue, las 46 plantillas del núcleo y un checklist de por qué no sale ningún correo

Bloque 3. Integraciones externas

#	Capítulo	Qué resuelve
10	Pasarelas de pago: Stripe, PayPal, IPN y tu propio adaptador	Las cuatro únicas pasarelas del núcleo y la purga de 2023 que explica por qué falta el resto, ipn.php línea a línea, Stripe con firma HMAC obligatoria y sus 12 eventos, PayPal Standard con _notify-validate y por qué VERIFIED no basta, y el esqueleto completo de un Payment_Adapter propio
11	Server managers: aprovisionar hosting y escribir el tuyo	Los seis managers del núcleo con sus puertos y trampas, el modelo servidor-plan-producto y los errores 701 a 704 al vincularlos, los 13 métodos abstractos verdaderos de Server_Manager frente a los seis que la web documenta y no existen, y el hecho central: FOSSBilling hoy no cubre VPS
12	Dominios y registradores: TLDs, precios y tu propio Registrar_Adapter	Los ocho ficheros de registrador y las cuatro marcas blancas de ResellerClub, el punto que todo el mundo malentiende — los precios por TLD los pones a mano, no se consultan al registrador —, el flujo de registro, transferencia y renovación, y las quince firmas abstractas reales del adaptador

Bloque 4. Desarrollo y extensión

#	Capítulo	Qué resuelve
13	Arquitectura interna y desarrollo de módulos propios	Que no es Symfony ni Laravel sino un framework propio que consume componentes prestados, el bootstrap de load.php con sus códigos de excepción, di.php servicio a servicio, RedBeanPHP congelado conviviendo con Doctrine 3, por qué no hay migraciones, y un módulo funcional completo con la estructura 0.8.x que ya no es la del example-module oficial
14	La API JSON y los hooks	Los tres roles enrutables, el Basic Auth con usuario literal admin o client, el CSRF y sus cuatro ubicaciones, el catálogo de códigos de error del 201 al 9999 y el detalle incómodo de que casi todos llegan con HTTP 200, los diez pasos del dispatcher, y los hooks con su gotcha: se persisten en base de datos y no se descubren hasta que corre el cron
15	Temas Twig, widgets e internacionalización	El orden de prioridad de TwigLoader para sobrescribir cualquier plantilla sin tocar el núcleo, la estructura real de un tema con esbuild, strict_variables = true como causa número uno de la página en blanco, el sandbox que limita las plantillas de email, los widgets con sus slots, y el estado real del español al 83,5 %

Bloque 5. Seguridad y producción

#	Capítulo	Qué resuelve
16	Seguridad, endurecimiento y puesta en producción	Cómo leer un advisory y decidir si te afecta, las cuatro mitigaciones para la ausencia de 2FA, HTTPS en dos capas, cerrar /install, /data, /vendor y config.old.php, sacar path_data de la raíz web, endurecer el servidor, rotar lo que Monolog no rota, los backups que el núcleo no hace, el rendimiento y el actualizador de dos fases que puede dejarte el cron parado sin avisar

Rutas de lectura por perfil

Hoster que evalúa migrar desde WHMCS

Tu pregunta no es cómo se instala, es si se puede. Empieza por el capítulo 1 entero, sobre todo la comparativa y el árbol de decisión, y no lo cierres hasta contestar si toleras la ausencia de 2FA. Salta directo al capítulo 11 para comprobar que tu panel está entre los seis soportados y al capítulo 10 para lo mismo con tu pasarela: esas dos listas son cortas y decisivas. El capítulo 12 te dirá si tu registrador está cubierto y que los precios por TLD se cargan a mano. Con eso puedes decidir. Si la respuesta es sí, vuelve al 2, al 4 y al 7, y termina en el capítulo 16 antes de mover un solo cliente.

Freelance que factura servicios recurrentes

No necesitas aprovisionamiento automático: necesitas cobrar todos los meses sin perseguir a nadie. Instala con Docker siguiendo el capítulo 2, haz el capítulo 4 con calma — es el que evita que emitas facturas con el IVA mal congelado — y modela tus servicios como productos custom en el capítulo 5. El capítulo 8 es tu capítulo central: renovaciones automáticas, recordatorios y reembolsos. Conecta Stripe con el capítulo 10, deja el correo saliente funcionando con el capítulo 9 y puedes saltarte el 11, el 12 y el 13 por completo.

Desarrollador que quiere extenderlo

Lee el capítulo 3 para saber dónde mirar cuando algo falle, y luego vete derecho al bloque 4. El capítulo 13 es la base: sin entender Pimple, el router propio y la convivencia de los dos ORM, cualquier módulo que escribas va a pelear contra el framework. El capítulo 14 te da la superficie de integración y el sistema de eventos, y el 15 la capa de presentación. Si tu extensión es un adaptador, los esqueletos completos están en el capítulo 10 para pasarelas, el 11 para paneles y el 12 para registradores.

Requisitos previos

Requisito	Para qué	¿Obligatorio?
PHP 8.3, 8.4 o 8.5	El código comprueba min_version = '8.3'. Debian 12 y Ubuntu 22.04 necesitan Sury o ppa:ondrej/php	Sí
Extensiones PHP	curl, intl, openssl, pdo_mysql, xml, dom, iconv, json, zlib y gd — esta última es obligatoria en el código aunque la doc la liste como recomendada	Sí
MySQL 8.4+ o MariaDB 11.4+	Almacén único. Crea la base en utf8mb4 tú mismo antes del asistente	Sí
nginx o Apache con TLS	El instalador y el área de cliente asumen HTTPS. certbot antes del asistente, no después	Sí
Manejo de shell, SQL y PHP básico	Vas a editar config.php, leer logs y consultar tablas para diagnosticar	Sí
Nociones de Twig	Solo desde el capítulo 15 en adelante	Para el bloque 4
Una cuenta Stripe o PayPal en modo test	Probar el circuito de cobro completo sin mover dinero	Para el capítulo 10

Laboratorio recomendado

Monta dos entornos y no los confundas. Uno. Una instancia local con el compose oficial del capítulo 2, donde puedes romper cosas, borrar la base y volver a empezar. Ahí haces los capítulos 4 a 9 y todo el bloque de desarrollo. Dos. Un VPS pequeño con dominio real y certificado, porque hay tres cosas que no puedes probar en localhost: los IPN de las pasarelas, que necesitan una URL pública alcanzable; el correo saliente con SPF y DKIM; y el comportamiento detrás de un proxy inverso, que es donde aparece el bucle de redirección de force_https.

Advertencia: usa la demo pública oficial solo para mirar la interfaz. No cargues datos reales de clientes en ninguna instancia hasta haber completado el capítulo 16: entre la ausencia de 2FA y la superficie que queda abierta por defecto, una instancia recién instalada y expuesta a internet no está lista para datos de terceros.

Cómo usar este curso

1. Los capítulos 1 a 3 no se saltan. El 1 decide si sigues; el 2 y el 3 son la base sobre la que todo lo demás asume estar apoyado.
2. El 4 es irreversible en la práctica: los datos de empresa, la tasa de IVA y la serie de numeración se congelan en cada factura emitida. Hazlo antes de la primera venta.
3. Del 5 al 9 se construye el negocio, en ese orden: no hay pedido sin producto, ni factura sin pedido, ni cobranza sin correo saliente.
4. Del 10 al 12 se conecta con el mundo. Cada uno cierra con el esqueleto de un adaptador propio, por si tu proveedor no está.
5. Del 13 al 15 se extiende el sistema. Son independientes del bloque de operación.
6. El 16 se lee antes de abrir al público, no después del primer incidente.

Empieza por Qué es FOSSBilling y en qué estado está realmente →