Lista de verificación de preparación para el alojamiento

Utilice esta lista de verificación antes de comprar alojamiento, antes de la primera implementación de producción y después de un cambio de configuración del servidor de materiales o PHP. Registre la evidencia y el propietario de cada artículo; un mensaje verbal "Laravel es compatible" no es suficiente.

Los requisitos normativos de plataforma y funcionalidades se encuentran en Requisitos de alojamiento. Los valores de los recursos deben provenir de registros Resultados de capacidad de alojamiento producido con Validación de capacidad de alojamiento, no de una estimación sin mediciones. Un resultado marcado como provisional solo sirve como evidencia comparativa; cualifique el perfil real de producción antes de tratar sus valores como requisitos certificados.

• PHP 8.3 o posterior está disponible tanto para solicitudes web como para CLI, y el proveedor explica cómo se mantienen las versiones de parche.
• Composer 2 puede ejecutarse en el directorio de la aplicación sin un tiempo de espera de instalación de dependencia artificial.
• mbstring, sodium, zipy pdo_mysql están habilitados tanto en la web como en CLI PHP.
• MySQL 8.0 con InnoDB está disponible, incluido permiso para crear y modificar tablas, índices y claves externas.
• La raíz del documento de dominio puede apuntar directamente al directorio de la aplicación Laravel. public/ .
• Certificados HTTPS y renovación automática están disponibles.
• El proveedor indica PHP memoria, carga, cuerpo POST, tiempo de espera de solicitud, proceso, inodo y cuotas de disco.
• El proveedor explica si proc_open, PHP CLI, Composer y los archivos binarios del cliente de base de datos están disponibles para el tiempo de ejecución PHP.
• El proveedor explica si se permiten enlaces simbólicos para public/storage.
• Cron está disponible si se habilita la limpieza programada.
• Se permite HTTPS saliente para Composer, actualizaciones de CMS o importación remota de medios, según corresponda.
• Se documentan la retención de copias de seguridad, el procedimiento de restauración, la supervisión y la escalada de soporte.
• Los perfiles principales, de medios, de operaciones y de tráfico seleccionados se identifican como aplicables o no aplicables.

Cualquier respuesta "no" debe compararse con una característica deliberadamente desactivada o un procedimiento de implementación/operaciones externo antes de la aprobación.

• La versión de producción se instala en una aplicación Laravel 12.55+ o Laravel 13, y no se sirve directamente desde el repositorio del paquete.
• Web y CLI informan versiones y conjuntos de extensiones compatibles con PHP.
• composer check-platform-reqs pasa en la aplicación host implementada.
• La conexión de la base de datos se realiza correctamente y utiliza la base de datos de producción prevista.
• APP_KEY está configurado, APP_DEBUG=falsey APP_URL es la URL HTTPS canónica.
• La raíz web es public/; /.env y /.git/config retorno 404.
• Laravel El comportamiento de reescritura/controlador frontal funciona para una ruta que no es de archivos.
• /webadmin rutas a través de Laravel mientras /cms sirve activos estáticos propiedad del paquete.
• storage/, bootstrap/cache, el disco de respaldo y los requisitos public/site se pueden escribir mediante el tiempo de ejecución PHP sin 777.
• public/storage funciona cuando se utiliza el disco público estándar.
• Las copias de seguridad de archivos y bases de datos existen fuera de la aplicación y una prueba de restauración tiene un propietario y una fecha.
• Las suposiciones de memoria, tiempo de espera, carga, disco y características del perfil de capacidad seleccionado coinciden con este servidor.

Marque las funciones no utilizadas como no aplicables y registre el motivo.

• Medios: una carga se puede almacenar y servir; cuando se requieren variantes de imagen, GD y el códec de formato fuente están disponibles.
• Correo: el restablecimiento de contraseña y la entrega de notificación de contacto llegan al buzón de prueba previsto a través de un transporte real.
• Notificaciones del panel: Con el correo desactivado y sin ejecutar el programador, un responsable de operaciones del sitio puede ver los recuentos almacenados de mensajes no leídos o pendientes de respuesta y abrir la bandeja filtrada por el sitio correcto. Se excluyen los demás sitios; abrir el panel no cambia el estado de los mensajes ni de la entrega.
• Programador: cuando se seleccionan notificaciones por lotes/diarias, resúmenes diarios o limpieza programada, el administrador/proveedor del servidor ha configurado Laravel schedule:run cada minuto bajo el usuario de la aplicación con el binario PHP CLI correcto. Registre al responsable y la ruta real de la aplicación; un programador existente que funcione no necesita otra entrada cron.
• Dependencias de notificación: un transporte de correo saliente real, canónico APP_URLy se configura una caché compartida con bloqueos atómicos para varios trabajadores. Los sitios nuevos utilizan de forma predeterminada notificaciones por lotes y resúmenes diarios.
• Evidencia del programador: en CMS 1.95.1+, configuración del panel/sitio o php artisan webblocks:scheduler:status --json muestran un latido programado reciente y una ejecución de notificaciones completada. Compruebe que la evidencia pasa a retrasada tras cinco minutos sin ejecución. Ejecutar manualmente el comando de envío o listar tareas no demuestra que el programador se haya ejecutado.
• Actualización del sistema: su verificación previa de administrador pasa las comprobaciones de base de datos, extensión, proceso, acceso de escritura, bloqueo y espacio libre.
• Copia de seguridad/restauración de MySQL: están disponibles cuando se utilizarán copias de seguridad de bases de datos nativas a nivel de aplicación.
• Medios remotos: las solicitudes salientes funcionan solo si se requiere importación remota.

• La página de inicio pública devuelve la respuesta segura esperada.
• /webadmin/login se carga a través de HTTPS y un administrador autorizado puede iniciar sesión.
• CMS CSS, JavaScript y los activos de marca en /cms devuelven respuestas exitosas.
• Se puede crear un borrador y obtener una vista previa sin que sea visible públicamente.
• Se puede cargar, mostrar y eliminar un elemento multimedia según la política.
• Los registros no contienen errores de permiso, de base de datos, de contenido mixto o de extensión faltante de la prueba de humo.
• Las copias de seguridad, la propiedad de implementación/actualización, el monitoreo y los contactos de emergencia se registran en la transferencia.

Mantenga lo siguiente con el registro de implementación sin incluir secretos:

• plan de hosting o perfil de servidor y región;
• PHP y versiones de base de datos;
• nombres de extensiones habilitadas;
• Resultado composer check-platform-reqs;
• límites de recursos configurados y disco disponible en el momento de la aceptación;
• versión del perfil/dispositivo de capacidad, ubicación del resultado bruto, fecha de calificación y peor caso de cinco ejecuciones;
• modelo de propiedad de sistema de archivos y raíz de documentos;
• funciones opcionales habilitadas y sus dependencias;
• fecha y operador de la prueba de humo; y
• fecha de prueba de copia de seguridad/restauración, retención y parte responsable.

Repita las secciones relevantes después de cambiar la versión de PHP, el motor de la base de datos, la raíz del documento, la propiedad del sistema de archivos, el método de implementación o el proveedor de alojamiento.